CIO Symmetry

A SearchCIO Small Business blog

» VIEW ALL POSTS Jun 24 2010   6:25PM GMT

Reactions to Scrum and waterfall mix for agile projects



Posted by: Christina Torode
Tags:
CIO
scrum
waterfall

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

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.

2  Comments on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Josephflahiff
    Christina, Thanks for pointing folks to my recording. While I didn't focus on it in the San Diego PMI talk. I totally believe that waterfall is right for some projects. I have been a traditional PMP and doing traditional waterfall projects for the past 15 years (well 10 years PMP). I totally agree that Waterfall makes sense. I don't want anyone making an artificial heart iteratively! In the associated slide deck for the San Diego PMI show I have a slide that lists[A href="http://whitewaterprojects.com/2010/05/18/san-diego-pmi-confernce/slide9-2/"] 4 key Values[/A] that might drive you to want to use agile on a project. Using agile is distinct in my view from BEING agile. Peace Joseph Flahiff www.whitewatreprojects.com
    0 pointsBadges:
    report
  • SRIINIVAS
    I have had the experience of working on both low level languages and business software. I found that if one is writing a program for a business process then this process is broken down into smaller tasks interconnected and the best approach would be to use the waterfall model by forming a framework and then going deeper. However, if your plan to write functions for libraries e.g draw a square, then for this you need to first draw a line successfully and here the scrum model would work much better. We could take whichever approach one is comfortable with but always ensure that you follow best coding practices, have code reviews and ensure high and low level testing for best results.
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: