LeadingAnswers: Leadership and Agile Project Management Blog

Project Progress, Optical Illusions, and the Simpsons

My last post was on modifying Parking Lot Diagrams to use the area of boxes to show the relative effort of differing parts of the system. The idea was that while traditional Parking Lot diagrams are a great way of summarizing progress at a project level, the customary approach of giving all the feature groups the same size box may lead people to believe these chunks of functionality are of equivalent size or complexity.

In the boxes below, the number in brackets describes the feature count, but this requires people to read the numbers and then consider the relative sizes. My goal was to create a new graphical summary that depicts the relative sizes via box area to make the summaries easier to understand.

So a standard Parking Lot diagram like this...

becomes a scaled Parking Lot diagram like this...

In the second example we can quickly see the relative estimated sizes of the areas of work, with for example, “Enter Order Details” being three times the size (in area) of “Create New Order”. In this example to keep things simple, I am using feature count (15 vs 5) to depict effort and area. Most projects will use development effort in points or person days as the scaling factor.

Anyway, I have been using these scaled Parking Lot diagrams on my projects for a while, created quite laboriously in Excel and PowerPoint, and I was hoping that someone with better skills than I have could help me streamline the process. Well, in typical fashion, soon after posting I learned that:

A)    I may be asking the wrong question
B)    My invented solution has already been done before and far more elegantly
C)    It has been done on the Simpsons

Oh, the joy of the internet! Actually this is of course a great thing and now I can progress from a much firmer foundation, and far quicker than my slow evolution was taking me.

When it comes to Excel acrobatics, Chandoo from the “Pointy Haired Dilbert” Excel and Charting web site is a great source of information, so I put the question to him. “How can I easily create the scaled Parking Lot diagrams in Excel alone?”  Chandoo was very helpful and gentle with his response and explained that people are not very good at discerning data displayed as area, and we can often build unintentional optical illusions.
 


In this example from Chandoo’s site, the orange circles are the same size, but because of the surrounding images they look dissimilar. For further optical illusions with data see his post here.
 
However, if we want to create scaled area graphs in Excel, here is Chandoo’s recommendation for doing so:
1)    First make parking lots for each of the activities in regular sizes.
2)    Also, in a table, list all the activities and their efforts (or costs / budgets)
3)    Now, create a live-preview of the parking lots using the camera tool. One image per parking lot. (more here )
4)    Name the images in some logical order (like imgTask1, imgTask2...)
5)    Now write a small macro that would scale the imgTaskn based on the effort required for it.
6)    That is all. You can use these sized images in your scope diagram or something else very easily.

Next in my search for showing how work components contribute to the whole project, and our relative progress against each category, I created a graduated pie chart diagram.

 
Here the work areas are shown as pie segments, their pie size corresponding to their proportion of the whole project. Then progress in each area is superimposed as heavier colouring with a percent complete figure added.

It turns out this type of graph is a variant of a polar area diagram. Polar area diagrams are still sometimes called Nightingale Rose Graphs, after Florence Nightingale who is credited with creating them in 1858 to illustrate mortality rates in the Army.


 
Source: CoolInfoGraphics

A more recent use of a similar diagram has been created for the Simpsons 20th anniversary.   A combination Nightingale Rose Graph (polar area diagram), family tree and timeline, this chart connects the influences that impacted Matt Groening and the creators of the Simpsons as well as the shows that came after.


 
Source: CoolInfoGraphics


While these last two examples show factors other than percent complete against each segment it demonstrates how they can be used to create visually appealing charts that measure contribution to the whole and other characteristics.

However, the more I research, the more warnings I find like Chandoo’s. While visually seductive to people like me, folk are just not that good at understanding data represented as spatial areas.

Edward Tufte is a master of depicting data visually and an unabashed critic of many things visual. He is best known for his criticisms of PowerPoint presentations in his essay “The Cognitive Style of PowerPoint”.
 

Edward Tufte has this to say about Nightingale Rose Graphs:

“A Nightingale Rose by any other name would smell as foul?? These Nightingale Roses are also called "sector graphs", but to me they are just a type of pie chart and contain all the disadvantages of pie charts. What's wrong with pie charts? The only worst design than a pie chart is several of them, for then the viewer is asked to compare quantities in spatial disarray both within and between pieces." (Page 178, The Visual Display of Quantitative Information)

So what’s next for me? Well, being a visual, right-brain biased kind of person, I will keep looking (ha) for new ways to depict work aggregation and project progress. As I mentioned in my previous post, while Gantt charts can provide this information, there is in my experience, such a bad perception of them (perhaps because they are largely used incorrectly like PowerPoint) that they switch people off rather than inform and engage people about progress and issues.

I am still a fan of burn-down and burn-up graphs, in particular Cumulative Flow Diagrams, but they focus on the numbers (days, points, stories) rather than functional areas the business often relate better to. Like the dials and the windscreen in a car, we need both quantitative (data) and Qualitative (observed) metrics to get a balanced picture of data and progress towards a goal we understand and recognize.

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.

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?...

Non-Functional Requirements - Minimal Checklist

All IT systems at some point in their lifecycle need to consider non-functional requirements and their testing. For some projects these requirements warrant extensive work and for other project domains a quick check through may be sufficient. As a minimum, the following list can be a helpful reminder to ensure you have covered the basics.  Based on your own project characteristics, I would recommend the topics are converted into SMART (Specific, Measurable, Attainable, Realisable, Timeboxed / Traceable) requirements with the detail and rigour appropriate to your project.

The list is also available at the bottom of the article as a one-page PDF document. While it is easy to make the list longer by adding more items, I would really like to hear how to make the list better while keeping it on one page (and readable) to share with other visitors here.

Security
  • Login requirements - access levels, CRUD levels
  • Password requirements - length, special characters, expiry, recycling policies
  • Inactivity timeouts – durations, actions

Audit
  • Audited elements – what business elements will be audited?
  • Audited fields – which data fields will be audited?
  • Audit file characteristics - before image, after image, user and time stamp, etc

Agile in New Orleans

Next week I’ll be teaching a two day Agile Project Management course for the PMI in New Orleans. The class sold out quickly; I only teach 3 or 4 times a year for the PMI and I wondered if registration numbers would be down this year. The fact that it filled up so quickly is very positive and perhaps more people are tuning to agile as a way to get more work done with less budget.

This year’s Agile Business Conference in London has the theme of “Driving Success in Adversity” and I have submitted a presentation outline and plan to attend. There submission system states “This year we invite presentations and tutorials emphasising how Agile practices promote efficiency in project delivery, guarantee business value and optimise return on investment.” This seems a great theme, agile is all about maximizing business value, and I am looking forward to the conference.
 
Meanwhile, in New Orleans next week, I am keen to hear how organizations are currently using agile methods within their organizations to add value. (I am also looking forward to sampling the food and feeling some warmer weather after a long Canadian winter!)

Lifecycle Variables

I have written a couple of posts now (here and here) about the new PMBOK v4 guide due out soon. One of the new graphs included helps describe how project characteristics change over the project life time.
 

The top blue line of the graph is used to illustrate how Stakeholder Influence, Risk and Uncertainty start off high and then reduce as the project progresses. The Escalating orange line illustrates how the Cost of Changes increase dramatically over the project timeline.

Quite a lot has already been written on flattening the Cost of Change curve within agile, so I will leave that for now and focus first on the top line.

Before discussing ideas such as how ongoing business input in, for example, prioritization of the remaining work prolongs their ability to influence the project, we should take a moment to understand the PMBOK audience. The PMBOK is not just for software projects, or IT projects, it is an industry agnostic guide relevant to construction, engineering, and manufacturing among other disciplines.

As a general guide, I think these curves make sense, especially outside of software projects. The ability to influence does decline rapidly once designs are committed and construction begins. Likewise, Risks and Uncertainty also reduce generally later in the project once technical obstacles have been overcome.

Software though is different, actually I would hazard a guess that every industry is different really, however software is the one that I know about. Software exhibits a characteristic known as “Extreme Modifiability” meaning we can make many changes, even late in the lifecycle and still be successful. While it would be difficult to move a bridge 3 miles upstream when it was 75% complete; we could choose to move validation logic from the presentation layer, to a middle tier, or a database trigger late into a project.

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.

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

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

Schedule Questions: Pair Programming and the PNR Curve

Converting effort estimates into project durations and team sizes is an important part of project planning. How this is done varies from project manager to project manager, to some it is an art, others a science, and to many a case of living with everyday constraints. Today I will focus on the science and its implication to pair programming.

If your initial project estimates indicate 72 person months of effort how do you best resource it?

1 person for 72 months?
72 people for 1 month?
6 people for 12 months?

Intuitively we know that 1 person for 72 months might work (providing they had all the right skills) but typically business wants the benefits of a project as soon as possible. 72 people for 1 month is extremely unlikely to work, unless the project is simple and massively parallel, like cleaning oil off rocks on a beach. Usually adding more resources beyond an optimal level provides diminishing rates of return. As the old saying goes, “You can not make a baby in one month with nine women, (although it might be fun to try.)”. Also as Fredrick Brooks stated in, The Mythical Man Month ”Adding resources to a project that is already late will make it later”. So, given an effort estimate how do we determine the optimal team size and schedule to deliver quickly and keep costs down?

While adding team members to a project increases costs in a linear fashion, the project timeline is not reduced in a corresponding linear way. Research by Putnam Norden found that for projects that require communication and learning (like software projects), the effort to time curve follows a Rayleigh distribution. Putnam confirmed that this curved applied to software projects in his article “A General Empirical Solution to the Macro Software Sizing and Estimation problem”, IEEE Transactions of SW Engineering, July 1978 and the curve became known as the Putnam Norden Rayleigh curve or PNR Staffing curve as shown below.

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