Agile assurance plan for government projects
By Nick Butler
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.
What is assurance?
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.
New Zealand government assurance framework
The New Zealand government assurance framework is based on the Three lines of defence model.
The Three lines of defence:
- Day-to-day project management processes
- Governance and oversight
- Independent review (internal or external)
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:
- make effective use of the day-to-day project assurance that is built into Agile
- tailor and scale governance and independent review to the Agile approach.
Which projects the government assurance framework applies to
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 need System Assurance team oversight
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:
- have a briefing with the System Assurance team
- get sign off on:
- assurance plans
- terms of reference for independent assurance reviews
- assurance reports.
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.
Principles of good assurance
The government assurance guidance lays out six principles:
- Assurance by design: Assurance is not a one-time activity.
- Flexible: Assurance adapts to meet changes.
- Informs key decisions: Assurance provides timely, credible information.
- Risk and outcomes based: Assurance assesses the risks to successful delivery and their impact on outcomes.
- Independent and impartial: Assurance is performed by competent people outside of the delivery team. These people are not unduly influenced by key stakeholders.
- Accountability: Assurance roles and responsibilities at the governance level are understood.
These principles align well with the principles and values of Agile. Together they underpin an effective Agile assurance plan.
Agile and assurance
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:
- user test the software to see how well it’s delivering the planned benefits
- demonstrate the software to your governance group so they can assess progress
- get independent reviews of the software.
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?
Harnessing Agile tools for assurance
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.
Agile assurance plan
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:
- the outcomes and scope of your project
- assurance roles and responsibilities
- risks for your project
- how you’ll put the three layers of defence into action.
Outcomes and scope: project discovery and Agile assurance
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).
Minimum Viable Product and Agile assurance
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.
Discovery workshops build a shared understanding fast
A discovery workshop is usually the fastest, most-effective way to build a shared understanding of your:
- outcomes — your vision, strategy, target users and metrics
- plan to get there — a prioritised backlog for your MVP
- Agile methodology — how it provides project assurance.
The workshop also lets you:
- engage with and learn from your governance and independent review groups
- feed in lessons learned from previous phases and related projects
- identify risks and assumptions to be tested and the resulting assurance priorities
- provide initial Agile training.
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.
Agile assurance roles and responsibilities
Here are typical assurance roles and responsibilities for an Agile project.
Senior Responsible Officer
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.
Agile delivery team or Scrum team
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.
Risk and your Agile assurance plan
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:
- challenging time or budget constraints
- new technology or approaches
- assumptions about the users or the solution
- requirements that are essential for government agencies such as security, privacy and accessibility
- the capability of the SRO, governance group, delivery team, independent reviewers, especially their experience with Agile.
Ways of mitigating these risks include:
- adding quality factors such as security and accessibility to your definition of done
- building quality factors into your software delivery pipeline
- including work in the backlog to address the risks
- testing assumptions or new approaches through small scale tests like spikes and prototypes
- getting independent reviews of essential quality factors
- Agile training and capability-building.
Definition of done and Agile quality assurance
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.
Three lines of defence in action
Your Agile assurance plan will show how you’ll run your first line of defence in order to enable the second and third lines.
Setting up your working environment for Agile assurance
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.
First line of defence: Day-to-day project management
The key is to check that:
- your team is delivering working software at the end of each iteration
- this software meets your definition of done
- this software delivers the user benefits that will achieve your outcomes.
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:
- recording requirements as user benefits (through user stories for example) and sharing these with the governance group through your digital tracking tool
- undertaking user research such as user testing and, for existing applications or beta releases, tracking analytics and bug reports, user feedback and reviews, and insights from your customer service team
- using this research to check how well you’re delivering your outcomes and meeting your metrics, and sharing the results with your governance group
- demoing and getting feedback on the working software at end-of-iteration reviews that your governance, independent review and other stakeholder groups can attend
- ensuring the team regularly checks and improves their work, including through automated testing, code reviews and product owner acceptance checks.
It can help to get an independent assessment of your Agile practices. For example, we offer the Agile Accelerator assessment and action plan.
Second line of defence: Governance and oversight
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:
- time and budget spend to date and remaining
- access to the digital project tracking tool showing the backlog and the work already delivered
- burndown or burnup charts generated by the tracking tool
- user testing and research results
- metrics reports.
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.
Governance group membership
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.
Third line of defence: Independent review
You can get independent internal or external teams to review priority aspects of project delivery.
Examples of internal review teams include:
- Audit and Risk Committee
- Enterprise Project Management Office (EPMO).
Examples of external reviews include:
- Security (Penetration testing, Security Risk Assessment, Controls Validation Audit)
- Privacy Impact Assessment
- Government web accessibility and usability web standards.
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.
External reviewers must be on the GCDO assurance panel
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.
Assurance plan template
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).
Example Agile assurance plan
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.
1 Investment overview
1.1 Objectives and outcomes
<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.>
- Strategy and target users
- Key metrics
<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.
1.3 Risk rating
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.
1.4 Referenced documents/artefacts
- Link to digital version of the backlog
- Discovery deliverables
- Governance TOR
- Independent review TORs
- Definition of done
- Maintenance plan
- Statement of Work
2 Assurance plan overview
2.1 Assurance approach
<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.
2.2 Lessons learned
<Outline any specific lessons learned from similar initiatives. Show how you have incorporated these into your assurance approach.>
Lessons learned from previous project A:
- Actions from retrospectives
- Discovery deliverables
- User research insights
- Techniques that helped people involved in assurance understand and use Scrum effectively
2.3 Key risks
<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:
- User needs assumption A
- New technology B
- Lack of Agile experience for independent reviewer C
- Fixed deadline D
2.4 Plan on a page
<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:
- SRO signs off on this assurance plan.
Discovery stage gate:
- SRO signs off on the vision, strategy and MVP.
Integration of work into the increment:
- Product owner accepts.
- Meets DoD.
Prototype stage gate:
- Prototype user testing: key tasks completed within tolerance.
Go live stage gate:
- MVP user testing: key tasks completed within tolerance.
- Independent reviews passed.
- Maintenance plan accepted.
3 Detailed assurance plan
3.1 Independent assurance
<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.>
- CISO sign-off
- Architecture group sign-off
- Security reviews
- Penetration testing
- Security Risk Assessment
- Controls Validation Audit
- Privacy Impact Assessment
- Government web standards assessment
3.2 Governance and oversight
< Include regular governance and oversight activities.>
- Review: Every two weeks.
- SRO meeting with the product owner: Every week.
- Governance group meeting schedule: Every two months.
- Time and budget reports: Every two weeks.
- User research reports: As completed.
4 Assurance roles and responsibilities
4.1 Governance structure
<Include a diagram of the governance structure for the investment.>
4.2 Assurance roles and responsibilities
<Describe assurance roles and responsibilities.>
- SRO reviews and accepts the assurance plan, discovery deliverables and assurance reports.
- Product owner reviews and accepts the DoD.
- Product owner reviews and accepts individual user stories.
- All governance group members and independent reviewers can attend reviews.
- Product owner and SRO receive user research, time and budget reports.
- Governance group receive discovery deliverables and user research reports.
- Any member of the Agile delivery team, governance group or independent reviewers can raise issues with the product owner at any time. The product owner can raise issues with the Agile coach at any time.
Lessons learned and case studies
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
More resources for government agencies
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
Questions and feedback
If you have any questions or feedback, email me at: [email protected]