Water-Scrum-Fall is the norm according to Dave West, Director of Research and Vice President at Forrester. Dave wrote about Forrester's analysis in a recent SD Times article. According to Forrester:
Organizations are increasingly adopting agile software development methodologies through a combination of bottom-up adoption and top-down change. However, the reality of agile adoption has diverged from the original ideas described in the Agile Manifesto, with many adoptions resembling what Forrester labels water-Scrum-fall.
Forrester believes this happens because agile adoption is frequently practitioner led, and consequently the practitioner focuses on the domain they are most familiar with. In most cases this means: software development. Areas such as release management, or project planning are still handled with traditional methods.
The article goes on to elucidate the Water-Scrum-Fall monicker:
Water – Defines the upfront project planning process that typically happens between IT and the business.
Scrum – An iterative and adaptive approach to achieving the overall plan that was first laid out in the 'Water' stage.
Fall – A controlled, infrequent production release cycle that is governed by organizational policy and infrastructure limitations.
The article also gives tips to development teams facing the Water-Scrum-Fall reality and trying to increase agility. Among them:
- A proper Scrum team must comprise all the people necessary to deliver working software. Typically, this means developers, testers and business analysts working toward a common goal.
- Application development professionals should challenge the status quo of infrequent releases and push to better integrate release processes into the development team.
- Spending too much time upfront will not increase the quality of the release; on the contrary, it is wasteful.
- Documents are a poor proxy for working software, and thus any documents created should be just enough to introduce the problem area and allow high-level planning and development work to commence.
But reading this brought to mind a blog post from June 2011 by Mike Dwyer of Big Visible. In that post Mike makes the assertion that Scrum can be divided into three big camps: the purists, the posers, and the pragmatists.
Are Water-Scrum-Fall development teams being posers until they become pursists or is Water-Scrum-Fall the very essence of being pragmatic? Let's hear from our readers. What do you think?
Community comments
Releases with a Little Glass of Water
by Stephen B,
Agree
by Adam Nemeth,
Re: Agree
by Vijay Nathani,
Re: Agree
by Gaston Coco,
Re: Releases with a Little Glass of Water
by Rob Miles,
Re: Releases with a Little Glass of Water
by Yves Hanoulle,
Is it about winning or losing?
by Amr Elssamadisy,
Agile teams in a non-agile organization
by Alan Dayley,
Okay, as long as its a temporary stepping stone to grow the "agile vortex"
by Brad Appleton,
remember RUP?
by Martin Kügler,
Scrum Usually Can't Exist Without Water-Scrum-Fall...
by Tim Elton,
Start Where You Are
by Mike Dwyer,
Re: Start Where You Are
by Chris Goldsbury,
The Debate
by Chris Goldsbury,
Re: The Debate?
by Mike Dwyer,
Settling for What You Can Get
by David Curry,
Releases with a Little Glass of Water
by Stephen B,
Your message is awaiting moderation. Thank you for participating in the discussion.
Continuous / Frequent releases may be great for Social or Consumer applications etc, but often enterprise customers cannot or do not want to absorb releases more often than quarterly for example. The team can still do internal interim releases but in the end we need to respect the customer's desire. Also there is a certain amount of overhead that is not IT related, Product Marketing, Customer Communication, Training etc that can go with releases, these things may also have an impact on delivery cycle. This should not be an excuse to let "hardening" pile up etc.
Also I don't have a problem with a little "Water" up front sometimes, we may choose to do a little research and/or help the Business and Development vet the idea a bit, think through the Minimum Viable Feature or Product, or understand the overall objective, and / or create some lightweight directional design/architecture etc. This is especially helpful if this is a real-world distributed multi-time zone multi-cultural team. If that makes my team "Non-Agile or Not Proper" so be it. We are working in truly cross-functional teams (Product, SM, Dev, QA, Data, DevOps etc) I think this may be a little swinging back from some of the "Start Coding Now" that came early on. In my world, this is not the same as the lets produce the entire requirements up front mess I lived in for years. I would like to think of it as a thoughtful approach to being agile, and hey my team just release some really great software so we must be doing something right.
Agile is great...love it...would never go back...but like anything you need to meld the ideal into the real... guess that makes puts me squarely in Mike Dwyer's Pragmatist camp
Agree
by Adam Nemeth,
Your message is awaiting moderation. Thank you for participating in the discussion.
1) In most enterprise contexts, there's no need or desire to have a new version every few weeks. No need for "internal releases" either.
2) Minimal Useful Features (Minmal Marketable Features) sometimes don't fit in a single scrum even if all the development effort is focused on that single feature.
3) Upfront planning will, and should be always present in human endevaurs affecting life for months. The differecne is:
3.1) Upfront planning shouldn't go into certain details
3.2) Software Engineers with a development background should be present on creating the plans instead on purely deciding on feasibility
Re: Agree
by Vijay Nathani,
Your message is awaiting moderation. Thank you for participating in the discussion.
Right. So there is no need for a new term "Water-Scrum-Fall". Scrum rules are flexible enough to allow customization on a need basis. This is one customized version of Scrum. Giving fancy new new names to old wine, is just an old marketing technique.
Re: Agree
by Gaston Coco,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think it's just another term for marketing purpose. Surely some consultant right now is creating a new training call "Water-Scrum-Fall Master" :P
Is it about winning or losing?
by Amr Elssamadisy,
Your message is awaiting moderation. Thank you for participating in the discussion.
Or is it about getting results?
What I haven't read here is if this method of development is giving the same great results found on successful agile teams? If so, then great! If not - and I would assume this is the case because the feedback loop has been broken - then these orgs are not getting results they are paying for and are fooling themselves.
My two cents,
Amr
Agile teams in a non-agile organization
by Alan Dayley,
Your message is awaiting moderation. Thank you for participating in the discussion.
This pattern is common in organizations that see Agile and Scrum as something just the developers do. These organizations keep doing the product definition and customer relations the same as before, big design up front. And they do deployments, user acceptance testing, etc. the same as before.
On the plus side, the teams doing Scrum usually get better at delivering improved quality. In the negative side the organization as a whole get only minimally more Agile, nor do their customers enjoy benefits of agility. They have a better engine but insist on keeping the old car. That's too bad.
remember RUP?
by Martin Kügler,
Your message is awaiting moderation. Thank you for participating in the discussion.
Water-Scrum-Fall is known since some decades under the term (rational) Unified Process.
Oposed to what people often claim, it goes together perfectly with agile (as in the manifesto) and XP.
(Mind, that R/UP asks you to tailor the process down to what your needs are!)
Have a lok at: Open UP
Okay, as long as its a temporary stepping stone to grow the "agile vortex"
by Brad Appleton,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree with Alan Dayley, I see this pattern most in large organizations where the agile adoption effort starts with development and takes very slowly (if at all) the other centralized roles at the system/program-level.
It is okay as a starting point (one needs to start somewhere). Instead of a V-model, you still have the ends of the V on each side, with the agile/iterative lifecycle in the middle (hence the water-scrum-fall moniker).
The challenge is to "virally infect" the teams & functions living outside the agile team(s) so that the more the interact with the teams inside the agile iterations, the more the experience wins them over and pulls them in to the agile mindset, thus creating what I'll call the "agile vortex".
This frequently happens first with testers, and then (hopefully) with project and program management. Often it will stop there and never even get to program management/governance or beyond, and the walls get set in stone, never to be breached. But if you do it right and make good interactions with these groups that influence their behavior and attitude, then its often operations (devops) and even the "architects" that are next to be pulled in. (Unfortunately I too often see centralized CM as one of the biggest/longest "hold outs" here)
Re: Releases with a Little Glass of Water
by Rob Miles,
Your message is awaiting moderation. Thank you for participating in the discussion.
I understand your point on releasing frequently in large companies, but the point of Continuous Delivery as a practice is to ensure that the business is able to release as often as they want to without IT being a blocker - not to enforce releases on a business that does not want them.
Scrum Usually Can't Exist Without Water-Scrum-Fall...
by Tim Elton,
Your message is awaiting moderation. Thank you for participating in the discussion.
...Because Scrum is a sub-optimization of the engineering/development team. Not that I'm bashing Scrum--it was a huge step forward and deserves credit for breaking the mold. Many agile practitioners (myself included) are moving on (or have moved on) from Scrum to adopt lean principles. A holistic enterprise-wide value stream perspective is what Scrum is missing, which is why Water-Scrum-Fall is the norm.
Start Where You Are
by Mike Dwyer,
Your message is awaiting moderation. Thank you for participating in the discussion.
Thanks for pointing out the silliness of the "YOU'RE (a) SCRUMBUTT" red herring. It really doesn't matter where you start, be it bumping down the stairs in an ever doomed waterfall, or trapped inside a dogmatic dreamland of exactly correct Scrum or Agile. IMO, you are a bona fide Agilest and a pragmatic Scrumster if you and your team end each planning session with a commitment to measurably, incrementally, improve a bit each time out. The day you stop is the day you stop doing Agile, become part of the drag, and have a tendency to be a reactionary pain at both ends of the spinal column.
The interesting thing we see is when teams actually begin incremental improvement. The team's work patterns are so compelling that executives and leaders realize the biggest impediment to Organizational Agility is the processes and structures used to control how the work is done. They often find that at best the ‘rule’ or ‘muscle memory’ is followed with rote obsession; at worst it is a at the core of the hobbling an organization's capability to compete in the 21st century. In either case Agile organizations struggle to put this impediment in their backlog and either make incremental improvements, or get sucked back into the muscle memory they are trying to escape from.
Getting to escape velocity in an organization is ‘the’ challenge facing Agile and Scrum for the next decade. Books on the subject suggesting a couple of ceremonies, some unique labels, and a lot of hand waving are not going to get you there. We see success coming from coaches that have experience, setting a vision and goal, work to ingrain Agile and Scrum into the organizational DNA, and walking forward on pragmatic paths of success.
Re: Start Where You Are
by Chris Goldsbury,
Your message is awaiting moderation. Thank you for participating in the discussion.
Thanks Mike.
The Debate
by Chris Goldsbury,
Your message is awaiting moderation. Thank you for participating in the discussion.
What I'm wondering after reading everyone's comments is this: Is Water-Scrum-Fall a realization that scrum is not perfect and needs alteration to fit the fortune 500 of the world, or is Water-Scrum-Fall a poser's attempt to implement agile and therefore....fake and not worth recognition. Please comment further.
Re: The Debate?
by Mike Dwyer,
Your message is awaiting moderation. Thank you for participating in the discussion.
Chris
What debate? If you are looking for a silver bullet from Scrum, you better check this out.www.bigvisible.com/2010/07/scrum-is-a-silver-wh...
Settling for What You Can Get
by David Curry,
Your message is awaiting moderation. Thank you for participating in the discussion.
Forrester blames the "practitioners" for keeping Agile processes within their domain -- as if it were some secret that software developers were jealously hoarding to themselves. From what I have seen, Water-Scrum-Fall is practiced where the development team would like to work in more agile ways, but the groups who handle requirements definition, project planning and release management really don't care to. Lacking strong sponsorship from senior management and the clout to change processes in any other part of the organization, the programmers settle for what they can implement for themselves -- and often have to fight tooth and claw to hang on to even that.
I don't think of this as pragmatists winning. It's more a case of organizations losing.
Re: Releases with a Little Glass of Water
by Yves Hanoulle,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree that most companies don't want to have frequent releases.
I disagree with the reasons behind.
Usually it is because they have never tried and are afraid for new things.
When you do a continuous delivery, there is not need for training.
The changes will be so small, that users are learning it on the fly.