Grappling with eels - second wriggle

Rottweilers like Harry are rife in IT. They're resistant to change, and you'll often hear them thundering pithy retorts like "Don't give me problems, give me solutions!" It's easy to put this attitude down to their rigid, no-nonsense nature, or even to regard them as ignorant dinosaurs from a bygone era.

But in reality, they are the product of an unforgiving business world in which deadlines matter and ROI is everything; and the attempts of a lone team leader to change the way his organisation thinks about project planning doesn't amount to a hill of beans.

Plan driven projects are so-called because they are led (up the garden path?) by the project plan - the term "plan driven" was coined by Barry Boehm to contrast with the term "agile". The plan "owns" the project and affects the behaviour of everyone involved. It's pored over incessantly by stressed PMs (project managers) who worry about how to rearrange the staff to get the facts to fit the plan; and it's rolled up and used as a baseball bat during management meetings, when Harry the Rottweiler uses the baseline as evidence that the project is slipping.

Agile projects, by contrast, are "planning driven", because their primary focus is on adjusting the plan as they go along based on the latest feedback.

(Side note: This "plan driven vs planning-driven" dichotomy is an example of the sort of wordplay that often goes on in the agile world. It's not exactly to my taste, but a lot of agilists appear to thrive on it. Another example is "model": the code is a model just like a diagram; therefore, your design model can equally well be the source code. Aaargh!)

A software project may very well be suited to a dynamic, adaptive approach to planning. But friction occurs because the project doesn't operate in a vacuum - it's fulfilling a specific need for a paying customer. For the PM and her team, the project is the universe, where the dynamics of software development are to be bowed down to; but for the customer it's simply a single piece in a bigger jigsaw puzzle. The customer doesn't care that it's difficult to predict when the software will be done, he just wants a date so that he can plan when his ROI will begin.

The business world operates on plans and deadlines. Although agile planning is an important risk-reducing development, the IT world risks alienating itself from the business world if it insists on eschewing the concept of predictive planning.

That said, agile projects could still fit into the plan driven business world if they keep to the concept of planning in broad brushstrokes, and only planning in detail for the current iteration. This may be good enough for many customers; others will demand more detail and commitment, if only because their business in turn demands it.

But the valid point that agile practitioners make is that even when a manager insists on a detailed plan being produced and adhered to at the start of the project, the plan doesn't come with any guarantees. So, know your audience. If Harry the Rottweiler insists on a rigid and almost certainly wrong plan, let him have it. But within the project, track your project velocity and keep planning adaptively, maintaining a plan that will become increasingly accurate the further into the project you get. Harry can have this copy as well if he wants, but it's up to him.

Often the value of a plan is the exploration that it encourages (for example, conducting a quick throwaway prototype to work out how long a feature will take), but the plan itself may quickly become obsolete. As Mary Poppendieck (of Poppendieck LLC) has said: "Do the planning, but throw out the plans."

Some more advice comes from Sanjiv Augustine, in his book Managing Agile Projects - in transitioning from the familiar, use release plans instead of Gantt charts.

There's a multitude of books on agile planning, offering a mixture of advice. I'll provide a round-up of the advice offered in some of these books in part three of this series. ®