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.
Activities Versus Achievements
Classical planning is based on activities. Once the key activities are identified, then resources are assigned, effort and duration are estimated, 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 activities, and in fact, these projects often start out their planning effort with a template from the previous project. For projects on the technology 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 activities. An attempt to do so may backfire by frustrating everyone in volved. 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.
Figure 7-1: Projects that operate on the edge of technology tend to take a zigzag course toward their objectives.
Figure 7-2: The basis of timelines in an agile versus classic environment.
The upside of activity-based planning is that you are able to mechanically 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, achievements (or milestones) are made up of several yet-to-be-defined activities, 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 achievements. They don’t like the restrictions associated with committing 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).
Figure 7-3: The basis of activity durations in an agile versus classic environment.
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 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 commitments from individual team members is a great way to pull the whole team together and ensure that they are all rowing in the same direction.
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 effective 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 approach 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.
Agile Strategy Use network diagrams rather than Gantt charts to show the multiple pathways and corresponding decision points in the agile project.
Network Diagrams
Network diagrams (see Figure 7-4) work well for agile projects because they can convey the overall project landscape without much detail, which is what we need at the outset of an agile project. Focusing on the details is effective for a relatively predictable project, but is often a waste of time when operating in an environment of constant change. If a project reaches a decision point and goes one way instead of another, then the effort to define and estimate details along the unused pathway is wasted. Because we know that much of our plan (prepared as a network diagram) will not be used, details in the agile project are worked out only as the certainty of taking a specific pathway is solidified, thereby minimizing wasted planning effort.
Figure 7-4: Network diagrams provide a high-level view of a project, especially when there are multiple pathways and decision points, without going into great detail.
Combining Network Diagrams and Gantt Charts
In the classic project, the up-front planning effort focuses on identifying project details along the primary path, and so the project manager’s main duty after completion of the plan is managing the project execution. That’s not necessarily the case in an agile environment. The agile project still needs to do detailed planning to be successful; it’s just not all done in the initial planning effort. Up-front agile planning revolves around identifying pathways and decision points, but the details evolve as the project progresses and uncertainty diminishes. While the network diagram lays out the high-level plan, the Gantt chart can be put into play to document the details of a specific pathway (see Figure 7-5).
Figure 7-5: Gantt chart overlaid on a network diagram.
In the agile project, the advance planning effort can be reduced to a high-level end-to-end plan (network diagram), plus a detailed plan (Gantt chart) looking out to the foreseeable horizon. The detailed part should consider two dimensions. The first is related to the uncertainty at hand. For example, only provide detailed plans leading up to a critical decision point so the team doesn’t waste energy planning to go down one road only to later find out that it’s a dead end. The second dimension is related to time. For example, you may decide to always have a detailed plan looking three months out no matter what, so that other team members, support organizations, and management can make their plans accordingly.
Agile Strategy Create your project plan in two parts: a high-level, end-to-end network diagram, plus a commitment-based Gantt chart leading to foreseeable milestones.
This leads us to a critical concept regarding planning for agile projects. You need to make planning a normal part of managing the project. Plans must be constantly updated based on the latest information that becomes available throughout the project’s duration. Another way to think of planning for agile project management is that it is a constant but low-effort activity, rather than the traditional high-effort up-front activity (see Figure 7-6).
Figure 7-6: The approach to planning in an agile versus classic environment.
As further illustrated in Figure 7-7, the overall effort allocated to project planning (the area under the curve) may be very similar to the classic methods that you are probably more familiar with. It’s just that your efforts are allocated differently over the course of the project.