How to manage agile

What can be learnt from the programming geeks who adopted the Agile Manifesto and rewrote the rule book on IT project management?

The move to being “agile” has up to now been a grassroots movement. It makes perfect sense at the level of small, co-located teams: stand-up meetings, face-to-face design workshops, fortnightly cycles of development and showcasing to a responsible product owner.

But how can top management adopt these lessons for larger innovation projects and for making decisions in board meetings?

I am leading the development of a new, slim guide to Agile Governance to be published by the Association for Project Management (APM) in the New Year. I believe there are general behaviours in the agile methods, such as scrum and dynamic systems development method (DSDM). Rather than focus on what IT people get up to in organising their detailed agile development projects, we need to identify the agile behaviours that result in these successes.

Seven behaviours
Boiling down the jargon, we find just seven, easily understandable agile governance behaviours:

1. “Show me” – the slogan of the US State of Missouri. Reflecting simple farmer’s logic, this agile behaviour says: “Don’t try to flummox me with documents, plans and promises; show me it working – and soon.” Agile management insists on seeing a new product early before committing. A working prototype being piloted in real use is worth more than hundreds of blueprints and designs.
    
2. Be incremental – make sure the focus is on incrementally implementing and gradually improving product and services. Incremental delivery of change means fast feedback on what works and what doesn’t. It is the same principle as riding a bicycle: a constant checking and balancing is needed otherwise you will fall over. Similarly, on innovation projects you cannot travel in a straight line for long periods without going off track.
    
3. Expect early business benefits – given the choice of bread today or the promise of jam tomorrow, an agile manager will generally prefer the benefits of a practical, but somewhat boring, solution now, rather than risk a throw of the dice on a long-shot that may fail. US government statistics show the majority of projects that run longer than a year with no intermediate deliveries never deliver, no matter how detailed and convincing their business cases are.
    
4. Go for smooth flow of work – once you have your team on track, delivering early, getting real benefits and incrementally improving the emerging final solution, concentrate on getting a regular heartbeat of work going: regular “sprints” of development, with periodic business reviews of their output. The nearer you can get the workload to be consistent and regular, the less likely you are to be surprised by a big problem. You are almost certainly going to have a series of smaller problems which will be easier to deal with. Avoid a waterfall of “gate reviews” as these often cause a stop-start of flow when staff members change from a design team, to a build team to a test team. Regular delivery of well-implemented change from an integrated, multi-disciplinary team, with continuity of staff, is the best indication that flow is smooth.
    
5. Never slip a deadline – J.P. Morgan famously said: “I want it Thursday, not perfect!” When things get difficult, and they always do, a wise agile manager will cut the expectations of scope and get the team to focus on the really important aspects of the innovation for immediate delivery. What functions are the most critical? Where are the biggest business returns? What can comfortably be left until the next iteration? Avoid a death march which assumes that the battle can only be won if the product is perfect – it never will be.
    
6. Reduce work in progress – this one will appeal to your chief financial officer: treat any capitalisation of unused software assets from quarter to quarter and especially over yearends as potentially lethal. Putting software on the balance sheet that is partially developed and untested is risky practice. There are only two possibilities: it may get used in the end or it may be written off. Experience shows that the latter is often the case. The simple behaviour of pushing back on project business cases that show long implementation timescales, with partially developed software languishing without use, is an effective agile behaviour that the accountants will appreciate.
    
7. Talk to people – get out and about. Find out what the developers are thinking. They know the risks better than their managers; there should be no deference to authority or rank. Dangerous group-think can occur when risk reporting becomes a hierarchical exercise driven by spreadsheets, rather than informed discussion.

Jeff Bezos of Amazon has drawn parallels between the recent internet explosion and the sudden start of modern life on Earth in the Cambrian period, when the fossil record really kicked off. The year 2000 is almost like a year zero in terms of management of innovation projects.

Expert agile practitioners at the coal face are now a good ten to twenty years ahead of current top management practice, which currently still reflects the MBA thinking of the late-1980s: business plans full of spurious detail, over-ambitious plans with little real-world testing of new ideas and commitment of large budgets on the promise of jam tomorrow that doesn’t materialise.

The governance of innovation projects needs a shakeup to bring itself into the 21st century. The slim Agile Governance guide that the APM will publish next year will provide leadership on this issue. Organisations exhibiting these agile behaviours will prevail over those that stifle innovation by demanding their technologists produce unrealistically detailed estimates based purely on guesswork, rather than on practical, agile feedback from the coal face.