Have the Pragmatists Won? Water-Scrum-Fall Is the Norm

Posted by Christopher Goldsbury on Dec 16, 2011

Sections

Enterprise Architecture,

Operations & Infrastructure,

Process & Practices,

Architecture & Design,

Development

Topics

Agile Techniques ,

Scrum ,

Agile in the Enterprise ,

Agile Manifesto ,

Agile

 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?

 

1. Back to top

   Releases with a Little Glass of Water

   by Stephen B

   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

   Reply

2. Back to top

   Agree

   by Adam Nemeth

   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

   Reply

3. Back to top

   Re: Agree

   by Vijay Nathani

   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.

   Reply

4. Back to top

   Re: Agree

   by Gaston Coco

   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

   Reply

5. Back to top

   Is it about winning or losing?

   by Amr Elssamadisy

   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

   Reply

6. Back to top

   Agile teams in a non-agile organization

   by Alan Dayley

   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.

   Reply

7. Back to top

   remember RUP?

   by Martin Kügler

   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

   Reply

8. Back to top

   Okay, as long as its a temporary stepping stone to grow the "agile vortex"

   by Brad Appleton

   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)

   Reply

9. Back to top

   Re: Releases with a Little Glass of Water

   by Rob Miles

   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.

   Reply

10. Back to top

    Scrum Usually Can't Exist Without Water-Scrum-Fall...

    by Tim Elton

    ...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.

    Reply

11. Back to top

    Start Where You Are

    by Mike Dwyer

    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.

    Reply

12. Back to top

    Re: Start Where You Are

    by Chris Goldsbury

    Thanks Mike.

    Reply

13. Back to top

    The Debate

    by Chris Goldsbury

    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.

    Reply

14. Back to top

    Re: The Debate?

    by Mike Dwyer

    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...

    Reply

• Older >