• Skills & Talent
• Transformation

Written by Nigel Foster, Head of Profession, Project and Programme Delivery, Capita Transformation

Agile is fast becoming the ‘must-have’ methodology requested by many operations directors… something that may be more the result of an impulse purchase in an airport waiting lounge bookshop than coming from a deep understanding of the topic.

That said, I must admit that learning about the Agile approach removed many of the challenges that had bedevilled me in recent years of running projects which had a sizeable IT element.

For example, how can you be sure that the developers are busy creating a product that the client actually wants? Answer: in Agile, the client SMEs are embedded as an integral part of the decision-making. Moreover, rather than waiting for the final deliverable to be polished and sparkly, we go ‘live’ with a product that does the barest minimum (the “Minimum Viable Product”). And while the client is using this initial version, we continue refining the product, stage by stage, until the client signs off the final, expected version with the minimum of fuss.

Then there is the perennially-vexed question of how best to handle change requests. In Agile the client is encouraged to request changes, which are simply fed into the next fortnightly scrum planning session. Commercial tolerances are agreed right at the outset, so that the project no longer has to shudder to an expensive halt while we wait for senior stakeholders to sign off.

At the end, the client gets what they actually need – even if they had to alter the specification during the process, leading to reduced stress all round and a happy client.

Perfect, isn’t it? Well, there are always caveats when using an exciting new approach.

Trusting the Agile approach

In the case of a pure Agile approach, the factor which forms the absolute bedrock underpinning the whole edifice is trust: the senior stakeholders have to trust that the Scrum Masters will lead the teams of developers effectively to produce the product as scoped and on time; that the budget spend remains within the financial parameters agreed and that any risks and issues that cannot be managed are promptly brought to the attention of the senior sponsors.

Gone are the set-piece project board meetings which eat into the calendar because the development team is fully accountable for progress and for any necessary changes; likewise, the written highlight reports, as project progress is updated to everyone verbally at a 15-minute daily stand-up meeting, clustering around the project whiteboard to share the latest data. And gone too is the need for detailed project plans: the very essence of Agile is that progress is dynamic. So why spend precious time trying to keep a detailed MS-Project plan up-to-date when everything could be re-written tomorrow?

Anyone who has run projects in the traditional “waterfall” way will recognize what a huge ask it is to seek such trust from most senior stakeholders: that includes the thought of abandoning the traditional governance model which they (like you) have come to expect. This is doubly so for a government client, always acutely conscious of the need to demonstrate full value for the tax payers’ money.

What then is the answer? What has worked really well for me is running a project using a hybrid model – combining the flexibility and advantages of Agile within a well-established and widely-used framework such as PRINCE2^®. Based on my own recent experience I suggest you:

1. Set up the software development process according to Agile principles and structure, led by a properly-trained Scrum Master.
2. Create the high level project plan just as you would in a standard “waterfall” project, but don’t be afraid of having lines that say no more than “Sprint 0”, “Sprint 1” and so on. Using Agile shouldn’t mean that other critical project activities, such as stakeholder communications, are not planned to a good level of detail.
3. Diarize regular, standard governance board meetings for your senior stakeholders and prepare a highlight report – but aim to restrict yourself just to one page. The key is to use these board meetings to reassure the stakeholders that you keep an eye on budget spend and that all is on track. “Earned Value Analysis” is a useful numerical way to evidence such reassurances.

Finally, be prepared to line manage the Scrum Masters and their product owners: the self-managing principle of Agile is great in theory, but everyone needs regular senior motivation and outside challenge to perform at their best.

Originally posted here

More thought leadership

Comments are closed.