The Agile Waterfall
A hybrid approach that uses both agile and waterfall is your best option when you need a highly flexible approach that also offers transparency in timeline and costs.
My generation is the generation before Agile; the generation of large SAP rollouts. We worked for years in a waterfall approach to implement new software for our customers. We were pretty good in our world. Not perfect, but for enterprises the approach had its advantages.
Now, the world has changed: Design Thinking, Scrum, SAFe and DevOps. For us, this was like stepping off the ground into deep water. The rules of reality were turned upside down. Once we went through the stages of denial, blame, confusion and doubt we moved on to this new mindset and started performing.
To deliver in this new world, we had to leave our old way of working and learn the rules and languages of this new environment. The transition starts normally with a Scrum or SAFe certificate followed by smaller projects, then handling full enterprise transformations. Nowadays, most from my generation have already delivered projects in an agile way. We would not call ourselves Ninjas, Gurus or Evangelists, we are not natives.
Most of us started in this revolution skeptical as visitors and observers and are now pragmatic and solution oriented. We have new skills. But we still have the old ones. And sometimes those old skills provide new value and functionalities for our users.
In one of our latest SAP FS-CS implementations, these experts who know both worlds were of the highest value for our client. We executed the delivery in a hybrid approach; between waterfall and agile. This provides the best of both worlds. It’s like snorkeling. You get to see the beauty of corals and colorful fishes, but there’s no need for a diving licence, heavy equipment or the fear of running out of air in the deep.
The Hybrid Model: Waterfall-Agile-Waterfall
This model has three phase:
We start with the classic waterfall approach
Then execute the implementation and configuration in agile sprints and come back to
Waterfall for the end-to-end testing and rollout
In the first (1) waterfall phase planning and analysis of the full scope was done. This led to a defined backlog for the project. That gave us a transparent view on the upcoming cost and time for the full project.
In the second (2) Agile phase we pulled the work from the backlog, executed the required implementation with testing and demo acceptance. After each sprint we had a potentially shippable product ready.
The third (3) waterfall phase was for testing: end-to-end, extended security, performance, and user acceptance, and finally deployment and rollout.
Hybrid Waterfall-Agile-Waterfall approach (technology agnostic)
The model manages two transformations: First -a- from Waterfall to Agile, then -b- back from Agile to Waterfall
-a- First Transformation (1) → (2):
The waterfall content must now be transferred into agile artifacts. This transformation is between the first (1) waterfall phase and the (2) agile phase. Functional and technical documents are adjusted to the user stories. The user stories form together the backlog. The strong commitment of the Product Owner is essential. To enter the following agile phase, a prioritized backlog is a must.
-b- Second Transformation (2) → (3):
Here the user stories and sprints are mapped into the release and rollout plan. This is the second transformation from the (2) agile phase into the last (3) waterfall phase. The Product Owner has again an essential task: they approve the release to be ready for testing. Testing is done by a highly specialized separate team. In addition, the quality and extent of documentation is proven: Interface descriptions, application diagrams etc. must be updated.
We are now in a unique position to choose the best fitting approach
This third approach, the hybrid, is of highest value for us. This project taught us to value all models and look more specifically at each situation and tailor your approach from all the options available.
In this approach we don’t force one model for the sake of using the model. We pick what is best for the project taking all circumstances into account. Those of us with experience in both worlds have an important role. This SAP FS-CS implementation gave us the confidence that we are equally strong in both models, and proof that both can be effectively combined.
The hybrid approach has several clear hurdles we have to overcome. For example, end user feedback can only be integrated slowly in the application: the approach is not as dynamic and flexible as pure agile. Another learning was that strong Product Owners with IT understanding are fundamental for success. They bear high responsibility in both transformations.
But the benefits like transparent costs and timeline outweigh these in some situations. Some federal governance and companies require having the plans before results: in this case, the hybrid approach with its clearly defined outcome unfolds in all its beauty. But as I told you, it's like snorkeling - you have to dive in the water. You can’t always see the beauty from the shore.
Today, my generation of IT experts are unique: our old skills bring new value. We still create powerful software and bring new features to users. But instead of only using one approach, we are flexible in our way of working. We bring our old skills to the new world and deliver new value.