By Chris Lockhart, Director at Point Management Group
There are challenges in companies that have historically delivered capability via traditional methods, on traditional timelines, with traditional skills, whenever new blood decides that they should be agile.
This is somewhat of an understatement. In most cases, entrenched waterfall culture trying to become agile is akin to a gaggle of blindfolded people trying to find a black cat in a dark room, especially when there is no cat.
How can a company, a business unit, a team, in an environment where waterfall mindsets are deeply entrenched, appreciably move the needle toward leveraging agile concepts to deliver value more quickly? How does a consulting practice help waterfall clients deliver value in an agile fashion? Especially when delivering value isn’t always the stated objective? When in fact it is often ‘deliver such and such by this date’ or ‘deliver this undefined scope with these defined resources’. It is a real-world challenge being played out across the business landscape.
So first, let’s step back. Are we talking about agile, lower-case ‘a’ as in just being more nimble or are we talking about capital “A” Agile as in the methodology?
My experience tells me that when waterfall places believe adopting a specific Agile framework will make them agile, it usually does the opposite. In reality, unless there is well-funded, top-down commitment to making major people and process change coupled with bottom-up technical expertise, becoming agile by adopting some Agile framework is usually a recipe for chaos. Short of good funding, great champions, widespread buy-in and commitment and some positive business case for doing so, specific Agile frameworks are probably not the path forward.
Recognizing that any given situation has its own particulars is important. Each enterprise is exploring agility to help with some aspect of delivery within their own context. It could be to increase speed of delivery, to improve coordination across multiple teams for highly complex implementations, to rapidly pilot and release capabilities, to improve quality of code and/or decrease the cost of operational support, to enhance some aspect of the customer relationship or a combination of these and other things. The point is, the context matters. It is not one-size fits all.
So the very first step in this process is to understand what problem you are trying to solve for and what challenges you have in solving for it. Sounds stupidly simplistic, but it is true.
For example, when one group or team wants to improve speed of delivery, but there isn’t a cross-enterprise buy-in on process and tooling, and experience on the team with agile methodology is inconsistent, going whole-hog on one framework is not going to work. Knowing what we’re trying to do (increase speed of delivery) and knowing the challenges (no buy in, team skills), helps in the solution. The best approach here is to take incremental steps:
- Individuals and Interactions – Start with the premise that a certain amount of work can be accomplished by a well coordinated team that actually speaks to each other. Teams that interact closely are able to better share, learn, problem solve. Issues with code, tools, process, people – in short any problem – is solved faster and better when people are talking. Faster and better problem solving is what this is all about. Have the stand up meetings, encourage working sessions, don’t schedule follow-up meetings for problems – CALL the person you need to speak to and resolve the issue there in the moment. When teams are interacting better, things move faster and are delivered with higher quality.
- Working Software – Higher performing teams can be focused less on endless thinking about problems and focused more on delivering working bits of solutions. In other words, if the team is aligned and thinking with one brain, there’s less of a need for time spent on huge amounts of typical SDLC documentation – requirements, designs, architectures, runbooks, etc. – that allow you to progress past the toll-gate but which few people will ever read. Of course, the holy grail of less time spent on documentation and more time spent delivering actual solutions that work always runs up against the bureaucratic need to leave a paper trail. But that is ok. Just because teams are focused on delivering functional code, doesn’t mean they can’t take notes as they go. Project Managers, business analysts or other folks on the team can help collate and publish this material and meet the needs of the organization for reviews and approvals. And all of it will go a lot easier if the team knows the code will work because the team has delivered working code.
- Customer Collaboration – Large waterfall projects will spend months on requirements gathering and design, turning over every rock and dotting every “i”. Speeding up delivery implies that we need to cut some of this out. In the waterfall company of the example, this can be done by engaging early. The team that is writing the solution must be brought into contact with the customer of the solution. Just as in Step 1 above, interactions are critical. And in keeping with Step 2, showing a customer sample bits of functional code is a game-changing way to help them visualize what their needs are and articulate their requirements. Doing this doesn’t violate the typical waterfall toll-gate process. But alignment between the builders and the customers from the beginning, operating simpatico, will dramatically accelerate the normal tedium of your average SDLC.
- Responding to Change – Waterfall organizations are keen on well-structured plans, often in project-plan format with hierarchical activities and dependencies. These plans almost never survive first contact with reality and are usually in a constant state of flux, requiring a FTE project manager to constantly be fiddling with dates, milestones, capacity, etc. Instead of that, the group in our example can simply begin tracking work in a different way. This builds on Steps 1-3. Better alignment both on the team and with the customer means less obsessive ‘tracking’ is necessary. When teams are focused on delivering a stream of functioning capabilities to the customers, the customers are less likely to wonder about dependency 42 in the 30,000-line project plan. That being said, we do need to know what is happening, by when, and who is doing what, so we can communicate effectively to leadership, stakeholders, and other teams who may not care about being agile. Some of the tooling can help us – JIRA or whatever – as we want to make sure we’re assigning work to the right folks and tracking it. Many of these tools make it really easy to report on the who, what, when, and generate gantt views and burndowns and other useful artifacts for waterfall minded people. But keep in mind, waterfall is predictive while agile is adaptive. Many of the folks in the first bucket will need dates when things will be done as there are usually many interdependencies in a large enterprise program. Since our example team doesn’t control the entire scope of the project, there will be a need to report what they’re doing in a way that makes sense to others.
Those paying attention will know that these four steps align with the Agile Manifesto from 2001. There is nothing in the original manifesto that prohibits being more agile within existing less-agile environments. There’s a lot of stuff since then that suggests you have to turn over the apple cart, start with a clean slate and rethink everything in order to be Agile. In my experience, most of those that articulate this view are usually trying to sell something.
For large waterfall places, whether you are on a team in a company and you’re trying to be a bit faster or better or you’re a consulting firm tasked with helping a client via delivery assurance, recognize that incremental steps are possible within the ponderous bureaucracy. Start small, go with what works, recognize you can’t change the world but that you CAN have a better performing team that works hand in hand with the customer and can react to change – that is the definition of agile after all.