We’ve all seen this. A one-year project in its 13th month, and the Project Manager has been reporting 80% of the tasks at 90% and has been doing so for the last 120 days. There’s no end in sight, and the customer is leaking cash every day the product fails to go into production. What can be done? Agile project management principles can help this all-too-frequent scenario.
First, let’s look at how this situation comes about. In a typical task-oriented project plan, one is required to decompose the tasks down to a fairly reasonable degree of specificity. The tasks are organized around a dependency graph, estimated, resources are assigned, and the schedule is calculated and/or nudged. (Well, usually the initial estimates don’t match the customer’s expectation and deadlines, so there’s a revision step here where estimates are shortened) But how does change get reflected? If a PM is doing an excellent (if frustrating) job, he is constantly updating the schedule, the plan, and re-conceiving the tasks as new information comes to him.
More often than not, however, this gets so messy and unwieldly that the PM holds fast, and starts to estimate completion based not on a proper decomposition and a completion of each of these tasks, but based on his guess, or his workers’ guesses. Complexity of the tasks is hidden, and becomes often quite invisible. Tasks at 80% which suddenly need to be re-decomposed and re-conceived do not, in the main, get moved back down to 40% after certain roadblocks are discovered.
The result? The customer is increasingly afraid, trust between delivery staff and client (and management) are eroded, pressure is increased, mistakes under pressure become more frequent, less sleep is had by all, and 90% complete becomes an asymtote, rather than a milestone.
Now what is to be done with such a project? How can Agile project management approaches help this situation? We can examine this by playing out such a scenario…
We can start by identifying a few key practices of Agile project management, and examine their benefits to the business client.
Timeboxing and Iteration
The first thing we can talk about to the fearful client is timeboxing. Timeboxing caps his investment into small chunks. We look at it and say, OK, you’re in deep trouble, but you don’t know how deep your trouble is. By timeboxing into a very short timeframe, and making a large project into many little short projects, we can get more visibility into the process – we can see things as they are, rather than how they’re reported on a project plan. Speaking of visibility…
Daily Meetings and Iteration Review
Part of the value of iteration and timeboxing is increased visibility, so we really need to have a mechanism for visibility. Already distrustful of project plans, we can tell the client, “Don’t believe the paperwork, let’s look at what’s actually built. At the end of each iteration, we’ll review the current situation, and demonstrate existing functionality.” His eyes perk up. “Wah?” he asks incredulously? What do you mean? So we say, “we don’t want you to guess at how ready this thing is. We’ll show you. That way, you can decide if it’s ready enough. …Or, your product marketing people can make that call if you prefer. It’s up to you, but you get to see it, touch it, and sense for yourself how ready it is, and you won’t have development managers and developers waving their hands pretending it’s further than it is.”
“Oh wierd,” says he. “So what are these daily meetings?”
We tell him that the daily meetings have several purposes. Only project members get to speak, and they report on what they did yesterday, what they plan to do today, and what, if anything, is blocking their path. No one else gets to speak, but others who are not on the team itself can listen in. This way, the whole project team is clearly aware of how they’re working, what’s left to do, and what each other are doing.
“Why do they need this? They have the plan.” “True,” we reply, “but how often do you have two people who need something, and both do it because they don’t know that someone else already did it. With your current project delays, do you want any duplication of effort? Just by way of example?”
Feature Lists, not Task Lists
We also talk to him about working from feature lists, not task lists. The team will be implementing features, and fulfilling requirements. How they do it is up to them. “Why should I care,” he’ll ask. “You shouldn’t,” we reply, except to assure him that if people are working against features, then they can choose to re-order their tasks in such a way as to most quickly get to the goal. No wasted effort, we tell him. Sounds good to him.
What’s more, we assure him, we will be first working on the highest-priority features. What “needs” to get to market. Everything else slides down the list. Even if the wonderful plan we all love had them at the top earlier. High-value features (as prioritized by the client) and their necessary dependencies get done. That’s it.
“So no features that I didn’t ask for?” He looks hopeful.
“That’s right,” we reassure him, “and you can change your mind.”
Smelling salts are brought.
“What do you mean, ‘I can change my mind?'” he asks.
“If, when we get to the iteration review, and you test drive the thing, Acme corporation has come up with the killer feature that you absolutely must have or the whole thing is useless, you put it to the top priority spot on the list that we will use to drive the next iteration.”
“And no one will complain that it’s out of scope?” he marvels.
“If you put it at the top of the list, it is the scope for the next iteration. We are at your service,” we comfort him.
“So when will this be finished?” he asks us desperately.
“When you say it’s ready,” we reply. He boggles. What does that mean? he thinks.
“What does that mean?” he asks.
“It means that we will tie it off when you think it has enough juice to go to market. If, after you re-prioritize what’s left, you find that it’s ‘ready enough’, then we’ll roll with it, take a couple of weeks to steady it and ship it, and then we can pick up your next-highest priority things, or anything new you want in it.” He looks near fainting again. “And we stop when you feel that spending money on it is no longer bringing you enough value – ideally because by that point we’ve done all the high-value stuff already, and we’re now working on less valuable stuff.”
“So I have discretion to pull the plug whenever I want to?”
“Please help me…”
This little scenario is fictitious. But in the end, it’s consistent with the experiences of many Agile practitioners (particularly Scrum) that I speak with. It only covers a small sampling of Agile practices that may help a project in crisis. Others may help quality, may improve developer productivity – but the above can help a key client or stakeholder begin to see a light at the end of the tunnel. While many people cannot get their heads around it, they may be willing to try new things simply out of desperation at the point where the existing process is causing them enough pain.
And it can turn a project failure into an ever-increasing success, because success is defined monthly, re-defined at the desires of the business client, and executed in bite-sized chunks that are digestible and estimable.
Just don’t forget that people have the strangest reactions to things that break their expectations… so make sure to bring the smelling salts…