Why do "Water-Scrum-Fall" - what does the Scrum in the middle of "Water-Scrum-Fall" offer?
Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.Sign up to join this community
Looks like "Water-Scrum-Fall" is a name coined by analyst firm Forrester Research to describe the reality of Agile found in many organizations. I would say they are referring to large and medium enterprises, because that is where they do most of their work. They could have called it "Hybrid", but I guess they wanted to identify a specific type of hybrid. Here is how they define "Water-Scrum-Fall":
...project planning and release management, continue to follow more-traditional approaches, meaning that Scrum adoption is limited to the development team. That team is presented with a detailed project plan and a set of requirements that it then works through, incrementally delivering software (but not to production) as the production release process runs at a different cadence.
So, you have the Scrum team in the middle of the process practicing Agile/Scrum while the upstream process of formulating the project is traditional:
We have to spend time upfront with the business building the requirements and plans to ensure that we know what they want, and they know how long it is going to take and how much it is going to cost.
Also, the downstream process of releasing the code to production is also traditional:
However, most organizations do not have the architecture required to support dynamic, flexible releases; instead, they do infrequent releases backed by heavy processes and governance.
With that in the background, I will try to answer your question:
My question is why do "Water-Scrum-Fall" - what does the Scrum in the middle of "Water-Scrum-Fall" offer?
The answer is "It is counter-productive"!
The "team is presented with a detailed project plan and a set of requirements". If the requirements and the timeline are pre-determined, you can't do any agile. It is counter to the Agile Manifesto value "Responding to change over following a plan". Releasing infrequently also goes against the agile principle of putting working code in the hands of the end-users soonest and getting feedback.
This is tricky because there is no such thing as Water-Scrum-Fall. I spent some time looking around online and I find two uses. The first, which I was aware of already, is a derogatory term for scrum-in-name-only. The second is reference to leveraging certain communications techniques in waterfall.
Scrum Communication in Waterfall
Simply put, you'll talk to each other more. That's really it. There is less chance of two people reading the same thing differently and not finding out for months because you'll talk to each other. I've seen people apply the 2-week reviews, but since you're still following the project plan, there is very little room to pivot if you realize that you're off the mark on what you're building. You can also implement retrospectives and there is a big benefit here. The Retrospective is a chance for the team to evaluate how it works and make small improvements. Personally, I leverage Lean and Kanban's techniques even in Scrum retrospectives, so I'd just look there to get this benefit if you aren't practicing the rest of Scrum.
Why You Shouldn't Half-Practice Scrum
Scrum is a framework designed to iterate through and solve complex, adaptive problems - problems without a clear answer with a proven implementation path. Most software falls into this category, so Scrum often works well for software. That said, it works when you use all of the pieces together. The more you strip away, the less it works. For a simple metaphor, if you want to screw in a screw, you wouldn't tape a philips-head bit onto a hammer.
Struggling with Agile and Switching to Back to Waterfall
I don't know why your organization struggled with Agile or Scrum. In my experience though, many organizations (not all) who struggle implementing Scrum have found that they face the same problems in Scrum as they did in Waterfall. A good saying is that Scrum and Agile don't solve your problems for you, they just shine a big spotlight on them - solving them is up to you. If this sounds familiar, your organization may want to look at those practices its struggling with and look into their internal workings.