Forums

As I see it, both are good processes for different types of projects....and I'm pushing our organization toward using both processes. A project manager would get a request for functionality, and would either add it to a relevant backlog, create a new backlog, or treat the initiative as a waterfall project.

Yet the project management tools available seem to either cater to one or the other. Why can't I use both? Do I have to purchase two separate toolsets?

If anyone knows of some good PM software that is flexible enough to accommodate both, please let me know!

Thanks!
--A

mtietel's picture
Training Badge

Don't tell the Agilists, but Agile "iterations" are just mini-waterfalls... When you get out of the trees and look at the forest (your unit tests aren't the only form of tests, right?), you're still doing requirements-design-code-test.

Even on BIG goverment contracts they're not trying to define it all up front and get it right the first time. They're doing it in phases.

The argument is just over how big/long the iterations should be...

pmhut's picture

mtietel,

My opinion is that you're right, check this article about [url=http://www.pmhut.com/can-we-combine-agile-and-waterfall-development-stra... agile and waterfall[/url].

jhack's picture

While an agile iteration may be a "mini-waterfall," there are important differences between Agile and Waterfall Projects. Waterfall projects assume that all (or most) requirements can be understood before designs can be created, and that coding follows both. This assumes a high degree of certainty regarding the requirements. Agile assumes that the requirements are not knowable until a working version of the system is created.

This has SIGNIFICANT implications for cost and time estimation. Agile tends to be "time boxed" (using the Iron Triangle metaphor of time/features/cost). Waterfall tends to be "feature fixed." There are ways of mitigating the issues of waterfall (phasing to determine scope, etc) or of Agile (strong design reviews to avoid poor early choices).

Both methodologies work best when applied appropriately.

Why do you need one tool for two different jobs?

John

alec4444's picture

[quote="jhack"]Both methodologies work best when applied appropriately.

Why do you need one tool for two different jobs?
[/quote]

Agreed. They both track differently as well, have different types of documentation, different methods of resource allocation.

Essentially, I was hoping for one tool for a couple of reasons:

1) Cost, of course
2) Ease of use, training
3) One place for resource allocation. Developer "A" is on project X for the next six months. After that, he'll be working on Sprint Y for one month, whose start date is dependent on project X....
4) One place for management level status of all current initiatives, waterfall or agile

There's enough similarities in the processes to warrant a toolset that can support both. But these PM software companies have either chosen to embrace one or the other. Instead of producing something flexible, their sales approach is to tell you one is better than the other. (i.e. "You're doing it all wrong!")

We could probably use one tool suited to one or the other and then kluge our way through on the opposing process. I was just hoping there was some kind of software company out there that had figured out that neither process was "wrong".

Borland Management Suite tried (http://www.borland.com/us/products/team/team-focus/index.html) but it seems to be more of a reporting / analysis tool that's meant to piggyback on other PM software.

Cheers!
--A

pmhut's picture

If I understood your question correctly, then the answer would be getting the best of both worlds (agile and waterfall don't have to be mutually exclusive, I'm being fairly objective). You can get the flexibility of Agile and the control of Waterfall. I think every (seasoned) Project Manager follows a certain methodology derived from 1 or several other methodologies. I remember having a conversation with someone on the phone, who is in my opinion, an excellent Project Manager, and he told me that the whole idea behind Project Management is not about a methodology here & there, but it's about getting the job done. And quite frankly, I believe in what he said...

erikko's picture

so far, to sum up this conversation, why do you need to chose among the two if they can work together?

suedavis's picture
Training Badge

[quote="mtietel"]Don't tell the Agilists, but Agile "iterations" are just mini-waterfalls...[/quote]

No, actually, they're not, unless you're doing "scrummerfall," which is one of the least effective forms of agile process.

[quote]When you get out of the trees and look at the forest (your unit tests aren't the only form of tests, right?), you're still doing requirements-design-code-test.[/quote]

We do idea-test-requirements-test-code-test-design-test; other flavours of agile may vary. The four things that you mentioned are happening, but the way that we get there is not fundamentally similar.

bruce's picture

Hi Alec,

[url=http://www.e-lm.com]e-LM.com[/url] is an online tool that supports both waterfall and agile methodologies, even on the same project.

Cheers,
Bruce

mtietel's picture
Training Badge

[quote="futabachan"]We do idea-test-requirements-test-code-test-design-test; other flavours of agile may vary. The four things that you mentioned are happening, but the way that we get there is not fundamentally similar.[/quote]

Hi Susan, It was nice meeting you at the Chicago Conference.

Preface - I'm not a methodology bigot and was speaking of content rather than form.

What form do your "tests" take after your "idea" and "requirements" phases? Can you elaborate on your "design" phase? (Since "code" comes before "design", does that imply that developers don't evaluate design choices *before* they write code? or is it more making the design "self-evident" by mercilessly refactoring to clean up code smells after "code"?)

Thanks,
Mike

ericgear's picture

These are two opposed techniques. So I don't think you can use both of them at the same time. [url=http://www.methodsandtools.com/archive/archive.php?id=43]Here[/url]'s a good article where you can find some info about the history of agile.
It might be good thing to combine top-down and bottom-up management though. These are not pm methdologies of course, they are bigger notions. But when you combine the best elements from both of them, i.e. control and collaboration, results can be great. [url=http://www.wrike.com/projectmanagement/02/07/2008/Top-down-and-Bottom-up...'s a post [/url]about it, that might seem interesting to all of you, folks.

jcol's picture

It's been my experience that true agile development can only be successful with high performance, tightly coupled, dev-test teams-- highly automated/adaptable tests. Where does PM fit in? You adapt and organize the game into short, manageable releases - delivering x features at each release. Forecasting costs/schedule +/-50%. The more you work with the group. The better you get at forecasting. You only know high level features maybe more for first release, you let them start to code and it evolves. You move obstacles and let them do their thing. Works best, small software companies/groups. I'm confounded in the IT world how agile could fit in. The concepts of tightly coupled, highly automated dev/test seem impossible.

erikko's picture

[quote="bruce"]Hi Alec,

[url=http://www.e-lm.com]e-LM.com[/url] is an online tool that supports both waterfall and agile methodologies, even on the same project.

Cheers,
Bruce[/quote]

that's a good share, i never thought that this can be together

cosmicrider's picture

In a large corporation, where hundreds of projects need to be tracked, the corporation determines the tracking method. Traditionally, that tracking method is waterfall. Funded projects get entered into this overall management tool and then tracked by high level executives. It has nothing to do with how the individual project is managed, but everything to do with how the project is tracked.

In this case, how do you match Agile on the Project management side with waterfall on the tracking side? this is the issue that we struggle with.

PierG's picture

alec4444,
the agile practices were born mainly to cope with what are called 'extreme projects'. Extreme projects are those projects where the rate of change is huge and/or the resources are really scarce and/or the risk is impressively high. If you are not in one of these situation, there is no need to leave a more traditional approach.
To tell the truth I would never suggest a pure waterfall: it simply doesn't work. I always prefer an iterative / incremental approach (feedback feedback feedback).
I hope it helps,
PierG

bruce's picture

[quote="cosmicrider"]In a large corporation, where hundreds of projects need to be tracked, the corporation determines the tracking method. Traditionally, that tracking method is waterfall. Funded projects get entered into this overall management tool and then tracked by high level executives. It has nothing to do with how the individual project is managed, but everything to do with how the project is tracked.

In this case, how do you match Agile on the Project management side with waterfall on the tracking side? this is the issue that we struggle with.[/quote]

Hi cosmicrider,

It is basically a question of what you measure.

In a traditional waterfall model there are a number of things that you might measure to determine the overall progress of your project. For example actual expenditure vs. budget forecasts; Actual effort vs planned work breakdown structure; Number of features implemented.

In the agile world the time is fixed. The budget can also be fixed by setting the maximum person-power you are going to allow on the project. Assuming you want the best quality, so that is fixed as well. The only variable left is the scope (or requirements).

To measure requirement implementation progress you use a burn-down chart showing the overall number of outstanding requirements. The rate of burn-down (i.e. the slope of the chart) can be extrapolated to give you an estimate of when you will finish all of the requirements (or how many requirements will be left when you run out of time.)

flod's picture

Check out Hansoft at http://www.hansoft.se. The tool let's you choose to work in agile or waterfall plus it's got some great reporting and tracking information built in. We've been using it for a few months and have found it to be a great improvement over the homegrown tool we had been using.