A new year is here and one of the top trends for 2011 will continue to be where Agile project management is going.
In a recent blog post by Bernardo Tirado his top trends in project management for 2011 includes a statement about Agile software development:
Project management organizations embracing Agile software and product development approaches will continue to grow while being faced with the challenge of demonstrating ROI through Agile adoption. In addition, they will need to disabuse their stakeholders and executives of the expectations set by IT consultants, the media and the vendor community that Agile is the next “silver bullet.” Organizations that do it right – including selecting the right projects for Agile – will reap significant rewards.
The key is selecting the right projects for Agile project management … but how?
Recently, I attended the Madison PMO Manager forum where we discussed this topic. One member mentioned that his organization completes a risk assessment on the project to determine if it is the right fit for Agile project management. Others indicated that it works well for small projects (making a web app) with small teams that are co-located.
You selected a project but how to you measure it?
This is where it gets interesting. A PMO has many metrics it tracks its projects for, but with Agile project management you typically only have a burndown chart that is really nothing more than a chart showing 100% down to 0% complete.
We want more, right?
One way to make measurements is to use the Agility Measurement Index which scores developments against five dimensions of a software project (duration, risk, novelty, effort, and interaction).
A second way to is track the goals that are set for the project. Without objective measurements you are just guessing!
Why does Agile project management work?
1. The stand-up meetings holds your team accountable.
2. Rapid development of semi-functional software allows you to keep the project going in the right direction and there is less of a chance of it going down the wrong path.
3. Having experienced developers that have coded similar items and expert users as your primary stakeholders will help to keep the project focused.
4. Do the right things! If the post-it notes methodology works and is appropriate for your project stick with it. If you are developing software that is regulated and you need some or a lot of documentation, make sure you create the necessary documentation. You cannot have a one-size-fits-all Agile process.
“The agile processes that are successful have players that "know" what to do from skill and experience.” -Glenn Alleman
The main reason why Agile works is that, unlike previous approaches, it does not rely on flawed assumptions about the "definition of done" and predictability. The best recent talk I've heard is http://confreaks.net/videos/282-lsrc2010-real-software-engineering.
ReplyDeleteWhile we're making predictions, mine is that many Agile adoptions by the Early Majority will fail, and here's why: http://www.ufunctional.com/2009/01/30/load-bearing-walls/.
I left an organization that moved to Agile development. It was not a success. The Application Manager would remove incomplete tasks from the sprint to make the burndown chart look good to upper management. We almost never had "shippable builds" at the end of the sprint. The post-mortems cleared a lot of air but were forgotten at the start of the next sprint, where we only got it all wrong all over again. We continued to underestimate tasks and build too much into the sprint. Again and again and again. The only thing that I think "worked" was having the daily standups, which left me, the Business Analyst, able to steer the project back on track when I heard the developers running amok. I will avoid Agile at all costs based on this one experience. It was a nightmare.
ReplyDelete