Project Management; Being Agile

Oct. 28, 2013 - PRLog -- Someone asked me how agile project management is different than traditional project management. I thought about it for a while, as there are several differences, but I wanted to give an answer that described those differences in a meaningful way. Finally, I decided one of the best ways to describe the differences would be to walk through a description of an agile project plan.

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.

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:

·      1. Gather all of the requirements.

·      2.  Perform analysis work on all of the required functionality

·      3. Perform design work on all of the required functionality

·      4.  Develop code for all of the required functionality

·      5.  Test all of the required functionality

·      6. 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.

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.

I've come to what I think is potentially the most controversial statement about my observations. Most traditional project managers are used to owning the project plan in that -- they will 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.

With an agile project plan, the team owns it. They work with the customer or client 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.

The differences I've pointed out 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 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.

About Trillium

Trillium Solutions Group, Inc. is a professional services firm headquartered in Chicago that provides technology consulting and strategic sourcing services for industries such as trade associations, financial services, telecommunications, and healthcare. For more information, please visit www.trilliumsg.com.