How to Agile
Project managers trying to understand what Agile is really all about often ask how Agile project management is different from traditional project management techniques. One of the best ways to describe the differences would be to walk through 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.
Note: In an Agile project, the traditional project manager role is no longer present; Agile projects recognize a ‘Product Owner’ role instead.