I neglected to write about last night’s Agile Estimating and Planning session by Mike Cohn, who will be presenting most of the sessions I’m attending today. It was a good session – the main takeaway was that in planning projects, and particularly in estimating features for software, relative estimation is more accurate than absolute estimation. We’re better at realizing that one feature (or “user story”) is twice as difficult as something we’ve done previously. The idea is that then, once we’ve defined an abstract measure of work, we can gain a pretty good idea of the “velocity” or our team – the number of units of work we can accomplish during an iteration. Re-examining the plan versus results after each iteration helps us find a good equilibrium for our team.

This morning, my first session is Managing Agile Projects. It has a good bit of overlap with yesterday’s session, but addresses a broader array of topics. The prime concern is dispelling myths about agile project management – that agile projects are impossible to plan, that they don’t need to be managed because they are self-organizing, and that the project manager’s role is to buy pizza and get out of the way.

The first new tool to me is the “burndown chart”, which can be used for both releases and iterations within a release. In essence, the y axis is the amount of work remaining, the x axis represents the amount of time for the release or iteration. Each iteration or day, you update the work remaining, and connecting the line of work remaining over time gives you the ability to extrapolate and see how well you are tracking to the project schedule. It gives you a basis to begin investigating sources of slowdown or unexpected efficiency, adjust the release (either date or content) for the actual progress, and improve your estimation for next time.

On to the necessity of managing agile projects, we’re back to my problem of him talking about this stuff in terms of teams. He’s assessing the readiness of multiple teams for agile development. With just one team, we don’t have the luxury of evaluating team by team. We have the team we’ve built, and they’re very good at what they do.

The idea of a task board to “assign” tasks and track progress is fairly compelling. Some of this comes down to better planning of releases, and getting out from under the weight of bug fixes is key to accomplishing this. Also, a lot of these ideas seem predicated on the assumption that tasks to be accomplished are all new work, and thus features can be dropped and you can still deliver a release/iteration. In reality, many of our tasks are wholesale replacement of existing application components. Cutting features from a replcement for an existing component is not an option – a replacement MUST be feature equivalent. I suppose we could cut COMPLETION of the replacement from a given iteration and advance the completion to the next iteration, and cut the scope of the progress on replacement for that iteration. I’m not sure here, and will need to think about it further.

Many of these sessions are useful not only for the content, but also in getting me thinking about our development process and procedures, and how they can be improved. I don’t necessarily have good time to think about this stuff during the rush of a given week.

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium.