Chapter 7: Planning for Agility


Overview

Planning is usually one of the most painful, undervalued, and even vilified project management activities in the agile environment. Why? Project managers are most likely attempting to apply a classic planning process when they need an agile one. This chapter examines some of the key characteristics of planning required in an agile environment and how to recognize them, reduce the pain, and enhance the value of planning.

Today's projects are urgent, exciting, and critical to business success—and they provoke different spoken and unspoken feelings about planning: "We need to move fast out of the gate or we'll risk losing out to the competition", or "Spending up-front time planning will slow us down. I already know what to do, so let me go start doing it!"

On the flip side, you will rarely find an experienced professional who is 100 percent against any sort of planning activity. "We need a plan that will guide us to our destination. In fact, a good plan is almost indispensable", or "I wouldn't agree to even start work on a project without a plan". These reflect some of the supportive feelings about planning.

So where is the disconnect? On the one hand, planning is a waste of time. On the other, it's a must do. The answer lies in recognizing that business and projects have changed. Nowadays there's incredible urgency to move fast. There is also project uncertainty, which makes us nervous about solidifying requirements or committing to a schedule. Our common sense tells us that we obviously need a plan, but our experience tells us that there is not enough value added for the effort expended, and furthermore, the plan may come back to bite us. We need agility—and planning seems to be an obstacle to obtaining it.

Classic planning conjures up images of large meetings, work breakdown structures, Gantt charts, resource loading, all sorts of swags, and long-range commitments. This may be a slight exaggeration, and I don't want to belittle this type of planning because it is highly effective for managing projects in which the basic steps are well known. Installing and validating a new piece of production test equipment is a good example. We know how to manage this process, but since this is a new piece of equipment, it will be slightly different from the last installation project. In this classic environment, there is no good reason why we shouldn't be able to create and commit to a detailed plan of this type.

But what about the agile environment, where we are trying to create something totally new and nothing similar has been done before? Does the classic planning process still make sense? Probably not. We shouldn't be spending a lot of up-front effort planning six or more months out when a discovery or decision made in the next three weeks could change everything. This is an important point, but often it's hard to recognize, especially when the level of uncertainty is not clear.

Agile Strategy

Only extend your detailed planning into the foreseeable future, to the next milestone or decision point, but not much further. Extended plans are risky and can frustrate team members being asked to create them.

To the project manager, a new project may seem similar to previous efforts, but to the technical team it may present totally new challenges. Since the project manager is not usually the technical expert, the level of project uncertainty should be discussed and agreed to early in the planning process by all key players. By making this effort up-front, the project manager is helping to set the tone regarding the planning methodology for the remainder of the project—specifically, how frequently or infrequently planning activities will take place. Essentially, the team should be expected to have detailed plans, but only up to the point where the project direction is still clearly visible. Once we reach the point where project uncertainty starts to blur the course, we will limit planning to high-level pathways. For example, let's say that we plan to produce a small lot of prototype circuit boards in three months. The next stage of the project is testing, which will ideally be at the final product level but may have to be at the subassembly level, and each of these pathways have specific and unique details that need to be planned out. The decision on which path to take depends on the delivery of a series of other components by outside suppliers who are running into difficulties and can't currently commit to a delivery date. Classic PM methods would teach us that we should have a detailed task list for completion of the circuit boards, as well as for each contingent pathway (final or subassembly-level testing). In the agile case, we also have a detailed timeline for completion of the circuit boards, but we only want a high-level understanding of the requirements for doing either final product or subassembly testing at this time, not the detailed task planning. In this way, the team will not get frustrated trying to create details around something that is too far out in the future, while the project manager will still be getting solid plans for the near term. Once the uncertainty around the outside supplier clears, the team would know which path to take and create the necessary detailed plans.

Agile Strategy

Set the tone for the project planning process by facilitating a team discussion on the level of technical and business uncertainty associated with the project. This, in turn, will help team members understand the scope and frequency of planning efforts throughout the project (i.e., high uncertainty leads to small but frequent detailed planning efforts, while low uncertainty leads to larger and less frequent detailed planning activities).

This does not mean that we can ditch the planning effort for projects that involve uncertainty, only that we have to plan for agility in different ways. Let's look at a few dimensions of the planning process and how they differ in classic and agile environments.




Agile Project Management(c) How to Succeed in the Face of Changing Project Requirements
Agile Project Management: How to Succeed in the Face of Changing Project Requirements
ISBN: 0814471765
EAN: 2147483647
Year: 2006
Pages: 96
Authors: Gary Chin

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net