Things happen… and then you Waterfall: The Strategic View on Agile
The reality is that in most enterprise companies, Waterfall and Agile coexist. To get the best from both worlds a portfolio strategy is required which encompasses the two models in parallel. Respect for both models is required to bring their full value to organizations.
I just came out of a meeting with my client. It’s my new project and a new client. New projects are always fascinating, each new start has its own beauty and its own new insights. This time my client is a leading global bank. My contact is at the higher management level. His statement was: “Agile is dead for us.” Breaking the silos between business and IT is something neither he nor his CIO had been able to accomplish, even after trying for some years. The business side of his company had never fully embraced it. And this, I think, is the reality in many large companies.
His comment made me think, because it was the first time I had received such pushback from a strategic leader on the Agile mindset. On one hand, a consultant should focus on areas where they know they will have a clear impact and can create results. On the other hand, we should be bold, aim high and keep our vision a little larger than what we see in front of us. If the reality is a mix between Waterfall and Agile, when do we use which approach? What strategy can make the best use of both approaches?
Companies have to balance their project execution between the traditional Waterfall and Agile approaches
Let’s look at an experience I had with a large European bank. The bank wanted to change their core banking applications, ledger, sub-ledger and move all to SAP. The senior leadership from the client requested an Agile project execution. Our specialists, who had to manage and deliver the project had strong concerns. They had done the same project before for another client and all in Waterfall. We didn’t want to lose the client, but all the experts in our team, strongly believed that Agile was the wrong approach for us in this case. They had three main arguments:
The scope of the project is known, is clearly defined and agreed upon upfront.
The client can only use the new software when all the components are in place; a partial running implementation would produce higher costs and is a risk factor.
All our experts, senior executives and specialists are used to working in the Waterfall approach. Training and coaching to deliver in Agile raises the costs and extends the timeline.
For this client, we came up with a hybrid approach, to satisfy our clients request for Agile and our strong belief that Waterfall was the right thing to do. Our hybrid model starts with the analysis and design phase in Waterfall, executes the implementation in Agile Sprints and ends by testing in Waterfall again. This hybrid model would generate a huge list of tasks (backlog), show early results, and the execution would be done in sprints. It’s highly predictable in its outcome, costs and timing.
These two client examples shows that both models coexist in leading market organizations
Companies which are not willing or able to move to a full Agile organization require a portfolio strategy to handle both approaches and optimize the outcome. To draw the line between Waterfall, Hybrid Projects and Agile, the value of the impact and the effort to change the model must be weighed against each other:
The advantages of moving to an Agile approach is bigger, because of the high value of reduced time to market and a higher learning curve which is reflected by the matrix. The Hybrid approach shows that between both models is a space where you can build-your-own approach, taking from both models what’s best for your specific scenario. The Waterfall triangle in the matrix stands for the reality we all are in.
The strengths of the Waterfall model are a clearly defined timeline for transparent results. We know what the product will do at the end. There is no exploration, but there is a clearly defined execution with a resistance to change.
Agile has its difficulties if the software requires formal planning, approval steps and can not show its strength if the outcome is already clearly defined.
We have to take the advantages of Agile into account when we decide on the delivery approach
If the project sees high value in the flexibility of changing objectives, if it needs to iterate based on the customers feedback and if it’s likely that the requirements are changing — Agile is the better choice. Agile has a high value for your project:
If the flexibility to incorporate changing requirements is crucial.
If you require the ability to iterate and update the solution until the customer feedback is positive, perhaps because you don’t know what the optimal solution is.
If structuring in long release cycles is not required.
When the acceptance from end-users is critical for the success of the project.
If you don’t have to focus on time and budget and the final end date is flexible.
The effort of moving to Agile is the second criteria we have to take into account. The main factor is the team itself. It’s less effort if
The team members have already some experience in Agile delivery.
The team and stakeholders are willing to change.
All team members are in the same time zone.
The product manager is an active member of the Agile team.
The principles of lean agile product management are understood.
Most of the software development techniques of the early years were borrowed from engineering or construction. Software was treated like building a house: you plan it, then you build it, then you use it. With Agile we realized that the solution is to change the view of the process. Users of the software can not imagine what the solution looks like before they use it. Applications are complex with many variances, and options and its boundaries are not always obvious to the user.
Agile is more like drawing an image. When you draw an image, you have multiple options; your imagination is the limit But you can only see what to optimize and change once the image is out of your head and on paper. In the portfolio strategy it is required to have areas and processes both for solid buildings and for images.
How is your organization treating Waterfall and Agile? Is there an ‘old’ in your new organization? Or a ‘new’ in your old organization?