How Scrum turns into Water-Scrum-Fall

Scrum came to prominence as an off-the-shelf replacement for the waterfall process. People are busy running their companies and building their products so they don't have time to think about software development practices from first principles. Scrum solved this problem by providing a simple, easy to understand framework that could be dropped in with minimal changes.

But the software delivery lifecycle starts with a product idea. Scrum was created to optimise the build portion of the product lifecycle. It doesn't give any guidance for how to come up with good product ideas or how to fund them. Since there is no clear guidance, and given how busy people are building their products, the current process of creating business cases to fund projects continues.

Business cases make a lot of sense. Companies have limited resources so they need to make sure they are spending them on the right things. Identifying what customers want, how much we expect to earn and how much it will cost is basic due diligence.

They also give us a way to govern the delivery of the project by tracking the time and cost to deliver against the original estimates.

But what gets measured gets managed. Since software development teams are going to be measured on time and cost it makes sense to do upfront planning and design to make sure that no unexpected surprises and delays occur later in the build phase.

What we have effectively done is shrunk the scope of the Scrum process to just the build phase of the software delivery lifecycle. At this point it doesn't make sense to release working software to real customers every sprint. The original purpose of releasing every sprint was to be able to get real customer feedback to learn whether the product we are building really meets their needs. But because the design is already locked in, feedback from customers is just another word for scope creep that will jeopardise the delivery timelines. Instead we can give demos to internal stakeholders to show them how we are progressing against the original plan.

Through good intentions, and a lack of guidance from the agile frameworks, we have ended up with a process that is waterfall except that we split up the build phase into multiple 2-week sprints.

Water-Scrum-Fall is better than the old waterfall projects because it gives stakeholders greater visibility into progress during the build phase so there are fewer big suprises where everyone thinks things are on track only to get a surprise that we need large budget and time extensions. But Water-Scrum-Fall does not solve the original goal of agile processes - to test our products early and often with real customers to validate if we are building products that really solve their needs.

If we want to help companies achieve real agility in their product development we need to make it easy for them to adopt alternative practices for funding work, aligning teams on what to build and governing in a way that encourages frequent customer interaction instead of discouraging it. That’s the goal of the ZeroBlockers framework.