DevSmart

Agility Is for Managers, Too

Is there a better way to to deliver a working product on schedule and under budget? A review of Mike Cohen's "Agile Estimating and Planning."

• By Mike Gunderloy
• 12/01/2006

As anyone who's run a software project knows, it's tough to deliver a working product on schedule and under 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 developers' workstations), you've probably wondered if there's a better way to do things. In fact, there is. At least, that's the premise of Mike Cohn's book, "Agile Estimating and Planning."

The central tenet of this tome is that most managerial activities can benefit from agile techniques. Of course, agile has become a hugely popular methodology, reaching the point where there are now more agile books, seminars, Web sites, coaches and whatnot than ever before. Refreshingly, Cohn strips away much of the hype and anchors his approach in the four simple value statements from the original Agile Manifesto:

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

One of the key innovations of the agile methodology is the de-emphasis of planning in software development. Planning in the 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 that results in mountains of paperwork that no one ever reads -- has no place in this world.

Instead, Cohn illuminates how the agile method replaces obtuse planning with estimation. Agile teams must still plan for the release, the iteration and the day's work. The author 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 quickly building consensus estimates of the relative difficulty of different tasks.

Working through the chapters on these techniques, and figuring out which ones appeal to you, will arm your team with tools for building effective estimates. The best thing is that all of these techniques incorporate continuous refinement, so most teams get better at them as they go along.

Planning for Value

Highlights
	Estimating in the agile methodology
	Ways to prioritize planning
	Successful planning in a fluid environment
	Scheduling by iteration length and team velocity
	Tracking and the agile "standard model"
	Strengths of the agile model
Prentice Hall PTR (c)2006 ISBN 0131479415 List price $44.99

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 also shows ways to set priorities using everything from informal brainstorming to formal math. Finally, he emphasizes the fluid nature of this kind of planning. As an agile planner, you must listen to the customer and be ready to change your mind about what's important based on shifting customer needs over the course of a project.

The agile practice is well developed in the area of scheduling and tracking projects, so it's hardly a surprise that "Agile Estimating and Planning" devotes plenty of pages to this area. On the scheduling side, Cohn pays a lot of attention to selecting an iteration length (the amount of time spent 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 burn-down charts, which are a part of the "standard model" of agile by now. 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.

Agile Ambitions
The most important part of the book actually 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:

	Re-planning 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 might also help silence critics who think of agile methodologies as a way for lazy programmers to justify their own poor planning.

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, this book can be very useful indeed.