How to “Control” an Agile Development Project

So-called “Waterfall” or “Phase-Gate” product development methodologies often give management the illusion that they control the project while meddling and slowing it down. Each formal gate meeting or project review is an opportunity for every manager to put the project team under scrutiny about their accomplishments and whether they should continue with the next phase. I have been on both sides of the PC projector for many of these reviews, so I know what I am talking about. The project slows down when a gate checkpoint meeting or formal review is approaching. The project manager and critical technical contributors view the meeting as an opportunity to show their value or possibly slip up, which may affect their project and their personal ranking and stature. Therefore, they spend a lot of time and emotional energy on perfecting slideware – deciding what to emphasize or obfuscate about the project’s progress. These meetings also drive other suboptimal behavior; for example, to show a “quick win” at a review, the team may take on a quick, low-risk piece of the development instead of concentrating their talents on retiring the higher-risk elements as early as possible. These deferred high-risk elements can cause significant project problems and delays later.

On the other hand, management cannot just hand a blank check to the project team and say, “Go away and come back with a great product whenever you are ready.” There have to be some boundaries to be enforced, right?

The answer is –YES – and “boundaries” provide the right concept for team empowerment within a management control framework. Empowering the team means providing it with clear responsibility for the project, the authority to make critical decisions, and the ability to execute.

Controlling agile

The team can execute the project if they have sufficient resources (with enough capacity), knowledge, talent, and tools for the job. But how can we give them the proper amount of responsibility and authority if they run unchecked? Isn’t that what Gate meetings and Project Reviews are for?

Learn how we help clients achieve faster releases, higher productivity, and customer success with agile consulting.

Boundaries in the early stage of the project are crucial

The simple answer is to negotiate a set of boundaries early in the project within which the team may make all its own decisions and then largely leave the team members alone to run as fast and efficiently as possible. The boundaries can be displayed as a simple polygon, as in the illustration below.

Controlling agile

In this pentagon figure, each flat side represents a constraint for the project, such as “the total cost of the development project must not exceed $__M,” or “The final Bill of Materials for the manufactured product must not exceed $300.” As the project proceeds, someone on the team (usually the Project Manager) indicates how the project is performing within these boundaries in real-time. Green marks indicate that everything looks good for staying within the boundary; amber indicates that the team is having trouble staying inside, and red means that a boundary is likely to be exceeded.

Once the boundaries are negotiated and set up, they are usually reviewed quickly in a weekly, informal check-in meeting with management. Assuming that the team does not mislead or hide some significant problem, this weekly check-in meeting can be concise (15 minutes is typical) and works very well to prevent wasteful, formal Gate review meetings and other window-dressing reviews. If the project is heading for a boundary breach, then it is incumbent upon the project manager to call an “Out-Of-Bounds” meeting with management to escalate the situation and decide what to do. Management should set up a straightforward and rapid escalation process to handle these situations and get the project back on track (see Unclear Escalation Paths can Kill Projects).

In summary, if you want a product development project team to run fast and efficiently, don’t weigh it down with a heavy “Gate Checkpoint” or “Formal Project Review” structure. Instead, give the team some overall boundaries, empowering it with sufficient resources and full and clear responsibility and authority within those limits, and let it fly free!

Further Reading

Discover the best resources for learning about Agile methodology by checking out our curated list of top Agile books written by respected authors.