Have the Pragmatists Won? Water-Scrum-Fall Is the Norm
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?
Releases with a Little Glass of Water
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
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
Is it about winning or losing?
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,
Agile teams in a non-agile organization
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.
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"
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
Scrum Usually Can't Exist Without Water-Scrum-Fall...
Start Where You Are
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: The Debate?
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
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
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.