Project Management on Agile Projects (part 3 of 3)

In my last two blog entries I shared the first four primary points I made during presentations in the past month.  This has been a great experience, and I've certainly enjoyed talking with so many people.   The effort has been worth while as it's opened up so many great opportunities to learn and expand on my view of software development in general.

In the first two blog entries I shared tips 1-4 for being an effective agile PM:

Tip #1 - Figure out what is truly valuable to your customer
Tip #2 - Stop imagining you can predict the future
Tip #3 - Stop thinking your customer can accurately tell you in detail what they want at the start of the project
Tip #4 - Don't just communicate ... collaborate!

Here's the last two from my presentation:

Tip #5 - Be lean!  (aka eliminate waste)

Last year I had the opportunity to attend a Mary Poppendieck workshop on Lean Software Development.   Lean is a concept coming out of the manufacturing sector, but applies to what we do in software development as well!   Mary defines waste in software development as:

Extra Features

• Unnecessary Documentation - Your customer cannot run their business with project documentation.   Documentation is a necessary tool for effectively managing projects, but unfortunately too many organizations have taken it too far.   Rather than creating more detailed documentation, look to replace it with collaboration.   Also examine the timing of documentation.   It's always cheaper to document something which exists, rather than documenting something which doesn't yet exist
• Extra Steps - look at your software development processes.   Are there extra steps inserted for the sake of process?   Break those down and create the most efficient process possible, with the fewest steps required to assure good quality products.
• Finding information - it is wasteful anytime someone needs to search for information.   If you find members of your core project team in particular are searching for information through the documentation, you should examine how effectively you're collaborating (or not).  
• Defects not caught in testing - any defect creates waste regardless of how soon you catch it.  The most effective way to deal with defects is to create an environment which doesn't allow them to be introduced in the first place.  For many of us this is a goal somewhere in our future, and until then we need to continue finding them less effectively.   However, do strive to eliminate them before they cross from one domain to another.  Is there a way your team can collaborate with the developer to find more defects in unit testing?
• Waiting - every day your customer waits for a new feature is wasteful.   So rather than forcing them to wait months for a complete set of new features, strive to deliver it incrementally throughout that period of time.   Your customer will be able to start using the new features incrementally and starting building value immediately.   The other significant benefit of this incremental approach is your customer will learn what they really need as a result of using the features. 
• Handoffs - this one is so obvious I wasn't paying attention!   Any time your team has to pass work from one person to another (especially when it's being passed outside the team), you create waste as the new person needs to come up to speed.    Work to bring as much of the knowledge required to build the product right into your team.   This can be difficult in many enterprise environments, but reduce the handoffs as much as possible.   In situations where your team must do a hand-off, don't let the team lose sight of the fact they still own the project work so they need to take the initative to stay in touch with the person it was handed off to.

I could write a lot on this topic.   However, I'd highly recommend you pickup Mary's books and go through them. 



Tip #6 - Learn & Improve!

For me this is one of the most important concepts of being an effective Agile Leader.   You need to help your team learn continuously and apply those learnings in their work immediately as they move forward with their work.  An effective means to do this is to host regular retrospectives.  My preference is to host them at the end of each week, before they have a mental break (ie. the week-end) and they forget everything they learned.

One technique for doing this is the perfection game.   I’ve adapted this from a vendor I work with, but ultimately it came from Jim McCarthy.   The concept is very simple.   On the whiteboard draw three columns with the labels “What worked great this week”, “Score”, and “What would have made this week perfect”.  Each and every team member is required to attend and participate in this activity.   I usually start as often people have a fear of being first (over time you may find your team changes this).   In the first column I write 2-3 things which I thought were great in the past week.   Keep it brief and clear, and avoid the temptation to tell big stories.   In the second column write a score from 1-10 (whole numbers only) where 10 is perfect, and 1 is at the level you couldn’t imagine it being worse.   This is a very subjective measure of mood so do not try to over analyze it.   Finally in the third column – if you did not score a 10, then you MUST provide suggestions for what would have made the week a 10 (ie. perfect).  

If you use the perfection game effectively a team of 8-10 people can get through this process in 15-20 mins.   Some tips to help with your success are:

• Do not allow debate to start – clarifying questions are acceptable, but that is all
• Do not track long-term trends on the scores – last week to this week is all that is relevant
• Do this as a stand-up meeting – it will keep the meeting moving and focused rather than letting people sit down

That concludes Mike’s top 6 tips for being an agile PM.   Unfortunately there are no silver bullets, only experience and great ideas to build on.   If you stop to view the work you do as a journey (not a destination) you will have a better chance of success!

In my next blog entry I will talk about my view of Symetrical teams!

Until then … be Agile!

Mike

Project Management on Agile projects (part 2 of 3)

In my last post I started to summarize my presentations over the past month.   Now that I'm a week later, I continue to be very happy about the results of my presentations.   I'm starting to hear feedback from the presentations and it appears at least some of the people in the rooms received value for the time spent.

In my last post I shared 2 of the 6 tips I provided to help PMs understand how they might be Agile.  They were:

#1 - figure out what is truly valuable to your customer
#2 - Stop imagining you can predict the future

In this posting I would like to share the next two points:

TIP #3 - Stop thinking your customer can accurately tell you in detail what they want at the start of the project

Have you ever found yourself in the position of having a 'solid' scope statement at the start of a project?   You've put a considerable effort into ensuring you clearly understand exactly what the customer wants, detailed in a document that has been signed off by the sponsor.   You've detailed scope in terms of what is in scope, out of scope and possibly what is unresolved at the time of writing.   Then as your project progresses you find yourself writing many change requests to alter the details of the scope.    Was your project a success?   I used to think so!   On very large programs I would have lots of change requests, and I prided myself that the customer wasn't suprised by the results.   However, I now wonder how much value we left on the floor as a result of having to cut scope so significantly in some cases.

Since I've adjusted towards to be more Agile my project experience is foreverr different! At the start of this year I led an Agile project in which my scope statement was very simple.   The scope statement merely said to add a business feature and supporting functionality.   It was a very vague statement, but turned out to be the best one I ever wrote.   We delivered what the business required and exceeded their expectations!

What you need to find is a way to manage the scope of your project.   I used a technique taken from a webinar put on by Allan Shalloway from Net Objectives:  Webinar.   Within the webinar you will find Allan talking about a technique for managing the scope using front burner, back burner, fridge and freezer.   We adapted it, but basically used this technique to put scope control into the hands of the customer.   The experience was great!

(note:  since my presentation I've had conversation with Allan Shalloway who says this is an old technique he no longer subscribes to as he's transitioned to the use of Lean-Kanban techniques.   That's OK though, as we're just starting our Agile journey so old techniques were probably an easier step for us.   Besides ... results speak for themselves!   I am now studying the Lean-Kanban thought process and am sure I will write about it at some time in the future)

TIP #4 - Don't just communicate ... collaborate!

Anyone can communicate!  All you have to do is send an email or document out to someone.  Collaborating is tough stuff as now you have to get people sharing information and ideas effectively.   This doesn't seem to be natural and takes a lot effort on the part of the leader and team to make it happen.

Think about how you organize your team.   The most effective organizational structure is a circle where everyone is on an equal level with clearly defined roles.   No intemediaries as that is wasteful and leaves things open to interpretation.  I will be writing a future post in the coming month with more on the topic of a symetrical team structure, but for now the important concept is everyone has the opportunity to collaborate with everyone else directly.
Host 15 min stand-up meetings each morning.   Please note 2 key things in the previous statement:  '15 min' and 'stand-up'.   This has turned out to be a very effective tool for keeping the team in sync each day.   During this quick meeting each member of the core team must share three things:   what they accomplished since the last meeting, what they plan to accomplish today and what barriers are in front of them.    Keep it on track and moving and you will find people dont' have a problem coming to the meeting each day.   If you'd like to read more about stand up meetings check out Martin Fowlers blog entry:  Its not just standing up

This is a big topic, but hopefully I've summarized a couple key points for you on tools for collaborating more effectively.   Don't just be a manager or boss!  Be their leader and inspire them to do the best job possible!   Make them believe they're the most important thing happening and watch how they'll rise to the challenge

Next week I will post the last two suggestions I have for being an effective agile PM. 

Until then ... be Agile!

Mike

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