Why 'Agile Project Management Controls' Isn't an Oxymoron
George Carlin made phrases like 'jumbo shrimp' famous. But the need to control agile projects is no joke. Ask the right questions along the way, though, and you'll bring order to a process than can easily turn chaotic.
Thu, April 11, 2013
CIO — Everybody knows I'm a shameless Agile zealot. Let's face it, though. Read the Agile manifesto with a cynical eye and the message seems an awful lot like, "We're artists, and if you want a great outcome, you can't manage our art projects the old fashioned way."
Cynicism aside, it's true that agile projects can't be managed with conventional waterfall techniques. But that doesn't mean they can't be managed. They need to be budgeted for and controlled, or else they'll never get approved. In other words, they need adult supervision.
Agile Isn't a Marathon, It's Many, Many Sprints
The tricky part is that the adult supervision for agile projects requires more continuous effort and, yes, more subtle attention than the classic waterfall techniques. In a typical waterfall project, the executives approve a budget and a calendar at the outset; after that, it's just the occasional black-and-white review meeting. The project managers can simply "check the boxes" as each requirement in the spec passes its acceptance criteria.
While creating that spec and the acceptance criteria may take a lot of up-front work, once you've kicked off the project waterfall monitoring and controls are pretty easy. Except they're not. All too often, the check box items aren't precise or all that relevant.
In the course of the project, discoveries can invalidate some of the details of the spec—and nobody has time to go back and bring the spec and test criteria up to date. So the twin enemies of every software project--scope creep and vague acceptance criteria--rot away the credibility of the budget, the schedule and the controls of waterfall projects.
In contrast, agile projects require much less up-front work; the specification and controls are developed and enforced every day of the project. Agile projects have no detailed specs—sometimes not even when they're completed.
Instead, the team must be entrusted with prioritizing the tasks by business value, and coming up with the "defining stories" for each release. The team runs its sprint within a defined schedule and budget. Since the sprint is typically short, there's little issue of overruns, and scope creep is counteracted by team decisions that "throw things overboard" to make the sprint deployable.
The only thing you know about a sprint, then, is exactly when will it be over, not exactly what will be delivered. While there are tools to help with the mechanics of cards, stories and units of work, the fundamental control mechanism for agile is the team and its interactions. This feels—and probably is—qualitative. It must drive the numbers guys crazy.