"Hey, Dan, it's time for us to move to agile," explained Tristan, a project manager.

"Tristan, you've been singing that tune for a while," replied Dan, a member of the PMO.

"Well, now I have data that I think you can use with the rest of the PMO and with our senior managers. Look at these cumulative flow diagrams."

"Cumulative what diagrams?"

"Cumulative flow. Look, they show us how much work is in progress and how much is done at any given time in a project. If you know you have a lot of work in progress, you know the project can't finish soon. If you know there's not a lot of work in progress, you can decide when to end a project. Here, take a look at these cumulative flow diagrams for my project."

One of the powerful motivators for teams, programs, and managers to consider agile approaches to projects is to see the amount of work in progress.

Figure 1 shows Tristan's cumulative flow diagram early in the project, when he was using a serial lifecycle.

Figure 1: Serial project early in the project

Tristan's project used a serial lifecycle until July. Because the project team was looking at all the features to try to freeze the requirements and architecture, Tristan decided the team was working on all the features. He thought that the team had finished maybe five of the features, so they got credit for those completed features. But they added an additional fifty features, so it sure didn't look like they were making progress.

When he saw the diagram for July, he couldn't see how they would finish this project in a year. That's when they moved to an incremental lifecycle, so that the team could finish chunks of work.

Now, take a look at figure 2, Tristan's cumulative flow diagram when they moved to an incremental lifecycle for the months of July, August, and September.

Figure 2: When Tristan moved to an incremental lifecycle in July

The project still has a ton of in-process work, but some of the features are complete. In an incremental lifecycle, you finish a feature as if you were going to release it. The entire feature is designed, coded, integrated, and tested. The code is checked into the code base and is ready for other people to use it.

Because Tristan's increments weren't timeboxed, some of the features still took longer to complete. When Tristan moved to timeboxes and finished increments of work inside timeboxes, his cumulative flow diagram looked like figure 3.

Figure 3: Seeing how timeboxes even out progress

Once Tristan added timeboxes to help the team finish the features they could commit to in an iteration, the team had a regular delivery of features into the code base. Surprisingly enough, they finished the project on time, although they had plenty of trouble with defects from their early work.

As Tristan explained to Dan, "There's still a hockey stick for finishing the features, but look at the progress we made starting in September. The timeboxes helped us focus on just the features we wanted to commit to in this iteration, not all the features that were started. Once we got to November, it looks as if we had hope—we finished as many features as we started. It took us an extra month to finish this project, but if you draw the green line from May straight across, I think that would have resulted in our features finishing with a much sharper hockey stick at the end, and much later."

Dan asked, "What do you mean?"

Tristan sketched his trend from the original graph, as in figure 4. "Here's my projected end. I've taken the serial lifecycle graph we had originally and extrapolated out. What do you think?"

Figure 4: Tristan's projected trend of project complete

Dan looked and said, "Well, I'' like to think you were being pessimistic, but this is what happens. We finish a little and then finish a lot at the end, and then the testers are overwhelmed, as is the doc group and the rollout group. I have to admit, I much prefer the graph we had where the timeboxes helped us even out the progress." (See figure 3.)

Tristan grinned and added, "Yeah, and if we use timeboxes the whole way through, we can make progress all the time. I bet we could have shortened the project."

Dan frowned, "Well, I'm not sure of that. But I do like seeing the real progress of how many features are done on the project." I'll take this data to the rest of my PMO and see if we can't try a few more agile projects from the beginning."

Data Helps Explain What's Happening in Your Project
If you are considering a transition to agile, or if you're wondering why things are taking so long, consider cumulative flow diagrams. They help you and the entire team see what's going on and what's getting finished in the project—or not. And, if you're considering a transition to agile, the data is a great selling point.

Acknowledgements
I thank Esther Derby, George Dinwiddie, and Don Gray for their comments.