So, what is ‘Water-SCRUM-fall’?

The realities of Agile in the Enterprise

When I first heard the term ‘Water-SCRUM-fall’ from a customer, I thought it was a tongue-in-cheek comment describing their dysfunctional approach to agile or probably a reference to a Dilbert strip I had missed. Then I heard a VP of development at IBM mention it on an internal call and I realized this is a real term now being used and did some research (read: Google). It seems that Water-SCRUM-fall is a term coined by Forrester to describe the ‘reality’ of the current state of Agile. Here is a link to Forrester’s original report on this topic (don’t buy it. It’s $499!) and here is article on SDtimes (it’s free) written by Dave West, the report’s author. And here are my thoughts…

What they describe is what I see every day, especially in large organizations with slow moving bureaucracies. I see that while the development teams themselves have adopted SCRUM some variant of agile (Disciplined Agile, as evangelized by Scott Ambler, for example), for their day-to-day product development efforts, what happens before and after this effort is still very traditional and waterfall. The front-end of a project still has the approval and governance ‘gates’ and the non-agile interactions with other teams and organizations in the company – like the DBA team, EA team, Security, tools groups, etc. The back-end of every iteration too is fraught with non-agile steps and interactions. The build and release, DevOps processes are governance and process heavy with several ‘stages’ and ‘staging areas’, before an actual ‘release’. This is a big impediment to agile that requires a ‘release’ at the end of each iteration, providing quick feedback and input to the next iteration.

While this is not ideal, this is reality. And we need to accept it and live with it. At a recent engagement I was involved with at a large financial institution, I led a team that rolled out Agile to multiple project teams. The requirement from the company was to align our Agile processes with their SDLC – a cumbersome waterfall process (which they actually called iterative) which had the rigor and governance appropriate for a financial institution of their size. It was tough, but it is what we put in place for them, coupled with some rigrous hands-on coaching for their SCRUM teams.

Water-SCRUM-fall is real …and here to stay!

Related Posts

Understanding DevOps:

• Understanding DevOps – Part 1: Defining DevOps
• Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery
• Understanding DevOps – Part 3: The Battle of Dev vs Ops
• Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring
• Understanding DevOps – Part 5: Infrastructure as Code
• Understanding DevOps – Part 6: Continuous Deployment

Adopting DevOps:

• Adopting DevOps – Part 1: Begin with the Why
• Adopting DevOps – Part II: The Need for Organizational Change
• Adopting DevOps – Part III: Aligning Dev and Ops Teams

Other DevOps Posts:

• DevOps 101 – Concepts and Basics (Slides from IBM Innovate 2013)
• Leveraging DevOps in a water-SCRUM-fall world
• Monetate’s 12-step program for Continuous Delivery
• The State of DevOps (by PuppetLabs)
• DevOps for Mobile Apps – Slides from IBM Pulse 2013
• Chef for DevOps – An Introduction