By Nick Butler
Tags: Agile , Development , Other
This guide shows you how to put together a simple Agile assurance plan for government projects with a digital component.
Based on the government assurance framework, it includes an example Agile assurance plan that follows the assurance plan template.
The guide shows you how to apply the Three lines of defence assurance model to Agile projects. You do this by integrating day-to-day Agile project management with governance and independent reviews.
For simplicity’s sake it mainly talks about projects, but it applies to programmes as well. Similarly, while it’s specifically for government digital projects, the approach will work for any Agile project.
Assurance is what you’ll do to be sure your project succeeds. It has to be objective and must allow independent oversight.
At its heart, Agile is assurance. That’s because the various Agile frameworks were developed as assurance tools. They de-risk projects by giving a timely, objective view of progress towards your priority outcomes.
Having a simple assurance plan creates clarity for your delivery, governance and oversight teams. It lets you spell out how Agile’s in-built assurance processes work, and what that means for them.
So here’s how you can use an Agile assurance plan to de-risk and de-stress the delivery of digital projects. It shows how you can ensure you’re creating all the value you can for the people of Aotearoa New Zealand.
The New Zealand government assurance framework is based on the Three lines of defence model.
The Three lines of defence:
For traditional Waterfall project management, the framework focuses on the second two. Agile is different though. The government guidance on Agile assurance puts it like this:
“Agile is more self-assuring than Waterfall. This means that assurance is part of the delivery process, with risk management embedded into day-to-day operations.”
So a successful Agile assurance plan will:
Following the framework is mandatory for all digital investments by public service departments. The same goes for Police, Defence and the parliamentary agencies, district health boards and some Crown entities (ACC, EQC, NZQA, NZTA, HNZC, NZTE, TEC).
A digital investment is any project or programme that uses technology as the main way it achieves its planned benefits. So it includes both public-facing digital services and internal tools.
High-risk projects must get a costed assurance plan signed off by the System Assurance team of the Government Chief Digital Officer (GCDO).
You determine the risk of the project with Treasury’s risk profile assessment tool. This risk assessment is broadly based on impact, scope and complexity.
For high-risk projects the Senior Responsible Officer (SRO) must:
In Agile you actively reduce scope and complexity by developing the smallest, simplest solutions. This means even high-impact projects can be low risk. As a result they don’t need this level of oversight.
The government assurance guidance lays out six principles:
These principles align well with the principles and values of Agile. Together they underpin an effective Agile assurance plan.
As noted earlier, Agile is assurance by design.
Agile lets you get an independent and objective assessment of how well your project is achieving its goals. The main way you do this is by delivering working software early and often. This means you can:
The government assurance framework advises agencies to tailor their assurance to the delivery approach. “For example, in an Agile / DevOps environment there may be greater reliance on assurance activities embedded into day-to-day project delivery and governance activities.”
Because Agile embeds risk management in your day-to-day processes, your assurance needs to focus on these day-to-day Agile processes. Are the Agile values and principles guiding all your work? Are you harnessing the tools of your chosen framework effectively?
Here’s an example of how you might harness Scrum for assurance. (Scrum and Scrum hybrids are the most popular Agile frameworks, so we’re using Scrum for our examples).
You identify that user stories are often getting rolled over into the next sprint. You haven’t been delivering working software that meets your definition of done by the end of your sprints. As a result, you haven’t been able to inspect it through user testing. Which means you don’t know if it needs to be adapted. On top of that, the governance group can’t assess your progress at the review. And there is nothing for independent reviewers to check. So, at the retrospective, the team works out together what needs to change. They then put this into place for the next sprint.
An Agile assurance plan provides clarity about how you’ll ensure the project succeeds. It helps you set expectations with your delivery, governance and independent review teams.
Specifically, you’ll need to get clarity on:
Everyone in the three lines of defence needs a shared vision for the project outcomes. How will you make the world a better place by helping your customers and enabling the strategic goals of your organisation?
You’re looking for the smallest, simplest solution that achieves these outcomes. This is often known as the Minimum Viable Product (MVP).
The MVP is an evolving description of the smallest, cohesive, standalone solution. It lets your users complete just enough of their goals that they’ll want to use it. So it’s the minimum you can do to achieve your outcomes. The details of this solution can change as user research delivers new insights. You can then re-prioritise your future work based on these insights.
So assurance isn’t tracking how well you deliver the original description of the MVP. Rather, it’s tracking how well you’re achieving the outcomes that prompted it.
A discovery workshop is usually the fastest, most-effective way to build a shared understanding of your:
The workshop also lets you:
If you’re running an ongoing co-design process, you’ll be able to include governance and independent review people on the co-design group.
We’ve put together a step-by-step guide to running discovery workshops based on a toolkit of activities we’ve refined over the years.
For certain projects, we can also facilitate a free discovery workshop.
Here are typical assurance roles and responsibilities for an Agile project.
The project sponsor with overall responsibility for project success. The SRO signs off on the project outcomes and the assurance plan that will ensure these are achieved.
A group formally charged with overseeing the project and chaired by the SRO. The group focuses on steering the project to achieve the overall outcomes, not on the day-to-day details.
Internal or external teams tasked with reviewing aspects of project delivery, such as architecture, risk, security, privacy etc.
A collaborative unit jointly responsible for day-to-day assurance. The team is made up of the:
Product owner: Responsible for maximising the value the project delivers. The product owner sets priorities based on the agreed project outcomes. They need the time and authority to give feedback quickly and decisively. At Boost, we’ve found that this is one of the most important success factors for Agile projects. Here’s our guide to success as a Scrum product owner.
Developers: A cross-functional team of developers, designers and anyone else needed to deliver working software each iteration without hand-off to anyone else. The developers organise their own work, share joint responsibility for the product and focus solely on the project.
Agile coach or Scrum master: An expert in Agile delivery who ensures the team maintains an Agile mindset and follows best practice for the Agile framework they’re using.
Agile capability is a key factor for project success. That’s why Boost’s ICAgile-certified trainers provide free Agile training to all members of the team.
The core risks for any project are failure to deliver your planned benefits on time, on budget and at the quality needed.
Agile risk management makes progress towards your outcomes transparent. You achieve this by delivering user-ready software that is the smallest, simplest solution for your current top priority user benefit. By doing this in short iterations (between one and four weeks) you can get fast feedback on how well you’re achieving your outcomes.
So at the end of each iteration, the value the product offers users and the time and budget remaining are clear and visible. On top of that, quality is assured by checking that all work meets the definition of done (see below).
Risk-based assurance also means identifying and mitigating the risks from the most-likely points of failure. These might include:
Ways of mitigating these risks include:
The definition of done (DoD) is a checklist of the quality standards work needs to meet before it is complete and release-ready. You can find definition of done examples and guidance here.
The DoD reflects the project and the product owner’s assurance priorities. Even so, it’s best to develop it collaboratively. That way everyone has a shared understanding of the DoD. Here’s how to run a DoD exercise.
Your Agile assurance plan will show how you’ll run your first line of defence in order to enable the second and third lines.
Ideally the whole Scrum team will be colocated. This gives you the benefits of face-to-face communication. If this isn’t possible, the team should have a robust video conferencing setup.
The main shared workspace should feature a prominent physical project board showing the work of the team. This keeps progress visible at all times.
The key is to check that:
If you’re not, you work out as a team the changes you need to make to the way you’re working. As noted earlier, all members of the Agile delivery team share responsibility for day-to-day assurance.
You can make assurance easier by:
It can help to get an independent assessment of your Agile practices. For example, we offer the Agile Accelerator assessment and action plan.
During project initiation and discovery you’ll show how assurance will work on your Agile project. In particular, you’ll spell out the governance group’s role in the process. This will include their Terms of Reference (TOR).
Your aim is to give the governance group clear and timely ways of assessing and influencing progress. A simple way to do this is to let them know they can raise any concerns about progress towards the project outcomes at any time. The product owner is the best point of contact for this.
Reviewing working software is central to Agile assurance. Every iteration you’ll have an improved working version of the software to show them at the review. Their feedback on how well it’s achieving outcomes will influence priorities for the iteration ahead.
Additional reporting might include:
Keep reports short, simple and engaging. Governance teams tend to be time-poor.
In addition to the governance group meetings, it’s useful for the product owner to have regular one-on-one catch-ups with the SRO.
Ideally the governance group will be made up of those people with the expertise, influence and interest to ensure project success. As a rule of thumb, the fewer the better.
The group can include your independent reviewers and external experts. It can change as the project progresses and you need different skills.
Skilled facilitation helps keep meetings engaging, effective and timeboxed. It’s especially important now COVID has made so many meetings virtual, with the additional challenges this brings. It’s best that the product owner doesn’t facilitate meetings. That’s because it’s hard for them to facilitate and process feedback at the same time.
Early on, you can build engagement and clarity by getting the governance group to decide themselves how they can fulfil their responsibilities under the TOR.
You can get independent internal or external teams to review priority aspects of project delivery.
Examples of internal review teams include:
Examples of external reviews include:
Try to use people with Agile experience. This makes it easier for them to understand their role in the assurance process.
You can keep them in the loop by including them in the governance group, reviews and other reporting.
Find out what to ask for in an assurance report.
All government digital projects must use providers on the GCDO Assurance Services Panel for third-party assurance reviews. To find vendors, check the GCDO assurance services panel on the Procurement website.
The government assurance guidance provides this template: Template for assurance plan (Word 71KB).
They also have this checklist to help you complete the template: Quality review checklist for assurance plan (Word 117KB).
This example is for a non-specific public-facing web application. It shows the type of information you’d include, not the detailed information itself.
Your plan will evolve. You don’t need everything up front, just enough to get you to the next stage.
<Include an overview of the investment objectives and outcomes being sought. This should include alignment to any strategic, sector or All-of-Government outcomes and agreed success criteria.>
<Include an overview of the structure of the investment. Is this a portfolio, programme or project and what methodology is being applied.>
This is Project B. It follows on from Project A. It will use the Scrum methodology.
N/A — We’re assuming that this isn’t a high-risk project because you’ve de-risked it when you developed your business case. Get guidance on how to develop low-risk government business cases.
<Include an overview of the assurance objectives, scope and approach.>
The project will use Scrum methodology to provide assurance that we deliver the outcomes noted above.
Working software will be the primary measure of progress. We will demo the latest iteration at the review at the end of each two-week sprint. Work will only be considered complete if it meets the quality standards in our definition of done. User testing and other user research will assess how well the software delivers the planned user benefits. We will use learnings from the user research, and feedback from the review, to prioritise work for the sprint ahead. Budget and time remaining will be tracked.
<Outline any specific lessons learned from similar initiatives. Show how you have incorporated these into your assurance approach.>
Lessons learned from previous project A:
<Include key strategic and delivery risks for the investment.>
Failure to deliver on time, on budget and to acceptable quality will mean the planned user benefits will remain un-realised.
Potential points of failure include:
<Include a high level overview of the key assurance activities (‘plan on a page’). Show key decision points (including stage gates) and assurance activities that support the key decision points.>
Assurance stage gate:
Discovery stage gate:
Integration of work into the increment:
Prototype stage gate:
Go live stage gate:
<Include internal audit reviews; third party assurance reviews, including Independent Quality Assurance (IQA) and Technical Quality Assurance (TQA) reviews; quantitative risk analysis; and Gateway reviews.>
Internal:
External:
< Include regular governance and oversight activities.>
<Include a diagram of the governance structure for the investment.>
<Describe assurance roles and responsibilities.>
The government assurance guidance features a range of lessons learned and case studies. These include approaches that fit well with Agile, such as the Ministry of Justice proof of concept.
Government assurance lessons learned and case studies
All-of-Government Portfolio, Programme and Project Assurance Framework
Government assurance guidance for Agile delivery
Security in Agile software development
Accessibility: a non-technical introduction
Better Business Cases guidance: Public value at pace
Government Digital Service Design Standard made simple
Government procurement made simple
Government Marketplace: An intro to the procurement panel
NZ Government consultancy panel: how to use it
If you have any questions or feedback, email me at: [email protected]
