Agile Portfolio Project Management

Figure 3-1. Work-breakdown structure (WBS)

The lowest level in the WBS hierarchy is also called a work-package, which is the level at which estimation is performed and assignments are done. The levels higher in the hierarchy are always combinations of the lower elements. So the bigger the project scope, the more branches there are in the WBS. The challenge with work-breakdown structures traces back to the problem of producing at an early stage a so-called master plan of work. Any work that is not listed in the WBS won’t be estimated. As a result, any work performed that is not in the WBS will produce cost overruns. We could argue that the WBS could be constantly updated to reflect the changes caused by scope changes, but that is hardly done in practice. The structure is difficult to adjust.

Another issue with estimating work up front is that the development team has not had the chance to work together and verify the estimates. If one estimate is significantly off, there is a chance that the other estimates are also out of line. Corrections of estimates while the project is under way are difficult to incorporate.

From a psychological perspective, the WBS is owned and managed by the project manager. Work is assigned to team members, and completion is controlled. This top-down, command-and-control management style does not work with agile teams, and it violates the principle of using a team-managed and team-organized approach.

I’ve met project managers who have told me that they will need the WBS for their own benefit, even though they won’t tell the agile team about it. These managers were so accustomed to this work product that they continued using it. It is hard to be against something that gives the project manager confidence, but if the team is not using it, why bother? Are the costs of creating and maintaining a WBS for a project manager justified? Shouldn’t the agile project manager work on something else and make better use of her time? Shouldn’t she work on something more important and relevant for the project team—for example, removing organizational impediments or facilitating a planning session?

Instead of seeing the project from the perspective of “work to be performed,” the agile team takes a different view. They look at the features and functionality of the system and document them as stories on index cards. Because the tasks in every iteration are the same, the focus of work is the story card. The activities for the iterations run parallel to one another; there is no requirements iteration or testing iteration in agile development. The activities are merged together and are continuously performed in parallel. The cards are estimated and prioritized, and the ones found relevant for the business are assigned to iterations. Remember, the feedback loop established through iterative-incremental development easily allows for this.

Gantt Charts

A Gantt chart illustrates the orchestration of the tasks according to timing and dependencies. In traditional projects, this format is frequently used to depict the project schedule. (See Figure 3-2.)

Figure 3-2. A Gantt chart

Very much like the WBS, the Gantt chart lays out the project schedule up front. The problem is the lack of predictability and accuracy of the schedule, especially for tasks late in the project. The planning window with the highest accuracy is the short time frame ahead of the day of planning. That is why iterations are so intuitive for many managers. Imagine a project manager in the beginning of a new long-term project. Ask him what the scope of work will be in iteration 20? It seems almost ridiculous to expect the manager to know, right? It is human nature that we think about the first iteration, the second iteration, and maybe a rough sketch of iteration 3. Iteration 3 will be refined once we start with iteration 2, and so forth.

Agile teams, however, know the project goals and have a rough estimate of how to get there. They know where the features and requirements stand at any given moment and the amount of progress expected to be achieved in an iteration.

Try the following experiment the next time you meet with a traditional project team. Ask for the project schedule, which is most likely shown as a Gantt chart. Then compare the actual day (the present day) with the plan. Ask a team member, “Based on this plan, you are currently working on task XY, correct?”

Based on my experience, the answer is most commonly an excuse for why the team is not working on that task, such as the schedule being outdated. The team’s good spirit and best instincts are directed most of the time to working dynamically with the project manager instead of following a plan. Developers follow their instinct and trust their common sense. Without those, the project schedule would collapse anyway, because there are so many tasks unaccounted for in the original schedule that just seem to pop up. I have also never seen a project team start work in the morning by looking at the latest edition of the schedule. “Based on the schedule, I should be working on XY.” Call it unprofessional or undisciplined; it just hasn’t happened in my world.

In all fairness, maintaining the schedule is a full-time job on its own because projects are naturally very dynamic. Occasionally, especially when executives like to get an overview of the progress of the project, it is a team effort to get the Gantt chart up to date. I call this pastcasting (instead of forecasting) because the schedule’s past is put back in order. For various reasons, the plan’s history might be put back in order, but it provides no value to the project itself.

In agile projects, which embrace change and a dynamic way of building systems, planning with Gantt charts encounters limitations and is too expensive to maintain. Most important, such planning does not reflect what is really going on in the agile team. An agile team can tell you, however, what its plan for the next iteration is and, possibly, the plan for the following iteration also.

Critical Path Analyses

Performing a critical path analysis is a technique used to identify the shortest way through the project schedule. Any delay of any task on the critical path will delay the completion date. Figure 3-3 demonstrates that activity E cannot start before C and D are completed.

Figure 3-3. Task dependencies

Knowing and monitoring the critical path allows project managers to control the progress of the project. One form of illustrating the project schedule and its critical path is the activity-on-node diagram. Each node carries the following information:

• Earliest start

• Latest start

• Earliest finish

• Latest finish

• Duration

• Number

• Name of the activity

By subtracting the earliest start from the latest start, the float is determined. If, for example, the earliest start is day 12 in a schedule and the latest start is day 18, we have a float of 6 days. That means this task could be delayed up to 6 days without having to sacrifice the overall schedule. Therefore, this task is not on the critical path. Every task without any float is, however, on the critical path.

Although this technique seems extremely powerful for controlling projects and puts emphasis on the critical tasks in the project, it has its shortcomings when applied in an agile project. A typical sequence for traditional project management is to have the up-front planning followed by the execution. The controlling mechanism of the critical path analysis does not include the adaptive development that takes place in an agile project. As a matter of fact, in agile projects tasks are performed in parallel—for example, writing small units of tests followed by the appropriate messages and methods in objects. A clear separation of tasks is not possible. The detailed level of the tasks would be measured in minutes rather than in hours and days, which are typically the unit of measure captured on an activity-on-node diagram.

In addition, agile projects are not considered to be late as long as the iteration is completed on time. Instead, agile teams measure how much progress has been accomplished within the last iteration. This approach creates a totally different perspective about a project’s schedule.

On agile projects, the critical path is nested inside the iteration, and every iteration is on the critical path. Daily stand-up meetings expose the most critical impediments. Suppose a team planned 50 story points and completed 55. They made more progress than planned. If they again plan 50 points for the following iteration and then complete 58, the team seems to be able to deliver more than planned. Having a rough estimate for the entire project, the average progress can be used to draw conclusions on the final delivery. Having each iteration serve as feedback about progress based on tangible output seems to be more effective than projecting the completion of tasks on paper.

Project Reports

Project reports present the state of the project to stakeholders. They provide information about how the project is doing compared with its original plan. In a perfect world, a project manager can ask her team members about the progress of a task. We know by now that IT projects are often far from a perfect world. So there are basically two problems with this approach. First, the plan is often outdated and cannot be compared with reality, and second, the tasks are too broad to measure as “done” or “not done.”

For example, a broad schedule might include a task of “Write User Guide,” which is estimated to take 100 person-days. It is extremely difficult for a technical writer to give a status report on this task not knowing what is left to complete. A typical answer is 50 percent, 80 percent, or 90 percent done. Also, the last 10 percent might take three times as long as the first 90 percent. So how predictable is this form of status reporting?

Executives who believe in status reports might be disappointed when they realize that a project that was reporting positive figures all of a sudden has to report the breaking news, “We are running late...” Whoever believes that the project status reports are exclusively created by the project manager is misinformed. Usually, status reports are a team effort that takes a lot of energy out of the entire team. But worse, while the team is providing status updates and explaining the work it has performed, team members are not making progress on the project itself.

Again, agile project teams use the increment and the iterative rhythm to report their status. For example, using two-week iterations, a project team can demonstrate its accomplishments in producing executable software. The features and requirements are either done or not done, and every claim or measurement is tangible. Using the earlier example, a team can report that a feature was not only converted to running software during an iteration, but it was also documented in the user-guide documentation. Executable software, a build, automated test cases, and a piece of documentation have been completed. All aspects of a manageable piece of functionality have been completed.

In addition, executives and stakeholders can always sneak into the daily stand-up meetings and observe the mood, progress, and issues of the project firsthand.