Agility is for Managers Too

Sofware project managers need to find that middle ground between planned and agile development processes. This book can help.

• By Mike Gunderloy
• 11/20/2006

Ah, if only managing software projects were as simple as the bedtime escapades of young Jack. But as anyone who’s tried to run a software project knows, there’s a lot to bringing together people and other resources to deliver a working product in some reasonable time and within an acceptable budget. If you’ve struggled with Gantt charts and detailed, up-front project plans (that somehow never seem to reflect what’s actually going on at the developer’s workstations), you’ve probably wondered whether there’s a better way to do things. The message of Mike Cohn’s Agile Estimating and Planning (Prentice Hall PTR, 2006) is that these most managerial of activities can benefit from agile techniques.

What is this "Agile," Anyhow?
There’s been some buzz lately about "good agile" and "bad agile" and debate about whether agile approaches are even worthwhile at all. Most of this is just the predictable backlash against any popular methodology; "agile" has reached the point now where it’s become an industry, and there are more agile books and seminars and Web sites and coaches and what-not than ever before. Refreshingly, Cohn anchors his approach in the four simple value statements from the original Agile Manifesto, valuing:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Given these core beliefs -- and their natural consequence that the entire software team has to work together to meet a common goal -- one thing becomes clear about agile planning: It does not occupy the privileged position that we most commonly think of for planning activity.

Planning in an agile world, like many other things, is a support activity, useful only to the extent that it helps a team meet a customer’s needs by delivering high-quality software. Any other planning (especially the ponderous cover-your-butt variety of planning that results in mountains of paperwork that no one ever reads once, let alone twice) has no place in this world.

Estimating in the Agile Tradition
But the removal of planning from the spotlight doesn’t mean that it can be dispensed with entirely. An agile team still needs to plan for the release, the iteration, and the day’s work. Cohn does a good job of explaining and illustrating some of the most common agile practices for estimating how much work can be accomplished in a given chunk of time:

• Estimating by story points is a way of judging the relative size of different chunks of work that need to be done, and then employing feedback to figure out how many story points the team can accomplish in a single iteration.
• Estimating by ideal days tries to use clock time to make estimates, without taking into account all of the interruptions that break up our clock time into small slices.
• Planning Poker is a way for a small team to have some fun while coming to consensus estimates of the relative difficulty of different tasks quickly (it resembles the classic Delphi method of futurist prediction, though I’m not sure the originators had that in mind).

Working through the chapters on these techniques, and figuring out which ones appeal to you, will give your team an arsenal of techniques for coming up with estimates of what they can get done. The best thing is that all of these techniques are defined for continuous refinement, so most teams get better at them as they go along.

Planning for Value
Knowing how long it takes to build software is only one piece of planning. It’s at least as important to figure out what order to do things in. Given a stack of 100 different requirements to implement, where do you start? In a traditional top-down planning world, you start with whatever your manager tells you to implement first -- but in agile land, things are different. Cohn looks at a variety of ways to prioritize features, including value, cost, knowledge development, and risk removal. He works through a variety of ways, from informal brainstorming to formal math, to set your priorities. He also emphasizes the relatively fluid nature of this sort of thing -- as an agile planner, you need to listen to the customer and be ready to change your mind about what’s important as their needs shift over the course of a project.

Scheduling and Tracking
A big chunk of the book is devoted to scheduling and tracking projects -- not surprising, as this is an area in which agile practice is fairly well developed. On the scheduling side, Cohn pays a lot of attention to selecting an iteration length (an iteration being the amount of time you spend working between delivering working versions of the software to your customer) and to estimating team velocity (how much work can be done per iteration). There’s also good advice on how to protect yourself from uncertainty with proper scheduling.

On the tracking side, you’ll meet the classic burndown charts, which are a part of the "standard model" of agile by now -- in fact, they exist in more than one variant. There’s also a good discussion of how you communicate the plan and progress to stakeholders, especially ones who may not be comfortable with all this agile stuff.

Wrapping up the Package
I think the most important part of this book comes quite late, in the chapter "Why Agile Planning Works." In it, Cohn summarizes his thoughts on the strengths of an agile approach to this portion of the software process:

• Replanning occurs frequently
• Estimates of size and duration are separated
• Plans are made at different levels
• Plans are based on features, not tasks
• Small stories keep work flowing
• Work in process is eliminated every iteration
• Tracking is at the team level
• Uncertainty is acknowledged and planned for

You could certainly get some of these strengths out of a non-agile plan, but the fact that they can all be pulled together coherently as part of an agile planning process is a point in favor of this process. It also ought to do something (though it probably won’t) to silence those who think of agile methodologies as a way for lazy programmers to justify their own lack of ability to plan. Of course, as with anything else in the software world, there are mature and immature agile teams out there.

If you have ambitions to be part of a mature agile team or to help an immature team become more mature, you’ll probably find at least some of the advice in this book very useful indeed.

Want to read more of Mike’s work? Visit his Larkware site for daily updates at www.larkware.com.