There are various opinions on mixing agile and waterfall.
On one hand, there are strong arguments against mixing agile and waterfall, for example the term scrummerfall was coined to denote a combination of the two approaches and defined as “the practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.” Surveys suggest that “pure agile projects are more successful than those that use a combination of agile and waterfall.”
On the other hand, organizations often start doing agile projects by introducing agile approaches into their traditional waterfall methodologies. The term water-scrum-fall is one example of a methodology that combines waterfall with agile and although this approach is not ideal, it is useful in organizations that are transitioning to agile and want to maintain some waterfall while attempting to go agile.
The book Being Agile in a Waterfall World by Joseph Flahiff unveils a completely different perspective on the agile vs. waterfall debate. Flahiff says:
“I don’t think they are necessarily mutually exclusive. I also don’t believe one is better than the other for all cases. There are times when it makes sense to be agile and there are times when it makes sense to use a sequential approach.”
According to the author, working in iterations is an agile practice that not everyone needs or will benefit from. Projects that have a well-defined outcome do not necessarily have to be implemented using agile methodologies. There will always be a need for waterfall projects, especially in certain industries such as construction. Imagine you are building a shopping mall. In an agile world, you would identify the minimal viable product, which would probably be the actual stores where consumers shop. But in real life, you have to start by building the foundation with the underground garage first, no matter what you want as your first deliverable.
Flahiff’s definition of agile is nimble or quick or adaptable. He goes on to say that the opposite of agile is not waterfall. The opposite of agile is slow, lumbering and unadaptable. In his opinion, there is no reason to write articles about agile vs. waterfall as they are not in conflict. He says that taking a nimble approach to some work is great. Taking a more planned and predictive approach to others is also great.
Some arguments why organizations want to go agile is to be more responsive to change, especially in situations where innovations have short life-cycles. If such life-cycles are shorter than the waterfall project then by the time the project is completed, it is already too late. To address such situations, waterfall projects can be broken down into shorter phases and by paying attention to loose-coupling of various components, individual components can be delivered as part of a shorter project that is quicker to respond to change.
Despite the fact that waterfall approaches are considered traditional, management thinking does not have to be the traditional command and control. Certain modern aspects such as servant leadership, respecting people, engagement of the team and distributed decision making that are a given in agile can be introduced in waterfall as well.
I really enjoyed reading this book because it is a nice change away from the agile vs. waterfall debate. It gives a new perspective on thinking about why we want to go agile or why we want to go waterfall.