Search:

ProjectConnections Print View


AGILE PROJECT LEADERSHIP

What Does an Agile Project Plan Look Like?

by Kent McDonald


I was talking recently with some project managers who were trying to understand what Agile is really all about, when someone asked me how agile project management is different than traditional PM techniques. I pondered that question for a little bit, There are several differences, but I wanted to find an answer that neatly described those differences in a meaningful way. I finally decided one of the best ways to describe the differences would be to walk through a description of an agile project plan.

An agile project plan is feature based.
Most project managers are used to a project plan that has a series of tasks laid out for the entire project, listing task durations, responsibility assignments, and dependencies. Plans are developed in this manner based on the assumption that the Project Manager, hopefully along with the team, can predict up front everything that will need to happen in the project, how long it will take, and who will be able to do it.

Agile project plans, on the other hand, are based on features. The plan projects when features will be delivered to production, without much detail surrounding how those features will be delivered, although the most current iteration tends to have a bit more information. Agile plans are based on the assumption that we don't really know what conditions will be six months from now, but we can put together a reasonably good guess about what will be delivered when, based on the priority of the features and how much functionality the team can deliver within a given timeframe.

An Agile Project Plan is organized into iterations.
Because traditional project plans tend to be task based, it often seems appropriate to group like tasks together into phases, and to have all similar work done for all pieces of functionality before moving on to the next type of work. For example, a software development project usually happens something like this:

  • Gather all of the requirements.
  • Perform analysis work on all of the required functionality
  • Perform design work on all of the required functionality
  • Develop code for all of the required functionality
  • Test all of the required functionality
  • Deploy all of the required functionality.

The end result is that the actual end products usually do not take shape until well into the project, so substitute measures of progress have to be established to provide the stakeholders an idea of how the project is progressing. This is usually accomplished by providing a count of how many tasks are completed and a percent complete estimate on those that are not done yet.

Agile project plans are organized into time bound iterations, usually anywhere from 2 - 4 weeks in length. During those iterations, all of the necessary work to take features from an idea to a working product is completed without artificial dependencies that prevent work from being done in parallel. The end result is that portions of the product are delivered on a regular, frequent basis. This gives stakeholders a much better idea of the state of the project, because they can see and use the end result as it becomes available.

An Agile Project Plan has different levels of detail depending on the time frame.
Traditional project plans are often developed up front based on the best information available at the time. In order to reduce the risk of the unknown, the team lays out the entire project and assigns all of the work so nothing is forgotten. This results in a highly detailed plan, often scheduled down to the hour, stretching sometimes six months to a year out into the future. But people are notoriously bad at foreseeing the future, even when conditions do not change at all. Given today's chaotic business world, this approach often leaves plans outdated shortly after they are finished.

It is completely reasonable to expect a team to be able to identify what they will be doing at a relatively detailed level for the next 2 to 4 weeks. Outside of that time frame, things become less clear because of changing business conditions, learning from the previous work, changes in the team, etc. Agile project plans address this with multiple levels of detail based on timeframe. At the high level is a release plan which highlights what functionality the team is planning to deliver for the next several iterations. Often this is based on the prioritized functionality and the amount of functionality that a team can produce in an iteration (frequently referred to as "velocity"). For the most current iteration, the team produces a detailed plan that includes the tasks needed to deliver the planned functionality. This multi-level planning allows the team to adjust their approach to account for changes in priorities, changes in the team, better approaches, and techniques learned during previous iterations, because they wait until right before they are going to do the work to determine how they will do it.

An Agile Project Plan is owned by the Team.
This is potentially the most controversial statement in the bunch. Project managers are used to owning the project plan in that they create it (hopefully with input from the team, but not always), update it, and communicate it to the rest of the organization. Some project managers look at the project plan as one of their major deliverables of the project.

The team owns the agile project plan; they work with the customer to decide what functionality will be produced in an iteration, and decide what tasks are necessary to successfully deliver the planned functionality in the upcoming iteration. Once the plan is developed—in reality an ongoing effort—the team is also responsible for maintaining it: they self-select the tasks that they will complete and update the status accordingly. As the people who are doing the work, they are best positioned to know what needs to be done.

My companions considered all of this for a few minutes. I wasn't sure if the silence was because they were in complete and utter disagreement and were trying to figure out which point to argue first, or if they were letting it all sink in. Thankfully, it was the latter. These differences could very well give experienced project managers a reason to stop and think. Many of these ideas run counter to what they have been taught and have practiced for several years. Yet many of these PMs agreed that, when taken together, these ideas make sense as a good way to organize a project focused on delivering value to the stakeholders, which at the end of the day is what being agile is really all about.

Many thanks to Greg Goodman for helping me to crystallize my thoughts on this particular topic.






©Copyright 2000-2014 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy