Agile? Me too or 2?

Craig Brown (Better Project) commented on my previous “Agile? Me?” post.  My main take away from the points he makes are that Agile, although not entirely new, packages software project management in such a way as to make it appealing to teams.

Other important points are:

• The command and control approach to software project management does not really work.
• A fool with a tool (or methodology) is still a fool or, in his words, “Smart people get it right. People that struggle with common sense will fail at this management system as much as any other”.

As previously stated, I see Agile as a different language or dialect of project management; I do understand that some (many?) project stakeholders do not “get” traditional project management.  I lost count of how many times I’ve been asked for a schedule only to have the person asking go totally blank when receiving it and then asking very basic questions about Gantt charts. 

However, talking with someone experienced in scheduling, EV, etc. you don’t get the blank stares.  This goes to say that speaking a language that all stakeholders understand gets you a long way down the path to success.

The aspect that is still evading me is, assuming that the Agile practitioner is not a fool or a micro manager, what is the economic benefit to the project organization that takes the Agile path?  Can I expect 15% shorter schedule, 17% lower cost, 8% lower rework, 21% fewer bugs, etc.?  The numbers are not that important but they would help me make a decision while investing my time and money training myself.

What do you think?  As always comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Comments

[Craig Brown]

Patrick

I posted something about defect rates last night, but here are some other numbers; we got about 4* as much features/functionality delivered with the same team in half the time as the team's previous project.

There is a lot in this but some highlights are (1) making decisions smaller for the stakeholders and (2) maintaining a flatter pace within the team (i.e. avoiding student syndrome on deadlines.)

[Patrick Richard]

Craig,

I saw your defect rate posting. I'd love to see that on my projects; maybe in aother life.

You are giving us interesting throughput numbers; what methodology was employed? Scrum?

Regards,

Patrick