LeadingAnswers: Leadership and Agile Project Management Blog

The APLN Seattle Leadership Summit

The APLN Seattle Leadership Summit is shaping up to be quite the learning event. Here are some of the highlights:

• Collaboration Games by Luke Hohmann and Allan Shalloway
• Kanban by David Anderson and Corey Ladas
• Scrum by Brent Barton and Lance Young
• Getting Started with Agile by Mitch Lacey and Julie Chickering
• Writing Agile Contracts by Bruce Eckfeldt and Jim Benson
• Agile Program Management by Mike Griffiths and Mike Cottmeyer
• Real Option Theory by Chris Matts and Olav Maassen
• Agile User Experience by Arlen Bankston and Jeff Patten

The program also includes two leadership keynotes by:

• Lisa Haneberg, author of seven books including 10 Steps to Be a Successful Manager and Two Weeks to a Breakthrough.

• John Yuzdepski, a partner at Management Concepts LLC specializing in product transitions and commercialization of new technology and a veteran of the mobile communications industry.

While I am involved in facilitating a session on Agile Program Management with Mike Cottmeyer, my real motivation for attending is to hear the other speakers present.

I am a big fan of Luke’s work on Collaboration Games and posted on it previously here. As too with David’s work on Kanban here and Jim’s work on Agile Contracts here. I know Mitch Lacey does a great job of explaining agile and I was introduced to Real Options as a reviewer of Preston Smith’s Flexible Product Development book and want to learn more.

(I’m sure Mike Cottmeyer can handle the session by himself, I think I’ll be sneaking out to attend some the other sessions!)

So, if you can get to Seattle July 17-18 I recommend the event as the best value agile project leadership training you will find this year. $300 for two days of leading edge knowledge and experience is excellent value (plus you could claim 16 self-directed-learning PDUs too, if you need PDUs).

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

Calgery APLN Meeting Slides Posted

On May 15 I presented on “Decomposing large programs into agile projects” and “Mapping the PMI Processes to Agile Best Practices” at the Calgary APLN meeting. I have uploaded the slides in PDF format and also a zip file containing the hyperlinked Process Groups / Knowledge Areas mapping to Agile practices. (You will need to unzip the PowerPoint slide and Word files into the same directory for the hyperlinks to work correctly.)

Calgary APLN May 15 Slides.pdf

PMI Agile Mappings.ZIP

The timing of the presentation was very close to Michele Sliger and  Stacia Broderick’s release of their new book “The Software Project Manager's Bridge to Agility”. I was hoping we could give a copy of their book away as a door prize, but the book was available about a week too late. However, I received a copy this weekend (thanks Michele, Stacia) it looks good and I look forward to reading it. We also have some copies on order as door prizes for future meetings.

Agile Alliance Update

I recently returned from the Agile Alliance Board meeting in Boston. Three times a year we meet as the board to review progress, plan Agile Alliance programs, conferences and member services. This latest meeting was my favourite. Not only did we get lots done in the two day period, but the process (mainly open space) worked really well and rather than committee work being frustratingly slow, it progressed well, and I came away energized by the whole experience!
We had many good discussions including:

Conference 2009 Update – Next year’s agile conference will most likely by in Chicago, at the Hyatt downtown hotel. Options are being kept open and the venue would work well with between 1200-2400 attendees.

  <Todd Little explains the dynamics of conference venue selection>

Click the "Contine Reading..." link below for more updates.

Calgary APLN Meeting: PMI Framework and Agile

At the next Calgary APLN meeting I will be discussing how the PMI framework maps onto Agile best practices. Yikes, what brought me to this!

Well, back in October at the Calgary APLN planning meeting we asked attendees what they would like to hear about this year. People made suggestions and voted on the topics, the top 5 were:

1) Using Agile on distributed teams
2) Team collaboration / motivation / accountability
3) How to decompose large programs into agile projects
4) Mapping the PMI Framework to Agile best practices
5) Fitting agile into the constraints imposed by the business

The first two have been covered; last November Jane Robarts spoke about her first hand experience of managing distributed agile teams and in February Gerard Meszaros spoke about team collaboration. Both were excellent talks and we have an experience report based on topic 5 “Fitting agile into the constraints imposed by the business” scheduled for June.

This leaves “3) How to decompose large programs into agile projects” and “4) Mapping PMI Framework to Agile best practices”.

Not surprisingly, we had no volunteers for the PMI to agile mapping so on May 15 I have the dubious pleasure of presenting on these two topics; weaving the risk reduction concepts of smaller, more agile projects with the connects-and-disconnects of PMI to agile processes.

When I saw the topic “Mapping the PMI Framework to agile best practices” my first thoughts were; “Don’t” and ‘Why would you want to?” it seemed akin to mapping horse-and-cart operating tips to car driving tips. They are just different and have divergent philosophies.

However, I can see that asking for mappings helps provide a familiar context for new knowledge. It also reassures people that everything in our old process is covered-off in the new process and there are no gaps. So, to help provide context, but not to imply equivalence, mapping the PMI framework to agile methods will be explored with the connection points and gaps identified. I will be careful to emphasize the viewpoint shifts in addition to the process differences.

If you can, please join us for what I hope will be an informative and entertaining presentation. Spaces are limited so register in advance to reserve your place. www.calgaryapln.org. For those that cannot attend in person, I will post the slides and resources here after the presentation.

Travel and Training

I have been traveling and training lots recently and not had much time to post new entries here.

However, the travel time has allowed me to read more and two books I am current enjoying are Leadership Agility by Joiner, Josephs and A Leader Becomes a Leader by J. Sheehan.

Neither is specifically about Agile methods, but both highlight great ideas that are universally applicable. I will post complete reviews when I have finished them.

My traveling and training courses continue next week when I will be teaching a public 2 day Agile Project Management course in Scottsdale for the PMI. I will be repeating it in Seattle May 20-21 and Washington D.C. August 11, 12.

Other public courses coming up include a 1 day in Sacramento June 20 and a two day in Anchorage September 11-12. These courses are proving popular (Scottsdale and Seattle are sold-out) but I also offer private courses that can be tailored to company requirements. Please see here for a full list.

Once the Scottsdale course is over I will resume regular postings here.

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

Top 10 Team Practices

There are some great books on agile team dynamics nowadays. My personal favorites include:

• Collaboration Explained by Jean Tabaka
• Agile Retrospectives by Esther Derby, Diana Larsen, Ken Schwaber
• Right-Brain Project Management by Michael Aucoin
• Great Boss Dead Boss by Ray Immelman
• The Blind Men and the Elephant by David Schmaltz

The problem is that most people do not get the time they want or need to read about these topics. So, I have created the following: Top 10 Team Practices list and one-page printer friendly version to remind us of some of the basic points.

If you lead a team then print the sheet and post it somewhere visible and do a mental inventory of the practices from time to time. If you are a member of a team that could do with a boost, print a copy and post it on your manager’s wall, I am sure they will thank you for it! (actual results may vary.)

1) Empower them – By giving control for local decision making and work sequencing to the team we gain the advantages of additional insights, better motivated teams, and more practical plans with less waiting. 

2) Listen to them – The team is closer to the technical details of the project and also best placed to determine the most successful solutions to project challenges and problems. Encouraging the team to solve the project problems has two main benefits. It demonstrates they are valued for their insight as well as their output, which makes people feel more involved and appreciated. Also, solutions suggested by the team are more likely to be embraced and executed with enthusiasm. It is better to have a 70% optimal solution executed with 80% enthusiasm than a 100% optimal solution executed with 40% enthusiasm.

No Glory in “The Middle Way“

(The “Balanced Blend” Manifesto takes Shape)

Don’t really buy into all the hype of agile? Think it works up to a point, but real-life is actually more complicated and demands more of a hybrid approach? – Don’t worry, you are not alone.

Since helping define DSDM in 1994, I have spent the last 14 years helping organizations adopt agile methods like DSDM, Scrum, XP, FDD, etc and have come to realize, like many others, that these methods are not the solution. Instead they are the over-simplified starting points that you need to blend into what already works within the organization. Then overlay and support with additional approaches to create successful project ecosystems.

We need simplified schematics of systems to assist comprehension and discussion. However, all too often these simplified models are put into production as the entire solution and then problems occur.  Like a simplified model of a car braking system, it is useful in helping us understand how the system works in theory, yet is full of design flaws for practical implementation.

In real life, servo’s and pumps are needed to amplify the braking force from the pedal. There is not a single shared-fluid system, but instead two diagonally opposed systems (so a leak does not result in total brake failure or pulling to one side in a left and right split system). In addition to the basic system shown here, cars also employ an array of supporting systems for fluid level monitoring, ABS, wear detection, etc.

Luckily people do not read about the basics of car braking systems and then decide to replace the one on their car with their own design. However plenty of people read about agile methods and decide to implement that as their new software production system.

The good news is that the state of existing software production systems is often very poor and so implementing any kind of better conceived system is an improvement. (A basic sub-optimal braking system is probably better than relying on throwing an anchor out the window and hoping it snags on something to stop you!) The problems occur when the current system is not optimal, but understood and working; and it is then replaced by an oversimplified alternative.

Agile 2008 Submission Review Marathon

Phew, I am done! We had over 120 submissions for the Agile 2008 “Leadership and Teams” stage which is a great response. However at about 5-10 minutes each to read the bio’s, proposal and submit a review it adds up to a large evaluation effort. Here’s how the stages and numbers broke down:

PMBOK 4 – This Time It’s Iterative!

(Well, maybe a little more iterative)

The current Project Management Body Of Knowledge (PMBOK) Guide is labeled “Third Edition” and was published in 2004. Every 4 years the Project Management Institute (PMI) brings out a new version and the Fourth Edition has just been released to reviewers in Exposure Draft format.

I was a contributor and reviewer for version 3 and will likely submit some feedback for version 4 too. One thing that will be of interest to agile project managers is the increased acceptance of iterative lifecycles.

The concepts of rolling wave planning and progressive elaboration have been in the PMBOK since at least the 2000 edition that I know of. These concepts address the idea that planning near term work in detail and later work in less detail. Then as new details emerge, going back to the plans and updating them with the new data. This is common sense to those in the agile community, but it sometimes surprises people that it has been in the PMBOK for the last 8 years since, unfortunately, many people skim past these important principles in the PMBOK Guide.

Likewise, previous versions of the PMBOK have mentioned alternative lifecycles and nesting of activities. Yet with the PMBOK v 4 draft we start to see more embodiment of iterative approaches.

Collaboration Tools

Last week’s Calgary APLN meeting was on Team Collaboration and afterwards an attendee volunteered a really neat and useful team assessment questionnaire. Gerard Meszaros (author of XUnit Test Patterns) who also has strong project management and team collaboration knowledge, presented on “Using Collaboration to Build Team Commitment”. It was a great presentation and referenced some of the Jean Tabaka’s work from the book “Collaboration Explained”.

I have known Jean since her facilitation work with DSDM in the mid 90’s and she really knows about teams, motivation and working effectively with people. Chapter 4 of her book talks about characteristics of high performance teams. After the presentation, Edgardo Gonzalez sent me a spreadsheet based on these criteria that allows quick and easy team assessments.

As seen from the screenshot above, the tool is a one page Excel sheet that assesses the team’s abilities in:
• Self Organizing
• Empowered to Make Decisions
• Belief in Vision and Success
• Committed Team
• Trust Each Other
• Participatory Decision Making
• Consensus-Driven
• Constructive Disagreement

In our example of a fictitious project, four people completed the questionnaire. The collective team score is shown on the left hand radar chart (indicating a weakness in the “Consensus Driven” field) and the individual scores are shown on the right hand radar diagram. Colour coding flags areas as “Red” for concern, “Yellow” for warning (“Trust…” in the example), and “Green” for good.

Not only is the spreadsheet an effective team diagnostic, but a good lesson in Excel spreadsheet formatting and validation. Thanks Edgardo for agreeing to make this available to everyone and to Gerard and Jean for their work in this important field.

You can download the spreadsheet for your own use below:

Collaborative Team Assessment.xls

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.

We Don’t Want User Input!

Do you really need those pesky users on your project, forever changing their minds and requesting new functionality just as you are about to be done?

When I was at school, my physic’s teacher was fond of telling us that, "if it were not for the students I would enjoy teaching." The same is true for users, they may cause us issues and headaches, but they are the reason we are there and developing software in the first place.

Why we Need User Input
The truth is that on agile projects we do not want user input we actually need user input in order to be successful. Agile projects are deliberately light on capturing initial requirements because we realize that requirements are likely to change, and evaluation of an emerging system will surface new requirements and improvements to existing requirements that we want to encourage.

Agile 2008 – “Leadership and Teams” Stage

This year’s Agile conference in Toronto this August will be structured slightly differently. Following a music festival structure, the conference will be divided into “stages” to cover different topics. I was able to visit the Agile 2008 conference venue in December when the last Agile Alliance Board meeting was held there and we toured the facility with the Agile 2008 Conference Committee.

Johanna Rothman and I are the “Leadership and Teams” chairs for the conference and we have been allocated a great venue; a large, bright ballroom with high ceilings and lots of natural light. This year the conference has much more space and larger mingling areas both indoors and out which I am sure will help.

On the “Leadership and Teams” stage we are looking for submissions on, you guessed it, leadership and team focused experience reports, research papers, tutorials, and presentations. Now is a great time to submit a proposal, so take a look at the submission system and propose your ideas.

The other element I am excited about is the submission system selection process. I have written previously about encouraging the agile community to prioritize our proposal backlog (list of submissions) and this year it is happening. On the Drupal based submission system anyone can write a review for a session and “up-vote” or “down-vote” a proposal. The cumulative scores for proposals help determine what gets selected.

This will not be a totally crowdsourced selection (like ideagora: Cambrian House), instead panel review will still be involved, but it is great to see the conference users (attendees) involved in prioritizing the features (proposals) for the event.

So, head over to the submission system and up-vote your buddy’s submission, down-vote anything from that guy that won’t return your emails (only kidding) or better yet, submit something valuable on Leadership and Teams for the conference, we would love to see it.

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.

Personal Agility – Free Webinar

Is agile about new tools and techniques or more a mindset? Philippe Kruchten asserts “agility is not a technology, science, or product but a culture”. This makes sense to me; innovation comes in waves (object oriented programming, business process engineering, lean production, etc); and while they all have their merits, most fail to deliver the full potential of their benefits because people concentrate on the process rather than the mindset. At the heart of agile is a mindset not a toolset.

I was speaking to Christopher Avery today, author of “Teamwork is an Individual Skill” and he shared some thoughts on personal agility and team motivation. Christopher is great for this since he approaches agility and team work from a psychological side whereas my thoughts are usually based on observation and trial and error.

We were discussing motivation and how to motivate peers who you do not necessarily have positional power over. Bosses may try to create motivation via carrot and stick approaches, but these are weak and short lived. People grow tired of such manipulation and find ways to break the system.

Instead, Christopher talked about “Intrinsic Motivation”, a more powerful motivation that comes from within.  People want to be on a winning team, but are not sure how to find or create them. The secret lies in understanding what “winning” means for others and then creating wins around you. In practical terms this means asking people “what is in it for them?” i.e. what is it they would like to learn, do, or gain (beyond a paycheck) from the project and then provide opportunities for these things to happen.

At first this sounded a little odd to me, a bit too touchy-feely. Asking people what they did over the weekend is one thing, but asking them what they want out of a project seems, well, invasive, too personal. However when you think about it, that is backwards, after all the project is something we all have in common. What they did with their spouse over the weekend, now that could be personal!

Telling someone what you really want to get out of a project might seem a little odd too, but fears of doing so indicate a ‘scarcity model’ to information. Why should we worry if people know what we really like to do or gain, chances are they will make opportunities available for us to do them. Helping others get what they want from projects creates an upward spiral of support and co-operation, which when you think about it, is the heart of a winning team.

Chatting to Christopher is always refreshing, he shares so much useful information that I struggle to retain it all. Fortunately for us Chris has recorded a free tele-seminar on Mastering Personal Agility. I heartily recommend it, the people side of projects have the greatest leverage, even small improvements here can yield large benefits; be sure to check it out.

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.

The DOI, Made to Slip?

Nearly three years on, why is the Declaration Of Interdependence (DOI) still not widely known or referenced?

The chances are that most readers will not be familiar with the DOI, yet it is a great piece of work. The DOI lists principles that, like the Agile Manifesto principles, help point the way for teams working on agile projects. It was created by the founders of the Agile Project Leadership Network (APLN) to guide agile project management and rally support for an uprising of new project management thinking.

Other than believing some of the wording was a little too clever for its own good and general consumption. I did not fully understand why it had been avoided. Then I read “Made to Stick” by Chip and Dan Heath and I realized that it has the stickiness and appeal of a greased electric eel.

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.

Agile Estimation – Upfront Estimates

This is the first of a couple of posts on agile estimation. I would like to thank Boris Mutafelija for submitting the topic request, while there has been much written on agile estimation; it is an area that comes up time and time again. Today I’ll cover the big picture view and upfront estimates.

First of all we need to understand that estimating software projects will always be problematic. It does not matter if it will be a traditional project or an agile one, software development projects are unique (we do not repeatedly build the same system) and the evaluation difficulties that make gathering upfront requirements tricky also make scoping and estimating hard too. So approach the problem conscious of the issues and limitations of any approach, keep in mind early estimates will have wide ranges of variability.

(Barry Boehm’s estimate convergence graph. At the time of Requirements Specification estimates are only likely to be in 1.5 X to 0.67X of the final project cost range. Calls for ± 10% are just not realistic on most software projects.)

Next we need to accept that at the start of a project, the estimation approach will be similar for agile or traditional projects. By this I mean we have very little to go on, probably no productivity data for the exact team undertaking the work and only a coarse grained view of the project scope and complexity. Agile projects become much easier to estimate once we have completed a few iterations and can start to gauge the true project velocity, but at the beginning we are in the same dilemma as traditional projects. Estimating the time required to build an unprecedented system with an unproven team.

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:

Agile In Atlanta – PMBOK to LWOK

I have just got back from the 2007 PMI Global Congress conference held in Atlanta, Georgia. It was a good conference and while I may question the applicability of traditional project management approaches for software development projects; for organizing a conference it is hard to question the results. I experienced no line-ups; good speaker support and a well thought out and organized conference.

My presentation on “Developments in Agile Project Management” was over subscribed and I was asked back to do an encore presentation which is a great endorsement for the level of interest in agile project management, especially from within the traditional PM community. When I presented on agile methods at the 2004 PMI Global Congress in Anaheim, I was the only presenter on agile methods there. Since then I have seen an increase year on year. Last year I counted four agile topics and this year six, which is a promising trend.

I met up with Mitch Lacey and Stein Dolan who were also presenting on agile methods at the conference and it was great to chat and discover we had a similar philosophy. This is that agile methods are merely additional tools for the project toolbox that work well given certain circumstances. They do not replace traditional methods, but instead can exist alongside them and can be used very effectively when the circumstances warrant. This is what Jim Collins calls” The Genius of the And” and the “Tyranny of the Or” by using a smart mix of traditional methods And agile we can better respond to project challenges and avoid the limitations of “either / Or” thinking.

It is good that the PMI is incorporating more agile content; lots of of today’s projects really need these techniques to be successful. Yet many agile practitioners are reluctant to take their message to the PMI, and prefer to focus on agile conferences. However as Henry David Thoreau reminds us “For every thousand hacking at the leaves of evil, there is one striking at the root” Not that the PMI is evil, but if we are to change the world of project management, then the PMI is a great place to start.

LWOK
My talk covered what’s new with Agile Project management and I was glad to be able to announce the Agile Project Leadership Network (APLN) LWOK program approved just a few days before.

While the PMI has its Project Management Body Of Knowledge (PMBOK) as its core set of agreed practices, little exists yet for agile project leaders. There are great resources scattered around different web sites, but no place we can point people to and say “go and start here, it will get you on your way”.

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:

<