Top management are eager to understand the successes they see in agile innovation of the post-internet boom, says Brian Wernham, deputy chairman of the Governance Specific Interest Group of the Association for 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.
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.
Expert agile practitioners are now a good ten to twenty years ahead of current top management practice
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 year-ends 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.