Like you, I was (still am) a traditional PM and a successful one at that. No success or validity of any agile principles needs to come at the expense of the validity of traditional methods.

It is more the case that some scenarios fit better than others for a given method. Outsourced projects (which is my background) are actually quite difficult to set up and execute using Agile due to the commercial constraints of budget and schedule that you find yourself operating within. One downside to living within these constraints is that the sponsor of a project always wants to know how the project is doing based on those two metrics. The sponsor sometimes does not or can not perceive or measure how the project is doing according to the scope and quality (fitness for use) dimensions.

I have seen this over and over. Any good PM worth their salt (and there are plenty of bad ones out there) can get requirements approved and then deliver on those requirements. The two tricky parts are:

1. Were the original estimates of effort any good? If so, you can probably get the job done basically on time and on scheduled. If you and your team are pretty experienced, you should be able to estimate the work pretty well. Again, there are plenty of people out there who are not very good at estimating.

2. Did the requirements the users give you actually reflect what they needed? This is the area where I see the most failure. I honestly think the requirements are significantly defective the majority of the time.

Experienced systems people can literally think in terms of requirements and design patterns as if it were a native language. Most business people or end users who are trying to speak that language are strangers in a strange land. They can’t do it. Therefore, the best a good PM can do in most situations is deliver on what you promised – even though that is not what the users need for their business. Thus the famous old research about vast percentages of waterfall projects being over-budget or not fit for use (bad requirements alignment) or simply failed.

It may not be a failure in your mind because you did exactly what you were asked to do, but the business person either has to pay more to get you to tune the system up once they start to better understand what they need or try to struggle through with what they asked for originally. Agile attempts to accommodate this reality by providing better mechanisms for input/feedback on the system you are developing for somebody. But, you are right, in order to do that, you lose the ability to stick to a fixed price.

Anyway, don’t discard anything you do that’s successful in the name of being ‘Agile.’ Just realize that some situations may allow or even require a few extra tools in your toolbox to help you get your end user what they need. Projects with a lot of novelty are hard to estimate and hard to get good requirements for – those situations require some prototyping or fatter estimates due to risk or perhaps even an Agile project method.

Dave is right about books. I like the ones he recommends and would also mention Craig Larman and Alistair Cockburn; those guys are great authors. Also check out Scott Ambler’s website and books.

Good luck,

Dave

Being traditionally a ‘Waterfall’ PM — and under such methodology bringing a multitude of application development projects to successful completion (most all within budget/scope/schedule) — makes me wonder the following:

In using the Agile Methodology, how can the PM ensure that the project will be within budget and on schedule?

From what I understand the Agile Methodology is flexible in that it provides virtual on the fly scope changes, however, in having such a situation, it seems almost impossible for a PM to be able to provide any reliable information as to the schedule and cost. Simply due to the fact that, based on ever changing scope requirements affecting multiple parallel bits, there seems to be no accurate way to reliably track changes in costs and schedule.

Do PMs constantly get re-estimates from all teams every time the scope changes? This would have to happen in order for the PM to maintain some semblance of a plan, in order to communicate to senior management and client the revised costs and schedule of the project.

It would seem to me that the Agile Methodology is mostly useful for development houses that are willing to absorb internally the changes in cost/schedule/scope that deviate from the initial desired goal of the project. There would need to be constant re-negotiation with the client and senior management for costs and schedule if multitudes of scope changes are introduced throughout the life of the project.
If you need to meet a hard deadline and required scope changes will push the project past said deadline, then the project risks being a bust if more resources won’t be adequate or can’t be found.

Such that, I believe Waterfall Methodology projects, while having some negatives, tend to be more predictable and perhaps better meet the needs of projects that require more strict cost, scope and schedule requirements.

Comments?

However, there is no reason to throw the baby out with the bath water. My belief is that planning and tracking are still essential to any project, regardless of the methodology.

I'm a seasoned Agile developer and PM and so I rarely use MS Project for anything other than as a very specific type of Visio.

However I still believe in a thing called Gantt …
http://blog.teameffect.com/post/Team_Effect_equal…

I welcome your thoughts on how this fits with your style of Agile management.

Regards

Jason

I thought your article was quite interesting, and as an Director IT who is trying to implement Agile development and a formal PMO at the same time, we’re definately struggling with how to pick the best tool set for managing projects in an agile context.

I have put a response on my blog (see URL) as I think that there are ways to use MS Project successfully in an agile context as long as you a) change the way you use the tooling to make it way more efficient (I have some suggestions on this on my blog); b) use GANTT charts at the appropriate level of detail (e.g. I agree that trying to put a bunch of micro-dependencies in your plan is overkill); c) use it more for macro-planning instead of micro-tracking.

See my blog post on the subject – would be interested in your experience and feedback.

All the best,
Chris Woodill