"Waterfall" is a Bad Way to Refer to Non-Iterative Projects

There are lots of new(er) PM methods out there now with XP, FDD, Agile PM, etc, etc. Most, rightly so, favor an iterative WBS 'design' that has the project going through multiple design\code\test loops rather than the 'old' way of doing a big design\big code\big test loop.

Practitioners of the newer methods tend to refer to the older methods as "Waterfall" PM. I guess this is because the Gantt chart for the old style project looks like a waterfall:

But think about it. What does a Gantt chart look like for the new(er) iterative methods?

It looks like 4 little tiny waterfalls! :-)

So I'm not sure what the 'old' way needs to be called but to call it waterfall is just wrong because the new method looks just as much like a waterfall as the old one does.

So here is the challenge: Email me at [email protected] with your choice for what the 'old' way should be called. (Now all you XP guys have to keep it clean. No bad language)

:-)

I will publish the best ones in a later post.

Comments

[Stu Charlton]

One way to make a gantt look appropriately agile is to schedule requirements, not tasks. Design->Code->Test in increments is what one would call "incremental" waterfal development. DCT-DCT-DCT-DCT in tight and amorphous loops is what agile is about, and since it's an empircal process, it shouldn't be in a plan. Rather, the priorities and estimates of the requirements should be in the plan.

[Glen B Alleman]

Reg,

All things are possible, but defining a context narrows the options. Here in the spacecraft business, agile processes are used along side of full IMP/IMS contract milestones. Using MSP as a communication vehicle as well as the soruce for BCSW/BCWP is common. At the "program" level MSP provides the foundation for connecting all the sub (IPTs) together in one place - MSP Pro 2003 running over Cytrix links as well as PWA.

Once we get down to the task level agile process take over (where appropriate) and MSP then provides the "begin/end" boundaries for the incremental deliverables.

An alternative question about tools is "are they compliant with corporate and customer demands?" MSP is along with Cost and Project View, SAP and RTP.

[Reginald Braithwaite-Lee]

As a manager you can use any tool or tools you like, even Microsoft Project. This parallels the "real programmers can write FORTTRAM programs in any language" boast.

However, the question about tools is not whether you can use them, but what they facilitate. Naturally you can estimate the project out and "refactor mercilessly." However, in most environments you will discover that once you have shared a GANTT chart with executives, you have just made a collection of milestone commitments. And then you may find yourself endlessly justifying deltas to the "baseline plan."

This is part of why I prefer to use a Scrum-like presentation of prioritized stories with estimates rather than tasks with dependencies.

YMMV.

[Glen B Alleman]

Brian,

My experience with agile uses project plans as "book ends" for the iteration. The itertaions are fixed duration. The Planning Session takes the story cards allocates them across the itertaion. So each iteration is shown as a fixed duration task in the schedule.

The schedule in this environment is used to show dependencies "outside" the agile project - in our case XP.

The feedback aspects can't be shown in circulatr manner...

www.xp123.com/xplor/xp0202/xp-one-page.PDF
and
xp123.com/xplor/xp0401/Scrum-dev.doc

are simple overviews with the loops.

RE two other things:

At the execution level (XP iterations) the developers likely dont see schedules, they see story cards.

Agile is "execution," the "state of mind aspects" may be necessary but they're far from sufficient.

[Brian Kennemer]

This is exactly the thing that most confuses me about agile methods as I have seen them discussed: The idea that if it shows up on the Gantt chart it is cast in stone! I show the next iterations on the Gantt chart because I KNOW they will exist, I think they will start at ABOUT this time and I think they will take ABOUT this long. Future iterations are a guess, just like anything on a Gantt chart is a guess.

It seems like Agile is a state of mind. I create a Gantt chart based on my current understanding of dates and effort levels\durations. I do my best to make sure that understanding is as educated as possible. But as we go on things change so I change my chart to give me and the others in my organization a new, more clear understanding of whats up with my project and it's projected use of time and people. It could change a lot and I will keep updating the schedule with changes.

That sounds "Agile" to me. But some of the conversations I'm having now seem to imply that Agile PM means that you don't make any schedules because they might be wrong! :-)

I hear lots of things about this and it still seems like 'being Agile' just means being a PM that updates their assumptions and does not assume that their first swag at the schedule is 100% correct.
:-)

[Reginald Braithwaite-Lee]

I call the old style of project management "monolithic" and/or "clasical". The agile style is "iterative".

I don't quite agree with the second waterfall-ish chart shown. The reason you have lots of small iterations is that you "don't know what you don't know." Therefore, if you can actually build the GANTT chart from the beginning with lots of iterations and milestones, you are starting with the assumption that you know what will be done and how long it will take to a great deal of precision.

I'm not saying this won;t work, I'm just saying it is not very "agile".

[Glen B Alleman]

Brian,

The second chart is still waterfall I'm afraid. The feedback loops needed for agile projects are difficult to display in MSP, since they would create a dependency "loop".

The spiral approaches found here in aerospace are about as far as you can get with MSP. True agile projects are difficult to represent in a linear tool like MSP. The best that can be done is to de-loop the project with end of iteration tasks that plan for the next iteration.