To quote one respondent to my last blog post on whether agile projects should mix Scrum and waterfall: “I have been on projects within the U.S. government where they tried to do both when saying they were doing Scrum, and it was a disaster.”
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Here is further explanation from the reader as to why Scrum and Waterfall is a bad combination:
The key issue in my opinion is that Scrum is a bottom-up communication process and that waterfall is a top-down communication process. In Scrum, the developers doing the work have their meeting, and that generates what is to be accomplished along with issues that have to be dealt with. This then rolls up to management, along with product owners, to make decisions about what will [work], what won’t, and help move obstacles out of the way. Waterfall is all about leadership telling everyone what they need accomplished, and meetings start at the top and come down. So issues in the trenches take longer to get back up, and it is more about low- and midlevel managers protecting themselves and driving the end workers to get things accomplished, then about figuring out what can be accomplished and passing that back up.
On the flip side, one project manager created what he calls the “Envelope Method,” which folds agile practices into waterfall, but he freely admits that it will shake up your organization. (Listen to a presentation that he gave on integrating agile into a Waterfall world during a recent Project Management Institute San Diego chapter event.)
Then there is the opinion that waterfall makes sense for certain kinds of projects, and Scrum others, as one reader explains:
Using the NASA cone of uncertainty, where uncertainty is high and learning must take place, a fail-fast approach is required, Scrum is put in for these parts. Where little or no uncertainty exists such as buying a completely set-up PC from Dell, waterfall can be used.
It all comes down to uncertainty due to:
- Rate of change.
- Complexity, both individual and overall.
- Interrelationships and dependencies.
- Lack of understanding how X provides value to [the] organization.
- [The] need to build individual and team competence to obtain individual and team confidence.
I will be following up with many of the people that emailed me. Some have traditionally used waterfall project methods but are trying to adopt/adapt some agile project practices into the requirements, development and testing phases.
I’ll be posting an update after these conversations to share what I learn about agile projects and the practice of mixing Scrum and waterfall.