Feeds

Grappling with eels - second wriggle

Planning: (mostly) harmless

Build a business case: developing custom apps

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.

head shot of Matt Stephens smilingThere'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. ®

Gartner critical capabilities for enterprise endpoint backup

More from The Register

next story
'Stop dissing Google or quit': OK, I quit, says Code Club co-founder
And now a message from our sponsors: 'STFU or else'
Why has the web gone to hell? Market chaos and HUMAN NATURE
Tim Berners-Lee isn't happy, but we should be
Microsoft boots 1,500 dodgy apps from the Windows Store
DEVELOPERS! DEVELOPERS! DEVELOPERS! Naughty, misleading developers!
Mozilla's 'Tiles' ads debut in new Firefox nightlies
You can try turning them off and on again
Apple promises to lift Curse of the Drained iPhone 5 Battery
Have you tried turning it off and...? Never mind, here's a replacement
Uber, Lyft and cutting corners: The true face of the Sharing Economy
Casual labour and tired ideas = not really web-tastic
Linux turns 23 and Linus Torvalds celebrates as only he can
No, not with swearing, but by controlling the release cycle
prev story

Whitepapers

Top 10 endpoint backup mistakes
Avoid the ten endpoint backup mistakes to ensure that your critical corporate data is protected and end user productivity is improved.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Backing up distributed data
Eliminating the redundant use of bandwidth and storage capacity and application consolidation in the modern data center.
The essential guide to IT transformation
ServiceNow discusses three IT transformations that can help CIOs automate IT services to transform IT and the enterprise
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.