The Critical Path on Agile Projects

On a traditional, sequential process an important part of the project manager's job is identifying the project's critical path. The critical path is the sequence of activities that will take the longest to complete and that, therefore, determines the overall length of the project. For example, suppose that my wife and I want to see a movie this afternoon. Before we can go to the movie she has three errands to run that combined will take her 90 minutes. I only have two errands but mine will take 120 minutes. In considering start times for our film, we better plan on one starting at least 120 minutes from now because my tasks will take that long. My sequence of errands are the critical path for our project of getting to the theater in time for the film. A common agile project management question is "where is the critical path" on agile projects? Because agile projects are split into a sequence of iterations this question must be answered two ways:

What is the critical path within an iteration?
What is the critical path within a project?

When I first started doing Scrum projects I worried quite a bit about the critical path. I had learned that this was part of my job as a manager. When I would look with my team at a set of tasks we had committed to for an iteration I had a tremendous fear that only I--the all-knowing project manager--would see the critical path. That without me to point it out to the team we would have one day left in each iteration, have perhaps 42 working hours available spread across our 7-person team, have only 38 hours of work remaining. But those 38 hours would all need to be done sequentially. I foolishly lived with the irrational fear that the team wouldn't see this.

As I look back, I'll admit to not getting over this fear as quickly as I think I should have. It probably took me two years of always worrying that this would be the time that the critical path would sneak up on the team and they wouldn't see it. But after those two years I eventually came to the not-very-insightful but extremely eye-opening realization that the team would always be smarter than me. During those two years (and in the ensuing nine) I have yet to work on an iteration where we neared the end and realized that we mathematically had the capacity to do the remaining work yet couldn't because of sequential dependencies inherent in the remaining work. My conclusion from this is that the critical path within an iteration:

is easy to see because the iterations are so short (typically two to four weeks)
does need to be considered by the team but this can be very informal and usually without even using words like "critical path." It happens naturally during a team's iteration planning meetings and daily standups when they ask themselves questions about how they're going to finish the planned work

Because of these points, my view is not to worry about the critical path within an iteration. Team members will naturally figure it out in the iterations where it's important. As for the critical path of an entire project, this is sometimes worth considering. In my Agile Estimating and Planning book, I wrote about rolling lookahead planning, which is one way for a team to deal with elements of critical path planning. Rolling lookahead planning involves teams (on projects with multiple teams) conclude their iteration planning meetings by taking a five minute look ahead at the next 1-3 iterations. This high-level forecast of which features will be added next can help identify dependencies between teams. This is often enough to avoid being surprised by a long critical path.

On a very complex project I wouldn't be opposed to even drawing a network diagram to see the relationships among the next 3-6 months worth of features (ideally written as user stories). However, before I spent time doing that I would really try first to write mostly independent product backlog items. If a project's product backlog items are independent and can be developed in any sequence then critical path issues disappear.