7 PLANNING FOR AGILITY 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 suc- cess—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 98 P A 99 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 sched- ule.
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 effec- tive 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 rea- son 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 be- fore? 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 previ- ous efforts, but to the technical team it may present totally new chal- 100 A G I L E P R O J E C T M A N AG E M E N T lenges. 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. Es- sentially, 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 de- tailed 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 require- ments 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 neces- sary 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 P A 101 (i., 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 proj- ects 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.
Activities Versus Achievements Classical planning is based on activities. Once the key activities are identified, then resources are assigned, effort and duration are esti- mated, and a sequence is created. The problem with this approach for an agile project is that it is based on the team’s ability to accurately identify all of the activities in the project. For projects that have been done many times before, it is relatively easy to identify the major ac- tivities, and in fact, these projects often start out their planning effort with a template from the previous project.
For projects on the tech- nology development end of the spectrum, it’s quite a different story. Agile Strategy When planning an agile project, ask team members to identify the achievements or milestones required to complete the project, rather than the detailed tasks. Projects that operate on the edge of new technology tend to take a zigzag course toward their destination (see Figure 7-1). The technical leaders know the general direction they must go and the sequence of milestones that must be achieved.
What they don’t usually know is the exact path or pathways that they will take. For these reasons, it is somewhat impractical to attempt to construct a timeline based on ac- tivities. An attempt to do so may backfire by frustrating everyone in- 102 A G I L E P R O J E C T M A N AG E M E N T End Start General Direction of Project Figure 7-1. Projects that operate on the edge of technology tend to take a zigzag course toward their objectives.
A more practical approach is to construct your timeline based on achievements, since those are the things that the technical team will be focused on (see Figure 7-2). This is a subtle but critical difference between planning using agile methods versus classical methods. The upside of activity-based planning is that you are able to me- chanically capture, fairly accurately, both the sequence and duration dimensions of your timeline. While achievement-based planning only captures the sequence dimension, in the agile environment, achieve- ments (or milestones) are made up of several yet-to-be-defined activi- ties, and because there are multiple possible pathways leading to each achievement, there is no mechanical method to construct a good bottom-up time estimate.
This leaves us with the top-down method for estimating duration, which works rather well for an experienced team. I’ve found that technical people, while often resistant to formal project management, are actually very good at estimating durations of Agile Classic Project timelines are based on: Achievements Activities Figure 7-2. The basis of timelines in an agile versus classic environment. They don’t like the restrictions associated with commit- ting to a specific sequence of activities since they know that sequence will change.
However, they will commit to achieving a milestone in a certain amount of time if you don’t bother them too much with how they are going to do it (see Figure 7-3). Agile Strategy Use the top-down method for resource and duration estimation rather than the traditional bottom-up method. Estimates Versus Commitments The key to this type of estimating is to ask for a commitment rather than just a top-down estimate. Asking for a commitment brings the business dimension into clearer focus for the team member by emphasizing the impact of not meeting your commitment.
It also forces people to think through their approach more carefully, perhaps breaking it down into smaller achievements, which are, in turn, easier to get a handle on. Technical and creative environments are tricky quarters to plan within. The individuals who excel in these areas need room to explore and experiment with various ideas. The very concept of a project plan is at odds with the creative environment.
Approaching the planning effort by asking for top-down commitments for reaching the next achievement/milestone creates a win-win situation. You, the Agile Classic Activity durations are based on: Commitment Work x Resource Allocation Figure 7-3. The basis of activity durations in an agile versus classic environment. 104 A G I L E P R O J E C T M A N AG E M E N T project manager, get the information that you need to manage the project, and the technical expert will see a planning process that doesn’t restrict his creative side—and may actually help him to add valuable structure to the technical approach.
Finally, gaining commit- ments from individual team members is a great way to pull the whole team together and ensure that they are all rowing in the same direc- tion. Agile Strategy Combine your request to individuals for a top-down duration estimate on a milestone with a request for a commitment to meet that estimate. The process of building an achievement-based schedule using committed durations is not necessarily easy, but it will be more effec- tive in an agile environment. Commitments tend to be dependent on each other, so the whole team needs to work together and become engaged for this process to work.
Rather than spending energy to estimate resource allocations and durations along a single sequence of activities, as is done in the classic planning method, the team will find itself developing a primary pathway and several alternative pathways. They will be identifying decision points that will drive or eliminate certain pathways. And they will begin strategizing their overall ap- proach to the project. For these reasons, a network diagram is often a better mechanism than the more common Gantt chart for depicting the high-level view of the agile project.