How to Manage Agile Software Projects

Published on: 2014-09-01

In my third post in my series about Leadership vs. Management relating to IT, I will talk about how to manage Agile software projects. Before I do that, though, I feel that I need to clarify the difference between true Agile and the pseudo-Agile used by most service organizations that I'll call "Iterative Waterfall".

As I discussed in my post about Agile a few months ago, the goals of any project leader who is truly taking an Agile mindset to their projects are to reduce wasted effort and to see value from the project as soon as possible. However, most service organizations' customers are focused primarily on two questions before the project gets started:

How much will this cost me?
How long will this take?

As we'll see in a moment, the methods that people have created to eliminate wasted effort and minimize the time before realizing value make it extremely difficult to answer these two questions. The result is that companies make a compromise by setting the scope of the project first, then creating a timeline for the effort, and then releasing the software in small batches on a regular basis. Iterative? Yes. Agile? No. Again, the point of a true Agile project is to reduce wasted effort, which means being able to easily adapt to changing priorities anytime during a project. People still call that type of effort "Agile", though, so I feel like I need to address it here.

Managing a Pseudo-Agile Project

Managing the actual effort during the progress of an Iterative Waterfall project isn't much different than managing the progress during a pure Waterfall project. Here's a rough overview:

Define your scope.
Organize your desired features into logical (and roughly equally-sized) groups, preferably groups that when completed represent usable software. This is like pure Waterfall in that you have milestones built in, but unlike pure Waterfall the milestones are equally spaced in the project plan.
Decide in which order your groups of features must be developed, and organize your project plan.
As the project continues, track effort and make adjustments to your timelines/scope/daily effort as necessary.
When a change in scope is needed, have contentious discussions about whose fault it was that the needed feature was missed during the requirements gathering process.

Managing a True Agile Project

Since Agile is meant to be, well, agile, managing these types of projects is significantly easier. Essentially, you need someone to manage scope for each sprint, but otherwise Agile teams are usually managed by a technical lead. How does this work?

The business leader determines what features are needed in the near term.
The software team estimates the amount of effort needed to implement each feature.
The business leader and software technical lead negotiate what features will go into the next release.
The delivery team meets each day to inform the group of their progress. Slower members of the team are helped and trained, and perpetually slow members of the team are removed.
Repeat steps 1-4 as needed until the features requested are not worth the effort of putting in.

Yes, removing most of the management for a project makes most middle managers uncomfortable. But the purpose of management is to ensure that teams and individuals have what they need to succeed, and this process does that wonderfully. The need for managers is greatly reduced, freeing up the business leader to focus on the value that the project brings without the overhead of the now unnecessary managers. This should free up managers to focus on adding more value to the organization or finding other portions of the organization to simplify and improve.

How to Manage Agile Software Projects

Managing a Pseudo-Agile Project

Managing a True Agile Project

Other posts in this series