Agile Project Management Experiences

I first started hearing about agile software development about 5 years ago. The company was working on a project designed to develop a web based incident reporting system. The lead technical team, new to the organization, was experienced in agile delivery wanted to use agile for the project. The project management staff was trained in traditional or classic project management and the organization was used to the language, tools and techniques associated with traditional project management. Agile software development wasn't a movement in the company, hadn't been introduced as the next great thing, the project wasn't even tagged as an agile project. After some debate at the senior management level it was determined that agile delivery was the best method for this project.

The project used paired programming, test driven development, iterations, regular builds and many other benchmarks that "make" a project agile. A project manager who had no agile delivery experience was assigned to the effort. This is where some issues began to be noticed within the organization. The project manager used the predictive, plan based management method they were familiar with rather than adapting to agile concepts. The project was going well based on the clients perspective. The client was able to dictate the next two weeks worth of project work, was heavily involved in the development of the software, and the software changed on a bi-weekly basis in their favor. Everything that was being requested by the client was part of the scope of the project. There were problems though, and the project manager was under the gun to answer the concerns.

When the question of "when will it be done" came up, the project manager wasn't armed with the language of agile or the metrics and wasn't able to present information to the stakeholders in a meaningful way. The stakeholders that were struggling with this new form of delivery were not the customers of the software. The stakeholders that were concerned were those that needed the resources next. The software had to be "done" at a point in time so that other software development could commence.

It seems to me that the example above could be any company. Company's are looking for THE way to get to market quickly, THE way to get software completed with less cost and THE way to maintain a competitive advantage. This isn't new, company's have been looking for that since the first company started. What is different today is that there is more than one acceptable way to manage a project. That is a good thing. There are a few things that must be in place to allow projects to work using different methods. First, the methods have to be defined and agreed upon. Notice, I didn't say create mountains of documentation. They must be defined so that team members know what is going on. Second, there has to be a reason to use one method instead of the other. Third, metrics need to be in place to support both the metrics and the communication of the status of the effort. Lastly, there should be one portfolio of projects that all projects report information to so that the organization understands how the money is being spent. As a project manager it is important that the portfolio view exists, otherwise I don't know when I'm going to get what I need to be successful.

Ride On, Manage On.