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

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.

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.

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.

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.

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?

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 [email protected] 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.

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