"It's a phenomenally bad practice, but so many people are doing it, they think it's a good idea." So says Scott Ambler, Chief Methodologist for IT at IBM Rational, about the anti-method known as water-Scrum-fall.

Recently coined by David West, a senior analyst at Forrester, the water-Scrum-fall term describes the "goofy" manner in which many organizations are managing the design, development and deployment stages of the application lifecycle. 

Water? That's a throwback to the traditional method of application development where all of the detailed work such as requirements gathering is done up front in the early stages of the project. Scrum? That's the Agile process that's only allowed to fester until the traditional requirements gathering and up-front work has been completed. This is as Agile as the water-Scrum-fall aficionados will get, despite the fact that they're pretty sure they're being Agile from start to finish. The 'F-Word' in the water-Scrum-fall anti-method is the old-school mentality that stifles the agile process by taking over the deployment process, damming up the Agile flow of quick releases, essentially cutting the Agile process off at the knees.

Scott Ambler says he's witnessed the water-Scrum-fall phenomenon first hand. "Organization will have this questionable requirements and architecture process up front where they think everything through and do a big, detailed requirements spec. Then they'll throw it all over the wall to a development team who will then work in an Agile manner. That team then hands off into the release process which will be this screwed up traditional thing that takes several months because the release guys don't trust the development guys."

Sympathy without tolerance

Of course, Scott Ambler isn't completely without sympathy for those who have found themselves wondering WTF after suffering through a WSF process. "It's often a cultural thing." Says Scott, indicating that organizations who have traditionally embraced a waterfall method struggle when making the move towards being more Agile. But being sympathetic doesn't imply tolerance. "We’re pretty adamant about desperately avoiding this goofy up front stuff and this goofy back end stuff."

The bottom line? You're either Agile or you're not, and if you're not, don't mess things up further by trying to squeeze in Agile methodologies where they won't be helpful. Water-Scrum-fall is not a happy median between Agile and traditional methodologies. As Scott Ambler says about water-Scrum-fall, "We definitely don't want to be promoting this."

Scott W. Ambler talks about water-Scrum-Fall

I've never been a huge fan of black and white mentality. Water Scrum Fall definitely describes the methods employed in our service and that's our reality based on the many different departments that have their hands in the development lifecycle. Would it be better if the development team didn't work their portion in a iterative fashion; demonstrating product development every few weeks?

Your post describes our requirements input and deployment output perfectly; moreover, it seems to me we are winning friends and influencing people with our development teams following a sprinting process that demonstrates the product every few weeks. I think we would be a lot more agile and cost effective if we gathered requirements and delivered the product using an Agile method, but that is out of our hands. I don't believe squeezing in a sprint method for the development teams is messing anything up. If anything we have been able to provide visibility into the velocity of the development teams and predict when our development release should be completed. Furthermore, sprinting has provided empirical data and timely validation for resource capacity planning, defect management, and business validation.

True as it is; I would not want to promote this method, but it has delivered small levels of success and gained the recognition of executives who have the power to influence change across the organizations departments that are still reluctant to change. Agile is a paradigm shift to some cultures, and although not preferred, it is a step in the right direction validating the methodology and increasing buy-in at all levels.  Public sector organizations are constrained by budget and compelled by historical practices, consider it a transition state to breaking the mold to minimize the pain! Life is a journey not a bit switch.

I sympathize what you've experienced. I've also seen exact example of this albeit in a slightly different way: the water-water-water-fall. Where teams believe they're doing iterative development, trying to be agile, but end up doing _complete waterfall_, and I mean entire "complete requirement" (When I mean complete, I mean entirely dotted i's, crossed tees, signed off, multi-team reviewed, you do not code if you cannot trace it to a requirement x.x.x style) waterfall style, while they're still essentially in prototyping phase. Dragging out the entire prototype methodology, which is supposed to be proactive and fast to react, to become a giant behemoth that takes on the size of a project itself.

What I've seen work, in situations of Water-Scrum-Fall, is not to change the culture (that'll introduce too much shock into the system and may kill the patient); but to shrink the relative size of the ends. Make Water phase really small, let the req phase be completely brief and convince the business it's ok to start with however brief spec -- Make the Scrum cycle your real one [which also means it needs to produce the real spec at the end of the cycle], and extend the  scrum team's responsibility to include fully deployed solution on production - 1 environment [or even production mirror if that exists] -- and your "fall" is really the final check to push to prod.  That way you've tricked the WSF pattern into wSf, which is one that sort of works...

He is a Fellow of the International Association of Software Architects, an Eclipse Process Framework (EPF) committer, and a Jolt Judge at the Jolt Awards. -Dr. Marla Ahlgrimm

I am a proponent of using the right tool for the job. When all you have is a hammer, the whole world starts to look like a nail. Conversely,  a precision tool like a screw driver is worthless for driving nails. I am equally annoyed with pushers of a methodology when they say that's the way we've always done it or this new method will solve all your problems.

For small teams, Agile methods (and I don't mean just Scrum) appear to offer a significant advantage over traditional waterfall methods because the team can be agile. Collaboration develops a better solution than the siloed throw-it-over-the-wall approach. Early feedback steers the whole solution toward the constantly shifting problem. However, for multi-year corporate initiatives where their are annual budget cycles, scores of departments with hundreds of stakeholders, other dependent projects and executives who don't really care how you get it done as long as it provides value to the company, a certain amount of phased approach, development tracks or even waterfall is necessary to maintain control. Now even in that environment, an individual subproject can be run within a set of constraints in a purely Agile way.

In my experience, a team of about four to ten technical staff guided by a small, knowledgable team of business specialists can accomplish significantly more in a shorter period of time and hit the goal better using Agile methods. But, the development team and the business team must act as one team to accomplish the goal and they must all be committed to using Agile methods. Everyone has to be able to perform several jobs. Everyone has to know their piece really well and also understand the big picture. One anarchist will kill it. Too much democracy will stall progress. It has to be agile. This method also works best when the goal is not nailed down or when several options are available. Trigger: if a business person ever says "I'm not sure what I want but that's not it.", you had better call your Agile Expert.

Once the size of the stakeholders reaches a certain critical mass (about 25 maybe), Agile techniques allow too many people to offer suggestions about what should be done and how it should be done. I believe this is mostly caused by the team having different levels of understanding about Agile methods. Granted the solution will probably be better than if only a few gave input. However, if the team is kept small and those dedicated individuals sincerely ask for feedback from the larger community as each iteration is complete, then the process moves forward and feedback is obtained.

Waterfall is useful when dealing with budget cycles. Businesses have cash flow (or burn rate) issues. Everyone involved might be able to generate a great return on investment but there simply isn't enough cash available to accomplish it. The solution can be to break it into phases and run each phase in an Agile way under the constraints of time and money. Another reason to use waterfall is when "that's the way we've always done it." Did you know that it takes more than two miles at full reverse speed to stop a supertanker carrying a full load of oil? What is the minimum turn radius for an aircraft carrier? There are efficiencies in running a big ship. You'll never convince some executives (nor do I think you should try) that their supership business would run better if all 25,000 employees operated in an Agile manner. You have a much better chance convincing a thoughtful executive that their giant corporate initiatives should state the goal and then give small teams a chance to move the business toward that goal one step at a time. I think most importantly, customers of corporations don't like really fast change. Sure they want to see progress but it takes a certain amount of time for loyal customers to see the benefit of the change.

All I'm suggesting is to not throw the baby out with the bathwater. Each of the management techniques has a place because there are multiple problems to be solved. Use the right tool for job. Learn about the tools you have and consider a new tool when a new problem occurs. But don't jump onto the next silver bullet train…it may not be going where your strategic vision is taking you. On the other hand, there's nothing wrong with taking shortcuts to accomplish objectives while keeping your sights on the long-term goal. I am an Agile Expert but I also work quite well in large corporate environments.