LeadingAnswers: Leadership and Agile Project Management Blog

Parking Lot Diagrams Revisited – Using Area to Show Effort

Parking Lot diagrams are a great way of summarizing an entire project’s progress and status onto a single page. They illustrate work done, work in progress, work planned and identify what is behind schedule.
 
In this example we can see that “Stock Search” in red, is behind, it was due to finish in November. “Create New Order” shown in green is complete, the boxes in yellow are ‘in progress’ and those in white have not been started yet. I have posted previously about their use and examples of how to produce them.

However, they miss an important element, the relative sizes (usually in terms of effort, but could be cost or risk) of the functional areas. So, in the example above, the fact that “Enter Order Details” might be 3 times the development effort of “Create New Order” is likely lost on the stakeholders reviewing the chart. Sure they can look at the number of features 15 vs 5 and likely surmise “Enter Order Details” is more work, but upon first impression, this is not immediately apparent.

So, bring on Scaled Progress charts, the box size represents estimated development effort. I have been using these with my current Steering Committee for a while. I meet some of these people infrequently and these charts provide a nice reminder of the overall project scope and where the project progress right now.


 
Development sequence is left to right, top down. We can see that progress is being made in “Contractual Estimating” which is a bigger chunk of development than, say “Monthly Billing”. I use PowerPoint for these diagrams, the box widths are all the same and I use the development point estimates to determine the height of the box. This way box size (area) is proportional to development effort. The percent complete shading effect is created by using another similar sized shape drawn on top shortened to the appropriate percent complete.

All this manual sizing and progress bar manufacturing is time consuming. What I really want is an Excel based Parking Lot diagram that automatically scales box size (area) to development effort. Like the one shown below:

 

Only I had to create this version in Powerpoint and that is not really practical, as estimates for functional areas change frequently, and while Excel can easily do the colour changes via conditional formatting, this has to be done manually in Powerpoint). So, if there are readers out there who can do this in Excel I would love to hear from you and share your solution with other readers here.

In the mean time, with my goal of keeping these graphs quick and easy to produce, I have been looking around for other ways of showing progress against work packages of different sizes. Microsoft Project is of course a prime candidate, and using the Tracking Gantt View shows progress against tasks, rolled up by group. I have recently been playing with the MS Project 2010 beta and the screen shot below shows the same project in MS Project 2010.


 
This is quite useful and I particularly like the new Timeline feature of MS Project 2010, giving a graphical summary of the entire project schedule above the Gantt. We can see the progress against each of the Feature Groups. For instance  “Create New Order” is 100% done, “Capture Customer Details” is 75% done, and “Stock Search” is only 95% done yet lagging behind the vertical orange line marking today’s date, so therefore it must be behind schedule.

However, this is my problem with Gantt charts, unless you are a project manager, or someone who understands Gantt charts, they are not that intuitive. This mess of bars accurately shows progress and schedule, but is difficult for many stakeholders to interpret. Notably, it fails in a couple of areas:

1)    It is difficult to see how the work areas contribute to the whole project
2)    Issues such as late tasks may not be immediately apparent

So what other ways of illustrating how components relate to the whole, and illustrating progress do we have? Well, pie charts are good at showing how components relate to the whole, and maybe we can do some fancy overlay of percent complete.

Here I have broken the work areas into pie segments to show their relative sizes and superimposed an additional pie segment which represents percent complete. This is OK, we could do some conditional formatting to make late segments change colour, but it breaks down when the number of segments increases. Plus it fails my “easy to create” requirement as this was a combination of Excel and Powerpoint.

So perhaps we are back to some kind of scaled bar chart

Of one sort or another...


 
Yet they are looking a little Gantt’ish again. I am hoping that this post will prompt someone to show us how we easily create a one page image that represents the whole project scope and then progress against each of the various components inside it.

Agile Business Conference 2009

I attended the Agile Business Conference in London this week and presented on Tracking Project Performance. I missed this conference last year and so it was especially good to catch up with people again and hear what they have been doing. Also, after working in London for six years, but then living in Canada for the last nine years, it is always interesting to see how things have changed since my last visit. This year it was video screens replacing all the paper billboards going up and down the escalators on the Underground that caught my eye.

 

The conference was very good, and had the general theme of “Agile Grown Up”, focussing on the organizational impacts of using agile. This may not have been as much interest to technical people, but was right up my street. On Tuesday there was a great session about agile at Nokia where 1800 software developers are using agile to develop the Symbian mobile phone platform. They are using a version of Dean Leffingwell’s “Agile Train” approach for scaling agile to such a large team and most agile practices, but not pair-programming or emerging architecture. However, the main emphasis was beyond the technical process scaling and more on the ongoing coaching, mentoring and training that is required for such a large undertaking. In a discussion with the presenter Simon Buck after the talk I learned that they aim for one full time coach/trainer for each set of 5 Scrum Teams (each about 7 people). Quite the undertaking.

PMBOK v4 and Agile mappings

For the attendees of my recent Las Vegas course, below is a link to the PMBOK v4 to Agile mappings we discussed. My previous course material mappings were based on PMBOK v3, and before that the 2000 edition, which are out of date now.

 

Quite a lot changed from the PMBOK v3 to v4; all the processes were renamed into the new verb-noun format. Six of the old processes were merged into four new ones, two processes were deleted, and two new ones added. So it seemed like time to redo the mappings and post them online this time.

 

Cautions

Process guidelines and templates are not an acceptable replacement for common sense, thought, dialog, or collaboration. A fool with a tool is still a fool, but can be especially dangerous since they give the impression that they have a potential solution to tricky problems. Beware of simply following any project guidelines that seem counter to your objectives.

 

So, why would you want to be mapping the PMBOK v4 to Agile techniques anyway?...

Project Success?

What defines project success? On “time and budget”, or “to specification and quality requirements”, maybe all of these? No, we are missing some less tangible, but critical components; how do people feel about the project once it is done.

On May 12 the PMI-SAC Awards for the best projects and the best project managers will be held in Calgary and Captain James Lovell, Commander of Apollo 13 will be giving the keynote “Apollo 13 – A Successful Failure”. This year I am a judge for the awards ceremony and in reviewing the applicants I have been thinking about what constitutes a successful project which prompted the recollection of some famous projects...

Apollo 13
Let’s consider Apollo 13. The third manned mission by NASA intended to land on the moon that experienced electrical problems 2 days after liftoff. An explosion occurred resulting in the loss of oxygen and power and the "Houston, we've had a problem" quote from Lovell (that is widely misquoted as, "Houston, we have a problem".)

The crew shut down the Command Module and used the Lunar Module as a "lifeboat" during the return trip to earth. Despite great hardship caused by limited electrical power, extreme cold, and a shortage of water, the crew returned safely to Earth and while missing the main moon-based scope, it was a very successful rescue, allowing future missions. “A Successful Failure”

Titanic
(The 1997 film not the original ship). This film was six months late, massively over budget and finished with a bloated 194-minute running time. Seemingly not a good performance given the original schedule, budget and scope requirements. Yet the film turned into an enormous critical and commercial success, winning eleven Academy Awards, including Best Picture and became the highest-grossing film of all time.

Batch Size and Velocity Fluctuations

I recently wrote a post on Velocity Signature Analysis and have been looking at how undertaking large chunks of work as a complete team impacts velocity. We are currently three quarters of the way through a major (4 months long) piece of functionality and velocity is finally rising. This seems a pattern; for the early portion of a new area of work we spend a lot of time understanding the business domain and checking our interpretation using mock-ups and discussions. Velocity, in terms of functionality built and approved by the business is down during this time since many of the team members are involved in understanding the new business area rather than cranking out code.

As project manager I can get jittery, did we estimate this section of work correctly? Our average velocity for the last module was 60 points per month and now we are only getting 20! Weeks and weeks go by as whiteboards get filled, designs get changed, but the tested story counts hardly moves. Compounding this Discovery Drain phenomenon is the Clean-up Drain pattern. During the early portions of a new phase, fixing up the niggling issues hanging over from the last phase seems to take a long time. This makes perfect sense, if they were easy they would probably have been done earlier. It is always the difficult to reproduce bug, the change request that necessitates a rework of established workflow or multiple stakeholder collaboration that seem to bleed into the next development phase. While there may only be 3 or 4 bugs or change requests hanging over, they take a disproportionate amount of time to resolve.

PMI Agile SIG Getting Ready For Launch

The PMI Agile SIG is gathering speed. This Special Interest Group (SIG) is set to be launched later this year and is very timely. While currently the interaction between agile and traditional project management approaches in most organizations may be small.

This intersection is set to expand. The agile community knows that interest and adoption of agile is on the increase. We need only look at the attendance figures for the major agile conferences over the past few years to see how usage and interest is on the increase.

    

Yet, at the same time the PMI is seeing dizzying growth too. Fueled by demands for tighter controls and better governance, along with a seeming insatiable demand for the PMP certification PMI membership has seen strong growth over the past 10 years.

The PMI Agile SIG will be a group made available to all PMI members who want to learn, contribute, and discuss using agile methods. It will examine the best ways to manage such projects and should be a powerful voice for driving agile related practices into the PMBOK Guide and other PMI standards.

As both agile and PMI adoption increases we will see far more overlap and iteration on projects.

Agile methods are being used increasingly beyond the software domain and rather than dismiss traditional approaches as not applicable I think it is better to work with them and help shape a better set of standards for the future.

I have written on introducing agile into the PMI several times before (here, here, here) and often end up discussing the IP concerns of working with the PMI with people. My take is that I'd rather be on the inside trying to make changes rather than outside taking shots. That's why I present on agile at the PMI Conferences and teach an agile project management course for PMI SeminarsWorld.

So, for those that want to help change the world of project management, the PMI Agile SIG is a good place to start. We are actively looking for members, anyone interested in joining can send an email to PMIAgileSIG@LeadingAnswers.com

Just what the PMI Agile SIG can do will be limited only by the enthusiasm of its members. I do know that there is a PMBOK Extension for the Construction Industry published by the PMI. It is for people in the Construction industry wanting to use PMBOK processes in their unique domain. Rather than the name suggests of just extending the PMBOK it actually says: "if you are in the construction industry, forget these processes from the standard PMBOK and instead replace them with these ones…" Longer term, a PMBOK Extension for the Software Industry that removes static planning and substitutes some agile methods would be very useful.

A Better S Curve and Simplified EVM

“S Curves” are great to track project spend. They are simple to interpret and quickly let us see if we are over or under budget.

  

However, we could be doing fine spend wise, but behind from a schedule perspective. This is where Tracking Gantt charts come in and show schedule.

 

Yet, Gantt charts lack the spend component. Pretty soon most projects get ahead or behind in spend and time and so trying to gauge the overall project health becomes difficult.

This is why Earned Value Analysis (EVA) and Earned Value Management (EVM) were created, combining both spend and progress variables to produce a comprehensive set of project measures and metrics. However, there begins the problem.

What’s Bad about Earned Value

EVA is beyond most project stakeholders -

Most people who are not using EVM every week do not understand the terms. “Is a negative Schedule Variance good or bad?”, “What’s the difference between BCWP and EV?” (Answers: it is bad, and they are the same). Despite its usefulness, the confusing terms and heavy use of math puts off a large percentage of the population.

Debates digress beyond numerical accuracy - More challenging still is when several people do understand EVM and start debating which versions of the formulae to use and everyone starts obsessing on the math instead of the project. “Should we use EAC = BAC/CPI, or EAC = AC + ETC, or EAC = AC + [(BAC-EV)/CPI ?” Geez people, the developers probably pulled half of these estimates out of the air and we are applying advanced math to them?

What’s the value in tracking progress against a flawed plan? - EVM compares actual project performance to planned performance at a point in time. So, if our initial plan is wrong we could be effectively trying to do the equivalent of tracking our progress on a road trip from Calgary to Salt Lake City on a map of France! The quality of the baseline plan is a critical success factor of EVM. In agile projects we acknowledge initial plans will likely need changing and so the basis for effective EVM is quickly eroded with evolving plans.

Where’s the Quality?  - We could be on time and on budget, but building a horrible product that the business does not like or is low in quality. We should be aware that cost and schedule are not the whole picture. EVM and agile alternatives are just a part of the picture.

What’s Good about Earned value

It is a Leading Indicator - Perfect rear vision is not of much use to people. At least EVM tries to predict completion dates and final costs. Imperfect leading metrics are always more valuable than perfect trailing metrics, since they give us options to re-plan and change our approach.

It is visual - It is easy to forget the EVM graphs and focus on the numbers, but at the heart of the process are some useful graphs. Visual is good because it engages the right-side of the brain and helps us draw on more mental power to understand, interpret and plan appropriate responses. Visual things are also better to discuss and collaborate on since we can point, annotate and extrapolate easier than with words or numbers.

Agile Alternatives
So how can we maintain the Leading and visual components of EVM and reduce some of the down sides? Well "Double S Curves" are a good start.

 
 
In this graph we have a familiar spend line shown in green tracking to the dollar scale on the right hand axis; and also a feature based line shown in blue tracking against the points scale on the left. 

The gradient of the blue line indicates project velocity. Where it rises steeply we got a lot of points developed in a short time, where it is flat, progress was slow.

 

Adding a background on the graph can be useful to show functional areas. Here we can see that the “Configuration” and “Stock” components of the system have been built and we are currently in the “Sales” piece of functionality at just over 1000 points worth of functionality completed.

Also, at the end of 2007 the step in the background image shows where the scope of the “Sales” portion of the system was increased, shifting the remaining functional areas out by the new work amount. Yet we are still missing projections and a sense of if we are ahead or behind from both spend and schedule perspectives. This is where predicted values come in.

  

Now we can see how we are comparing against our projections. In this example we are overspent and a little ahead of progress currently, but the trends in velocity do not correlate with the continuing velocity improvements predicted.

As a replacement for Earned Value Management, these graphs are all you need. We can get the same metrics and indices right here.

 

Traditional EVM metrics like Schedule Performance Index (SPI) and Cost Performance Index (CPI) can be easily translated into Agile terms. For example, if we planned to complete 30 stories this iteration, but only completed 25 then our SPI is 25/30 or 0.83 (we are working at only 83% of the rate planned). Likewise, CPI is the Earned Value (Completed Features Value) to date divided by the Actual Costs to date, in the example above $2.2M / $2.8M = 0.79. This means we are only getting 79 cents on the dollar compared to what we had predicted, (but of course, who is to say what we predicted is correct.)

Cruel Irony
I find it ironic and amusing that “Earned Value” is a traditional project management term and agile projects often track progress in nebulous “Points”. This is backwards. Agile projects deliberately relate things back to real business value, and yet many traditional project track progress against tasks that add little or no business value and call the process “Earned Value”.

Creating a detailed requirements document that formalizes an incomplete, premature view of requirements that should change as details emerge and business continues to evolve is not earning much value at all. Yet prioritizing features by business value and tracking progress against the business oriented features is an excellent example of real “Earned Value”.

Next Steps
I have uploaded the example spreadsheet used to produce these graphs so you can get started with your own if you are intersted. The Excel “tricks” are as follows:

1) To get the two graphs on the same chart use the ‘Line – Column on 2 axes” graph option. This is on the “Custom Graphs” tab in old versions of Excel, In the Vista version of Excel, add a secondary axis to a normal line graph, by Formatting the data series, then click “Secondary Axis” on the Series Options tab.

2) Create a background image with bands that vary in height corresponding to their points estimates. E.G. a project with two phases one 300 points and one 200 points, would have background image with two bands, one, say, 3cm high the other 2 cm high. Just as long as the proportions are correct the image will be scaled to fit the graph region appropriately. I simply use PowerPoint to create my background images, but you can be as fancy as you like.

3) In Excel format the axes and adjust the Min. and Max values from 0 to you budget amount and points estimate for the project. If these number change, create a new background image and reset the scales.

Download graph_examples.xls

Tool support

I try to keep up with the agile PM tools, but as far as I know, Rally, VersionOne, Target Process, Mingle, XPlanner, etc do not produce these graphs yet. I hope they do soon and calculate the EVM numbers too. I talk to many organizations who want to apply EVM type analysis on agile projects or work with PMO’s that ask for these stats.

Discussion on when it is appropriate to use straight line extrapolation to calculate Estimates At Completion (EAC) and the impacts of updating plans will be the subject of a future post. In the mean time you can also read a research paper on the topic written for the 2006 Agile Conference.

Download rp2_cabri_griffiths_agile_and_earned_value_reporting.pdf

Print Your Own Planning Poker Cards

Local APLN member Edgardo Gonzalez, has kindly offered a Planning Poker card template for readers to download. (No longer are we tied to the decks generously given out by Mountain Goat Software at conferences; now we can print our own!)  Based on the Fibonacci sequence, these cards print on standard Avery stationery and can be used by team members to estimate story points. (Post on Agile Estimation Techniques)

Thanks Edgardo for your gift to the community.

Download Planning Poker Cards.doc

Agile Project Leadership and More on Accreditation

Last week I taught the “Agile Project Leadership” course with Sanjiv Augustine in Manchester, UK. The course went really well and we were looked after by Ian and Dot Tudor our hosts from TCC Training and Consultancy. They have a number of training facilities around the UK and ours was Aspen House, a converted church that retained all the arched doorways and high vaulted ceilings you would hope for.

It was a rare treat to teach in such nice surroundings and the church setting made evangelising agile all the more fun. In truth we were “preaching to the choir” as most of the delegates were already familiar with the benefits of agile and were looking for practical tools and more leadership techniques to move their organizations to the next level.

Agile Project Leadership Training Course

On February 4-5th I will be co-instructing with Sanjiv Augustine our new “Agile Project Leadership” training course in Manchester, UK. Sanjiv is the author of the excellent “Managing Agile Projects” book and fellow APLN board member.

This is a fast paced, practical focussed course that covers agile project management, leadership, and avoiding common agile project pitfalls.

You can find further details including a course outline at here.

Top 10 Estimation Best Practices

I have written a few posts now on estimation and so I thought it was time for a summary. Also, I am planning to create a series of one page best practice summaries / cheat-sheets for agile and this seemed like a good candidate.

(I am a real fan of one-pagers; there is special value in getting everything visible and presented on one page that brings unique scope comprehension and clarity.  Toyota and other lean organizations make heavy use of A3 reports, a one page summary of an issue, its root causes, countermeasures, and verification steps to summarize problems and planned solutions - they are powerful tools.

Incidentally, when I first started work I had a wise and cantankerous project manager who was full of oxymoronic proverbs. One I remember was “If you cannot summarize it on only one page, you need to go off and learn more about it!” An astute paradox.)

Anyway, here’s the summary; if you want more explanation on any of the points, refer to my previous posts (Upfront Estimates, Estimation Techniques, Estimate Ranges) on agile estimation.

Software Estimates - Managing Expectations via Ranges

Customer: How much is that parrot in the window?
Pet shop owner: Somewhere between $200 and $250
Customer: Erm, OK, I’ll give you $200 for it then!

To some people providing estimates as a range of values seem a strange and unsatisfying way of conducting business. They just want to know how much something will cost, not how much it may or not cost. This is reasonable if the object or service is ready for use, but not if it has yet to be created. The more uncertainty involved in the process the more likely there will be some variability. Now consider this conversation:

Customer: How much will it cost for a taxi ride from the library to the airport
Taxi driver: Probably between $20 and $25, depending on traffic
Customer: OK, that sounds fair, let’s go

It seems more reasonable, we understand the variability of traffic. Unfortunately not all stakeholders understand the variability caused by evolving requirements and changing technology often associated with software projects. However the uncertainties of software development are real and we have an obligation to report estimates as ranges to help manage expectations.

Agile Estimating – Estimation Approaches

In the last post we covered the importance of engaging the right people in the estimation process and the need to use more than one estimation approach. Today we will look at some examples of team based estimation approaches and practical ways to combine estimate result sets.

Estimation approaches (agile or traditional) can be divided into Heuristic (expert judgment based) and Parametric (calculation based) approaches.

Heuristic
• Comparison to similar systems
• Expert Judgment
• Activity Based (top down)
• Task Based (bottom up)

Parametric
• Function Points
• Use Case Points
• Object Points

Both sets of approaches have some merit, but they are also have their limitations and are open to misuse and over reliance too. For instance Activity Based (top-down) estimating is the most commonly employed estimation approach, but has been found to be the least accurate. Capers Jones in his book “Estimating Software Costs” instead recommends task based (bottom up) estimating approaches that tend to yield better results by encouraging a more thorough investigation into the likely tasks.

Involving many stakeholders
We should ask the people who will be doing the work how long they think it will take. Not only are they closest to the technical details and therefore theoretically in a better position to create a better estimate, but also because of the psychological benefits also.

If someone just hands you an estimate for your work and tells you it should take two weeks, you can either comply and try to get it done in two weeks or rebel and either finish it early or explain why it will take much longer to illustrate the poor nature of the estimate. Even complying and doing the work in two weeks can be a problem; given two weeks work will expand to fill the time. If a solution is found early time will likely be spent finding a better solution or refining the existing one. We do not get enough of the early finishes to cancel out the late ones. As Don Reinertsen observes in “Managing the Design Factory” in engineering we get few early finishes.

Calgary APLN Planning Session

Last week we had the planning session for the 2007/2008 Calgary APLN Chapter. The goal was to create a prioritized list of topics to explore this season and demonstrate some of the values and practices of agile project leadership along the way.

We started by using the Speedboat game in small groups to identify impediments and propellers towards our goal of “Connecting, developing, and supporting great project leaders”. Speedboat is a group exercise for “Issue” and “Enabler” brainstorming that can be used with any group. It helps people to clarify goals, air their concerns, and suggest options for avoiding risks and moving forward. My colleague and co-host for the session, Janice Aston, wrote up these useful notes on using Speedboat and the outputs from the group.

Download Speed_Boat_Instructions.doc

Download Session_Results_10-17-07.doc

I previously wrote an account on Speedboat and other Innovation Games in an earlier post.

Following the Speedboat exercise we brainstormed presentation topics for the upcoming year. The thought process was: “Given the issues and enablers you just identified with agile leadership, what are the topics you would most like to see presented and discussed this year?”

Each group wrote ideas on sticky notes and we then posted them on the wall. Went through an affinity grouping exercise that sorted them into themed groups and removed duplicate suggestions. We all then went through a dot voting exercise where we assigned three votes among the topic suggestions. The topics and votes counts (shown in brackets) are shown below:

Right-Brain Project Management

Last week I attended an excellent presentation on “Right-Brain Project Management” by Dr Michael Aucoin. I attend lots of presentations during the course of a year, mainly at North America events but a sprinkling of international conferences too, and few presentations stand out as being excellent. This one was exceptional from the content (that connected some loose ends in my Agile-Leadership-Project Management mental model) to the materials and delivery.

So, what was so good about it and what does it have to do with Agile Leadership? Well it outlined a parallel view of project management that supports and reinforces agile leadership and fills in some gaps along the way.

Michael started off by talking about today’s Stretch projects. He defined a Stretch project as a project that causes traditional project management challenges. They are characterized by:

• Schedule challenges and resource challenges
• Ambiguous specifications
• Dealing with new technology, new groups, new people
• Dispersed teams
• Many mid-project scope changes
• Challenging people issues

In these circumstances the old project management approaches that are good for predictable projects break down. Michael did not use the words Traditional and Agile, but he might as well have been giving an agile presentation because through his research he had arrived at the same conclusions, but interestingly, offered additional insights.

Why Does Project Management Fail?
Many people are frustrated by the mismatch between project management theory and its application on real-life projects. This is due largely to trying to employ approaches designed for predictable projects on today’s Stretch projects and seeing them come up short.

Yet, in many walks of life outside of project management, people succeed in unpredictable environments everyday. Doctors, farmers, and teachers all work in difficult to predict environments yet, on the whole, are successful. So why do project manager’s struggle with stretch projects? There are three main reasons.

1. Mismatched project model and environment
2. Projects lack emotional involvement
3. Personal challenges created by stretch projects

Let's look at each in turn...

Agile Exception Processes – What to do when bad stuff happens to good projects

When caught by a fire or other urgent situations it is useful to have emergency equipment on hand and know how to use it.  The same goes for Project Exception Processes, if something untoward happens then that is not the best time to be creating new processes to deal with the event and explaining how to use them. Emotions are high, people respond to bad news differently, and it is better to practice an agreed to procedure than figure out new rules.

Project tolerances and exception plans provide an agreed to emergency plan for when bad stuff happens to good projects. They act as guardrails to help prevent us going off track and provide a mutually understood and agreed to resolution process. So, just as during an emergency is not the best time to collaborate on improvising a rope ladder, nor is during a major project scope change the best time to define a resolution process between project stakeholders.

We will look at the two components (Tolerances and Exception Plans) individually and then examine how they work together. Project tolerances are the guardrails, the upper and lower boundaries the project stakeholders are willing to tolerate for a given project metric. Another way to think of it is how much slack rope we have as a project team to do our own thing (or hang our selves with). Tolerances can be set on a variety of metrics and the degree of variation will depend upon the individual risk tolerances of the collective stakeholders. Some projects might be very time critical, others more concerned with budget, or user satisfaction.

New Agile Project Leadership Training Course

In September I will be co-instructing with Sanjiv Augustine the new course “Agile Project Leadership”. Sanjiv is a fellow APLN board member and author of the excellent “Managing Agile Projects” book. I’m really excited because a) we have an excellent course that will stretch attendees while engaging them, and b) co-teaching with Sanjiv will be a blast since he is such a knowledgable and personable expert.

Our first course offering will be in Manchester, UK on September 10-11th. You can find further details including a course outline at Agile University here

Agile Interfaces - PMO Integration

I spend a fair portion of my time working with Project Management Office (PMO) and Project Support Office (PSO) groups helping them integrate agile methods. One simple concept I’d like to outline today is the idea of Agile Interfaces.

Agile methods provide a great feature delivery engine, they iteratively feed on features from the backlog and produce tested functionality of high business value.

To external stakeholders this also represents a daunting and unfamiliar process to connect to. Its cyclical, seemingly never ending process is about as appealing to interact with as putting your arm in a washing machine while running. However there are a couple of friendly, safe interfaces that can alleviate mid-cycle arm twisting (how we normally extract information from the team.)

As mentioned, while agile methods focus on delivering features, they often do not provide the information required for PMOs, PSOs and other supporting groups. They typically do not encompass the entire enterprise lifecycle omitting important pre-project work and beyond delivery activities, as shown below.

The Pipelining Anti-Pattern

If you have analysts working ahead of development, or have testers working significantly behind development, then you may have “Pipelining” problems.

Pipelining is the term used to describe the situation when business analysts are working ahead on the requirements for a future iteration; the development team is working on the current iteration, and the test team is engaged on a previous iteration.

In some circumstances analysis may be several iterations ahead and testing several iterations behind. To some people this may seem an efficient use of resources with each group running at their optimal speed, unfettered by the co-ordination constraints of different groups. However from an agile and lean perspective this is problem, a bad-smell that needs fixing.

Here are the problems with pipelining:

Three teams not one – in a project where pipelining is occurring we do not have one cohesive team we have three teams (or more). It is hard enough co-ordinating the members of one team towards a common goal aligned to business benefits. When there are three teams it is just too easy for people to claim that they did their bit and problems lie with other groups. Yet, the fact remains that if the software does not meet business satisfaction then it is everyone’s problem.

Increased Work In Progress (WIP) – Requirements whether they are in the form of user stories, use cases, or formal specifications all represent work invested that has not delivered value to the business. The same goes for code, until this functionality has been tested to the satisfaction of the business it is not valuable. As the time increases between capturing the requirement and finishing the last test two problems occur. The first is classic accounting, money have been invested for no return yet and there is a risk associated with future returns. The second is that requirements decay; the longer we keep requirements around for, the higher the likelihood that they will no longer be required or will have to change.

Increased time from defect injection to defect remediation – the cost of change increases the longer a defect goes undetected. In a pipelining project, defects introduced by faulty analysis could take months to be detected in testing or user review. Fixing the problem after this period of time will entail refactoring far more code (for the work happening in the interim) than if it was detected earlier, and will increase technical debt...

The True Role of a PM on Agile Projects

So, what does the PM do on agile projects? If the team self organizes and selects their own work from the prioritized feature list, should the PM just buy pizza and keep out of the way? Well they are short changing the team if that is all they do. Rather than a fear of role erosion, PM’s should be maximizing business value delivery and looking to broaden their skill set with more leadership practices.  This post outlines four core roles and ten core principles managers of agile projects should practise. 

Working in Parallel
Before we start, the transition to agile does not happen overnight. There will be a long and sometimes awkward transition period as all the project stakeholders adopt a more collaborative and empowered approach to work. Some people will be quicker than others to make the transition and the PM often has to continue with traditional PM activities, behind the scenes, to ensure no balls are dropped on the project.

Ideas not new to agile, just a renewed emphasis
The Agile PM traits of a downward serving model and Leadership rather than Management were not invented by Agile guru’s. Instead agile teams found that the management styles that favoured people over process, collaboration over command-and-control worked best on agile projects. Leadership that moves the emphasis from doing-things-right to doing-the-right-things is a better complement to agile methods than the detail oriented task management popularized by modern project management. Interestingly, project management (emphasising achieving things through task control) is a relatively new phenomenon based on Fredrick Taylor’s Transformation View of task decomposition (1900). Whereas Leadership (emphasising achieving things through collaboration and shared vision) is as old as human collaboration itself. "When the best leader's work is done, the people say, We did it ourselves." - Lao-Tzu (604 BC)

Agile PM Role 1: Obstacle Removal

Large Project Risks

(Chop those large projects down to size)

When I started out as a PM and had a few successful projects under my belt, I wanted to manage larger and larger projects. Now I’m looking for ways to make them smaller and limit the functionality initially tackled. This is not just laziness or a lack of ambition on my behalf, instead it is a realization that delivering business value comes from successful projects and that large projects are inherently risky and more likely to fail.

Jim Johnson of the Standish Group presented some interesting metrics at the PMI Global Congress conference in Toronto a couple of years ago that confirmed my suspicion. From a study of over 23,000 projects it was found that the success rate dropped as project duration increased.

From the graph we can see that most (over 50%) of the 6 month projects surveyed were deemed successful, dropping to 23% of 12 month projects, and less than 10% of 24 month projects. Now, we need to understand what “Sucess”  means here. The criteria was quite strict and defined as within 15% of cost and schedule and to customer defined functionality and quality standards.

I expect a large proportion of these “failed” projects merely missed the 15% cost or time criteria and the picture would not be so bad with a wider margin. Predicting costs over long periods is notoriously difficult as even labour rates and inflation predictions elude the best market ecconomists. However the trend is still true, larger projects carry a much higher probability of failure for a number of reasons we will see...

A Burn-Rate Based Estimation Tool

In my last post I suggested spending less time worrying about project metrics and more time on stakeholder concerns, so I thought a tool to simplify project tracking might be useful.

Having completed project estimating with the team, it is often necessary to convert effort estimates into cost estimates based on likely utilizations and then track actual hours billed against these projections. Today’s download is a simple burn-rate estimation tool that produces S-Curve graphs and let you track actual spend against burn-rate projections and planned budgets.

You can download the spreadsheet here:

Download estimation_and_budget_tracking.xls

Lighter Grip and More Awareness: Lessons in collaboration from Boeing

Control vs Communication

When you first learn to ride a bike it is normal to grip the handlebars really tightly and look at your hands or feet as you concentrate hard on the new “riding” task and try not to fall off. The problem with looking at your hands or feet while cycling is that you will not see the rock or pothole in the road ahead until it is too late and so, despite your best efforts, you will fall off. It is actually safer to relax, loosen your grip on the handlebars a little, and look further up the road to spot obstacles in plenty of time to avoid them.

The same goes for project management, when we are new to the role it is normal to focus on the project plans, progress against the plan, and budget consumed too closely. We focus so much on these project management tasks that we fail to see the issues and risks (rocks and potholes) the project is headed towards, until it is too late. While plans, progress and budgets are all critical elements, we can bring more value to the project by releasing our obsession on these project metrics slightly and focussing more of our attention down the road to items like sponsor satisfaction and team morale. There is little point having a perfectly executed project plan and a full set of EVA metrics if the project gets cancelled or half the team quits.

Specification vs Collaboration
Closely linked to Control and Communication is Specification and Collaboration. We can try to specify everything down to the nth degree of detail and then hope we got the spec right and whoever is developing the product develops exactly to specification. Or, we can explain our goals at a high level and then work in closer collaboration with the developer to achieve our desired results.  Agile methods recommend the second option, getting the customer working in closer collaboration with the developer to ensure the right product gets built. This works well for many types of software project where it is difficult to fully articulate the complete requirements upfront. However, it is not just the software world that is switching to collaboration over specification.

Today’s aircraft are highly complex networks of sub-systems, parts and software; and Boeing’s new 787 Dreamliner is about as big and complex as commercial aircraft currently get. From its ground breaking remote diagnostics that communicate component usage, wear and failure statistics to the ground in real time via satellite communications; to its novel composite material wings that save weight, the aircraft is new and extremely complex.

When Boeing sent the specifications to the electronics supplier for the 777 (the predecessor to the 787) the document was over 2500 pages. The equivalent specification document for the 787 is a mere 20 pages, how is this possible? Boeing, who are experts in specification and control, learned that to tackle a project of this magnitude they had to form closer relations with their suppliers and learn how to co-create and collaborate like never before. While it would be wrong to say: “Gone are all the detailed specs” the major shift is to increased collaboration with suppliers and less reliance upon specification.

Many industries are tapping into the benefits of increased collaboration over contract negotiation that are also embraced by agile methods. With increased collaboration comes shared decision making as well. In the past, Boeing gave the orders like a drill sergeant, and suppliers complied. Rarely did it matter if the supplier had a better idea – Boeing wanted components built exactly to specification. This time, Boeing has given all of its partners a vote on matters that affect them. Boeing and its partners are reaping the benefits as they work together on solutions and adapt to realize unanticipated benefits.

So, if you get a chance to fly on a new 787 Dreamliner any time soon, consider the new collaboration process that enabled its creation (and let’s hope they did not lose any of those story cards!)

You can read more about emerging trends in collaboration and Boeing’s new work practices in Wikinomics: How Mass Collaboration Changes Everything. By Don Tapscott and Anthony Williams.

Release and Iteration Planning with Innovation Games

In this post I outline some really useful techniques for planning releases and iterations. They are adapted from a great book called “Innovation Games: Creating Breakthrough Products through Collaborative Play" by Luke Hohmann

Some thoughts on the term “Games”
I have never been a fan of suggesting the use of “games” in the enterprise workplace, as in XP’s “Planning Game”. The term does not sit well with some traditional-type folks; to them it sounds unprofessional and not serious enough for important work. Yet the Innovation Games described by Hohmann are high performance facilitated workshop exercises that produce great results. If the project is serious enough to engage busy stakeholders then I think we owe it to the business to use the most effective tools at our disposal. If calling them “facilitated workshop exercises” eases their acceptance then I’m all for it, because it is the results I’m really interested in, not so much what we call them.

The Games
In Luke’s book, he outlines a number of games (exercises) that can be used in a variety of settings. Some like “Design the Product Box” and “Buy a Feature” are probably familiar to many people working on agile projects, others will likely be new. To keep this post a reasonable length I will focus on adapting three exercises for use in release and iteration planning.

The three we will look at are “Remember the Future”, “Prune the Product Tree”, and “Speedboat”.  I use slight variations on the last two, I call them “Shape the Product Tree” and “Sailboat” and I will explain the differences when we get to them...

Team Decision Making

How quickly we make decisions and the team member’s level of agreement to these decisions impacts project performance and team cohesion. Software development is an exercise in information exchange and decision making. Also, since software projects have no tangible, emerging product moving down a production line, the communication and decision making process becomes more critical to keep everyone informed and engaged.

Agile methods utilize many tools to promote effective communications including: co-location, daily stand-up meetings, planning workshops, retrospectives, etc, but less is written or taught about decision making. However, if team members are not canvassed for their opinions we run the risk of alienating portions of the team leading to reduced levels of commitment and participation, and potentially missing an important new perspective that could help avoid pitfalls further on. This post outlines the importance of team based decision making and outlines a couple of simple tools to get you started.

Agile methods favour more team empowerment and less command-and-control direction. This increases satisfaction and productivity, but raises the need for effective decision making. Without a project dictator, how do teams make decisions and move forward?...

Update from The Agile Alliance Planning Meeting

I have just returned from the Agile Alliance board meeting in Portland, OR. The objectives were to develop the goals and objectives for the Agile Alliance for 2007, work through some conference planning details, and discuss research funding and other initiatives.

The meetings were held at the Kennedy School which is a very cool hotel, come arts and entertainment facility that houses a theatre, restaurant, several bars, and a movie theatre. The whole place has been preserved/restored to a historic school setting and decorated with a wide variety of art installations and period fixtures. The hotel rooms are old class rooms, complete with chalk boards, heavy baseboards and devoid of modern trimmings like TVs. The meeting rooms are old libraries, home economic labs etc. It really was a creative and inspiring setting and I believe helped contribute to a very productive set of meetings. If you are ever near Portland I would recommend you drop in for a look around.

Many of the items under review still require refining so I can not describe them until they are approved, but I think it is safe to outline some of the topics and themes discussed.

The Agile 2007 conference in Washington D.C. sounds like it will be a great event. It is good to learn that the Open Space sessions will be given a higher profile this year. They ended up a little buried away last year which is a shame because they can generate great energy and innovation. 

The conference submissions have now closed and many tracks received over 150 proposals. Unfortunately, some of the tracks only have room for about 50 presenters which means many good submissions will have to be turned down. We discussed other ways of harvesting this wealth of experience and information and I hope we can get some kind of knowledge-base CD of extra tracks or contributions into the Agile Narratives programs to recognize and make use of all these excellent submissions. From a lean perspective it seems like a lot of muda (waste) to let this information pass by the agile community as also-rans. Who knows, maybe there is an experience report or research paper out there that is just the solution you are looking for.

The venue for the Agile 2008 conference has not been selected yet, but planning is in progress. Major hotels and conference centres book up early and so preparations are already underway. Possible venues discussed included: Seattle, Toronto, Vancouver, Atlanta, and Santa Clara amongst others. Not only is the city important but so too is the conference site, we want somewhere that can not only house the large group, but also provide many gathering areas to promote discussion and collaboration.

It was also good to discuss the certification debate so more. I had a productive chat with Ron Jefferies, Brian Marick, Jutta Eckstein, and Ryan Martens and we all seemed to agree that if certifications are to exist they should be skill based and hard to obtain.

The sessions were well facilitated and productive. It is great to have a these face-to-face sessions it is just a shame that we are not located closer to one another so that we could easily (and responsibly) have more of them. My next planning trip is to Salt Lake City on Wednesday when the APLN board will be conducting a similar exercise for its planning year. Surprisingly the only overlap between these two groups is Todd Little and myself, otherwise we could have all gone to the Kennedy school which would have been a lot of fun.

Agile Earned Value Analysis Podcast

I recorded another podcast with Dina Scott of ControllingChaos recently. This one is about the problems of applying traditional Earned Value Analysis to Agile projects and then the promotion of some alternative, Agile metrics that answer the same questions.

The central theme comes down to questioning the logic of using conformance to a plan that is likely to be flawed as a yardstick for project assessment. Instead I suggest we can employ an extension to Cumulative Flow Diagrams that provide better project indicators.

The podcast can be found here and a link to my previous post on Agile Earned Value here.

Smart Planning: Balancing Functional and Non-Functional Requirements

Agile projects prioritize requirements based on business value. There may seem like no business value in the non-functional requirements of Compatibility, Usability, or Reliability, but if the systems fails to deliver one or more of these “~ilities” then the system is a dead-duck delivering no business value whatsoever. (We may design and build the highest specification car on the planet, but if it only runs on unicorn sweat, needs three hands to drive it, or manages only 5 seconds between break-downs it is not useful.)

So, given that we do need to prioritize non-functional development alongside functional requirements, what mechanism do we use? One approach that business folks understand uses money as the prime driver. A fancy descriptor for the technique might be “Feature prioritization based on balancing predicted ROI against expected monetary value of risk mitigation” but let’s just call it “Smart Planning” for simplicity.

Agile Leadership Patterns: The Merlin Exercise

According to legend, Merlin the magician was a great help to King Arthur because he knew what was going to happen since we has living his life backwards. This allowed Arthur of avoid obstacles and thwart enemy plots before they happened or were even schemed of. 

Project Managers can benefit from engaging the team in backwards planning from the desired end goal, through the required deliverables, to where we are today.  On Agile projects the exact end point may not be known as some functionality will evolve as new details emerge. However the Merlin exercise can be used for single iterations or sub-systems where the end goal can be easily described.

To use this process start by describing the completed solution with all the components and success criteria in place. Get the team to list all the technical attributes that must be in place. Then moving backwards, brainstorm each successful step that occurred to produce the desired outcome. Ask the team what the likely roadblocks for each of these steps might be and then ask how they would best be overcome.

The real power of the Merlin exercise comes from imprinting an image of success, seeing solutions to potential roadblocks that may occur, and starting (a perhaps daunting endeavour) from a view of victory. As the project progresses and the inevitable roadblock are encountered, having already discussed how they may be overcome speeds the remediation process.

Backwards planning also helps address “fade” where people struggle to identify steps a little further down the line from where they currently are. By starting at the end and asking for all things that must have contributed to the success we have two “starting” points for planning and more opportunity for team input.

The Merlin Exercise and other great techniques are also described in Project Leadership: From Theory to Practice by Jeffrey K. Pinto, et al.

Using Earned Value on Agile Projects

Q: Does Earned Value work for software projects?
A: Absolutely, Earned Value Analysis (EVA) is a statically valid reporting approach that can be applied to any endeavour. It compares actual progress and spend against projected progress and spend.

Q: Can you use Earned Value on Agile projects?
A: You can, but I would not recommend it. There are fundamental problems using EVA on agile projects relating to baseline plan quality. Also there are better alternatives available for agile projects.

Earned Value analysis and reporting measures conformance and performance to a baselined plan. So, given that on agile projects we know that our initial plans are likely to change, why track progress against a weak plan?

Next Calgary APLN Meeting Sold Out

The next Calgary Agile Project Leadership Network (APLN) meeting on Thursday October 12th is full. However we are currently putting names on a wait list in case of cancellations, so if you would still like to attend this event send an email with your contact details to register@calgaryapln.org and we will see if we can get you in.

For those of you already signed up, I’m sure the presentation will be very interesting. Rob Morris from CDL Systems will be talking about “Estimating and Planning Agile projects” and I had a chance to review Rob’s material earlier this week. It looks really good and draws from Rob’s deep experience along with materials from Mike Cohn and Steve McConnell.

Event:                         Calgary APLN: “Agile Estimation and Planning”
Presenter:                  Rob Morris, Principle Software Engineer, CDL Systems
Date:                          Thursday October 12, 2006
Time:                          12:00 PM – 1:00 PM (registration will commence at 11:30 AM)
                                   Light beverages to be provided
Location:                   5th Avenue Place – Conference Room
                                   Suite 202, 420 – 2nd Street SW

Topic: “Agile Estimation and Planning”

Rob’s presentation will explore Agile estimation and how it can be used in determining what can be accomplished within an iteration and how to estimate multi-iteration release plans. He will also touch on firm fixed price estimation and compare these approaches with more traditional estimation approaches.

About the Speaker:

Rob is the principal software engineer at CDL Systems and has over 20 years experience developing software systems. His more recent work has involved overseeing the development of control station software used to fly unmanned aerial vehicles currently operating in Iraq and Afghanistan. Rob has a BSc. in Electrical Engineering and Masters degrees in Computer Science and Software Engineering. He has embraced Agile techniques and tries to shoehorn them into the more document centric military projects at every opportunity. He is also a certified ScrumMaster.

Calgary APLN Meeting: "Estimating and Planning Agile Projects"

The next Calgary Agile Project Leadership Network (APLN) meeting will be on Thursday October 12th when Rob Morris from CDL Systems will be talking about “Estimating and Planning Agile projects”. Here are the details:

Event: Calgary APLN: “Agile Estimation and Planning”
Presenter: Rob Morris, Principle Software Engineer, CDL Software
Date: Thursday October 12, 2006
Time: 12:00 PM – 1:00 PM (registration will commence at 11:30 AM)
Light beverages to be provided
Location: 5th Avenue Place – Conference Room
Suite 202, 420 – 2nd Street SW

Topic: “Agile Estimation and Planning”
Rob’s presentation will explore Agile estimation and how it can be used in determining what can be accomplished within an iteration and how to estimate multi-iteration release plans. He will also touch on firm fixed price estimation and compare these approaches with more traditional estimation approaches.

About the Speaker:
Rob is the principal software engineer at CDL Systems and has over 20 years experience developing software systems. His more recent work has involved overseeing the development of control station software used to fly unmanned aerial vehicles currently operating in Iraq and Afghanistan. Rob has a BSc. in Electrical Engineering and Masters degrees in Computer Science and Software Engineering. He has embraced Agile techniques and tries to shoehorn them into the more document centric military projects at every opportunity. He is also a certified ScrumMaster.

To register for this event and for more information about the Calgary APLN group visit www.calgaryapln.org

Planning is too important for the beginning of a project

Planning in projects, agile or traditional, is a critical activity, but it is only as good as the information it is based on. The bulk of planning effort should not be reserved for when we know least about a project - at the beginning. Instead planning needs to occur throughout the project and plans need to evolve to reflect the changing realities of projects.

All too often projects begin to diverge from plans and the assumption is that the project needs bringing back on track. Well, perhaps the plan was lousy? The quote “The map is not the territory” from Alfred Korzybski, nicely summarizes the position. When reality diverges from the plan, it is reality we have to rely on. Now, I am not suggesting that we do not track to plans and just let things take as long as they like. Rather, we insert the step of analyzing why the plan and the project have diverged; in software projects the reason is often we had a poor initial plan.