Last night I heard Mike Cohn speak about Agile Planning and Estimation. Mike’s a great speaker who I highly recommend to you seeing, but you may know him from his company, Mountain Goat software, or his book, User Stories Applied.

Though I’m lucky enough to practice many of the items he spoke about, my most favourite emphasised points of the night included:

• Focus on accuracy over precision;
• Avoid measuring items that are more than a magnitude apart; and
• Measure size over duration.

I find it interesting to see how most businesses plan for IT projects. The most common approach is for the business to get a set of proposed projects together, but get IT to cost them. They then decide on which one to do based on this input and what benefits are talked about and estimated costs.

When I see the costing process, I see it as heavy weight – lots of predictive plans with lots of magic weighting and theoretical costs. Worse still is that it sets the expectation that the cost is actually predictable when, in reality the detail you get and what it cost you from the original plan are far apart and you just spent a bucket load on this additional lengthy process (the estimate starts to become a promise).

An alternative I propose is a lighter weight approach with businesses focusing on what they want to do and not what projects a particular group within the business proposes. It’s more important to focus on the business problem first and the implementation details last so that both are aligned as closely as possible. After identifying what the business want to do they should next define how much they would like to spend. The amount needs to be feasible and measuring existing project costs and benefits and getting IT involvement is definitely required. Magic numbers plucked from thin air are never useful but do need to be balanced in terms of value maximisation and technical feasibility.

The focus for the project implementation should also be different from traditional methods. The focus should no longer be ‘keep to the plan’. It should instead maximise the value the business gets while keeping aligned with the business objective. Agile projects provide a great way of doing this by splitting down the detail into chunks that have identifiable value, getting the business to continually identify what is valuable in relation to their business objective and then getting the value faster and earlier than a big bang approach.

I’d love to hear what you think about this so please drop a comment.

Regular heart beat retrospectives are a useful tool for measuring how well the team is going. As someone responsible for project delivery, you want to maximise the amount of honest feedback you get (both positive or negative) as they all might pose risk to the project.

The amount of feedback you actually get is a useful indicator rating the team’s comfort level – either with each other, or with other people they report to. I’ve seen a number of feedback sessions stifled by one or two key people that sit inside the room, as people withhold their opinions for fear of negative consequences. Controlling people typically disengage individuals from the team and reduce the effectiveness of feedback you get. Uncomfortable silence or a minimal set of feedback are both signs that people may not be entirely comfortable.

Splitting the group into smaller teams might help to improve individual’s openness, introducing a speaking token so that one person is not always talking or even asking someone to leave is a last option.

The feedback I’ve most recently received on my latest project is how fun it has been. This enjoyment factor is common feedback I get when working on projects with agile values and practices. I do not think this theme is exclusive to agile projects but I definitely think it is more common.

I believe that projects run in this manner are a result of the Agile Manifesto statement of ‘Individuals and interactions over processes and tools’. A result of working closely together and striving for a common goal breaks down the focus on the individual and succeeds in building a fully functional team.

Why you should care as a Project Manager or as a Business Person?

Enjoying your work has a number of effects on the way that you work. I believe studies have disproved that happiness positively impacts productivity, but I believe that in the long term it still has a positive effect. More importantly I believe studies have proved that happiness positively affects staff retention.

If anything, my own opinions are that it works to reduce the overall risk of the project as each person builds on each other’s strengths and contributes positively when someone is at the low in their peaks and troughs. The similar alignment between all team members also leads to people improving the project in different ways because they want the project to succeed and not just because of individual motivations.

Note that working in this manner is not necessarily comfortable for all people but it’s usually because people have built up their own social barriers in order to work effectively in more traditional environments, or they don’t like working in teams.

Final day. More highlights include:

• Entertaining keynote with Kent Beck talking about what is more Extreme than XP, and leading on to the discussion about the Responsible Developer. Like XP, his talk focused more on the developer role in an organisation but talked about what comes next.
• A fun two-part workshop with Rachel Davies and David Hussman talking about Agile Project Parameters where we brainstormed and dicussed the questions we might ask as an agile coach during a Project Chartering session.

I’ve been having troubles posting things to my blog due to Internet access here, but this entry was written just after Sweden and England drew in the world cup (equivalent of midnight here in Finland), so here’s the recap of today’s goings on:

• Barry Boehm’s keynote – An interesting discussion in which he discussed different analysis models that could still be used in agile, considering risk management and balancing agility and discipline. He talked about the scaling of agile to scrum of scrums and research indicating where agile is most applicable.
• Panel of Notable Agile Leaders including (Angela Martin, Rachel Davies, Jutta Eckstein, David Hussman, Emmanuel Gaillot, Mary Poppendieck and Michael Feathers) holding a fantastic discussion on Politics and Religion in Agile Development. A lot of the advice they gave and their own ‘war stories’ struck a chord with me so much in my experiences and different projects I’ve worked on. It was great for them to all be so honest and give their opinions. Kudos to Angela for being an excellent moderator for the session!
• Value Stream Mapping – An excellent exercise with Mary Poppendieck, involving identifying waste in an entire value chain (i.e. when a customer requests a features and they are using it), and more interestingly the strategies or areas of focus for particular project examples.
• Coder’s Dojo – Coming half way through this session, I still had lots of fun with this hands of workshop presented by Christophe Thibaut and Emmanuel Gaillot. We did a bit of dynamic language group pairing adhering to a small set of well defined rules that I found fascinating from many different perspectives, most especially the social one.
• Final keynote by Jack Jarvik discussing methods he applied in the early 1990s that appear aligned or similar to many of the XP/Scrum practices.

What can I say, but what another fantastic day?