Project Management on Agile Projects (part 1 of 3)

 Over the past three weeks I’ve been fortunate to be selected to speak at three different conferences.    Toronto Agile Tour 2010, PMI-CTT Symposium in Waterloo and this past week at the Agile Vancouver Conference.  My topic was basically the same at all three, but turned to suit   my audience.   The two Agile conferences heard the message of what benefit project management brings to Agile projects.    The PMI group heard me talk about extending their PM career by learning what it means to be agile, and then apply it to the ways in which they behave and conduct their business.

Rather than doing this as one big blog entry, I’m going to split this topic over three weeks.  It’s easier for me as I can spread the work out, but more important it’s easier for you to read something short in your busy life.

The following are Mike’s six tips to being an Agile Project Manager.   If you’re interested in the other message (what benefits project management brings to agile projects) please contact me and I will be happy to pass it along.

Tip #1 – Figure out what is truly valuable to your customer

A company once set out to build their customer a drill.   They started working on it, and before long they were having lively discussions with regards to the design of the drill.   They would debate colour, materials, chuck type, power source and many other details at great length.   It took months to deliver the new drill, and the team was very proud of their accomplishments!  So did this company deliver value?   Not really as all the customer really wanted was a hole!

What needs to be done first is to figure out what is valuable to your customer.   I’ve come across many IT people who believed their customer actually wanted to work with them.   This is a dangerous attitude, as it leads in the wrong direction.   The business comes to work each day wanting to make their business activities successful and they need tools to do this, which is where IT comes in.   IT makes a business out of enabling our customer's success.    With this notion in mind you need to seriously examine everything you do, and question the value it brings to your team’s ability to deliver value.    No one ever ran their business with your project schedule, requirements document, or project plan.

These artifacts do deliver the ability to enable effective delivery of value for your customer, which is why we continue to build and deliver them.   They’re important, but don’t lose sight of the fact they are not what the customer sees as providing long term value.

Tip #2 – Stop imaging you can predict the future

In the past I’ve prided myself in creating detailed schedules.   I took a year and focused on improving this skill, and I can now work MS Project in all kinds of ways (yes including leveling successfully).   About 5 years ago I had a work assignment in downtown Toronto.   I would ride the VIA train there 2-3 days per week, and during that time I primarily worked on my schedule.   It was a great schedule, with hundreds of the tasks clearly laid out and connected together in the perfect network structure.   With this schedule I thought I had perfect control of my project … WRONG!  I only had the illusion of having control, and the evidence of this is how much effort went into adjusting the schedule as it simply didn't reflect reality. 

Instead of creating detailed schedules, give your team some ownership on this front.   Find a better balance by providing them a framework from within which they can self organize and figure the details out themselves.

On a recent project I created a schedule out of flipchart paper, and post-it notes.   I created a giant grid with the far right of the grid representing our time box which we could not exceed.   We established further constraints inside the schedule, which could not be broken (e.g. No single person’s activity could go more than 2 weeks duration).   Every morning we would conduct a 15 minute stand-up meeting, and would use the schedule on the wall as our focal point.   At the start of the project I was secretly concerned about how on earth I was going to effectively control my project if I didn’t have a detailed schedule.   However, I have never felt so in control of my project as I did that time.

I’ll draw on the Agile Manifesto principles to explain why I believe this happened:

“Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.”  

Try it … it works!  

Next week:

Tip #3 - Stop thinking your customer can accurately tell you what they want in detail at the start of the project
Tip #4 - Don't just communicate ... collaborate!

Until then ... be agile!

Mike