The Better Business Case framework works for investments that use Agile methods – the process allows flexibility within parameters that keep everyone safe, and fully supports innovation and optimisation.
What an Agile project is
There are two main classes of 'agile' projects, discovery-based and burn-down.
These ask decision-makers to invest a fixed sum of money to prove/disprove a hypothesis (R&D, feasibility projects), either to explore and stop or as a precursor to a business case for a larger project. The core features of discovery-based projects are:
- uncertainty about project direction or outcomes
- constant incremental delivery of value
- the ability to pivot delivery as new value is discovered
- the ability to stop at any point when sufficient value is delivered, or if the value to be delivered does not warrant the effort required.
This approach is best suited to market-led discovery projects which seek to:
- investigate feasibility
- exploit 'first mover advantage'
- explore market value, or
- push revenue.
They are often used to incrementally deliver new services on-line, where small frequent delivery of functionality can add significant customer value. There are few of these projects in government.
One example: DIA's 'life event' projects seeking to determine how/whether to develop a one-stop shop for information relating to life events.
These projects are small, because they are experimental, and the money may need to be written off. Generally, a project over $5 to $10 million is not a 'discovery' project. They should be funded from operating expenditure, or through a tightly controlled innovation fund to avoid waste of public funds.
This approach is not suited to all project types. For example, when the outcome, scope and requirements are well-understood (such as replacement of a legacy system), discovery is not required, and there is no ability to stop before the scope is delivered. Another example is when there is a single unitary deliverable (such as a database migration). If the problem cannot be subdivided into deliverable units, it's not agile, by definition.
Burn-down projects are where agile techniques are used to enable and control incremental development, even if frequent incremental delivery of functionality is not possible. Projects where outcomes, scope and requirements are known or largely known (such as Financial Management Information Systems, database migration, legacy systems replacement) are not well-suited to an agile discovery approach. However, agile methods can be used to burn-down a fixed backlog until the scope of the legacy system has been replaced. As in any project, there may be parts that are discovery-based, to seek the best approach to deliver part of the functionality, but this does not mean this approach is suited to the whole project.
Large Agile projects
Difficulties arise when a decision is made to combine a large Agile development project with a business transformation. In this case, there needs to be very clear thinking around the boundaries:
- what the Minimum Viable Product is
- what part of the project is foundational and replacement and what part is transformational
- design constraints must be set to ensure focus remains on the development.
There is a very real risk in seeking transformation that the foundational aspects will be overlooked, by chasing customer value rather than systematically addressing the development backlog.
How to use the Five Case Model with Agile projects
The purpose of the Strategic Case is to make a compelling case for change – why should decision-makers fund this initiative, right now, rather than another?
An agile project must still make this case:
- How the proposal supports the agency's, sector's or government's long-term strategies, expected outcomes, investment objectives and benefits.
- Any initiative will have key risks, assumptions and dependencies which may impact on its deliverability.
The Strategic Case describes the problems or opportunities and the outcomes you want to achieve for any investment regardless of delivery method, so Cabinet can decide if it wants to invest.
Agile delivery is an implementation option dimension assessed in the Economic Case – this case needs to demonstrate how using an agile approach will support successful delivery. If, following options analysis, agile implementation forms part of the ‘best public value’ option then it generally becomes the preferred option.
The Economic Case includes a formal assessment of options and must confirm that an agile approach will work best and provide best value (for money and for New Zealand). The business case should clearly show the benefits of an agile approach, not simply assume it is the right approach or only option. Nor does a decision to develop using agile methods provide an agency the capability to deliver this way. Implementing an agile engineering practice is a significant effort in its own right. All this needs people with the capability to carry out the work – this is often where agencies struggle the most and compete in a limited market.
An agile approach requires planning, just as a more traditional approach does. The details are different. The decision to take an agile approach should itself be part of a considered planning process.
Estimating for any project is difficult – for agile no more than for traditional development methods. This does not mean it should not be done.
For a 'discovery' agile project scope is the unknown, work ceases when enough value has been delivered. Funding, staffing and time can be used as the basis for costing.
For a 'burn-down' agile project where scope is known:
- the scope suggests the number of squads required, and drives the backlog
- squads have a likely membership composition
- other support (architecture, change management, legacy integration) requirements can be identified
- this gives a burn rate that can be used as a basis for costing.
Just as with a traditional project, if external vendors or resources are being used a procurement plan is required. The Digital Public Service branch, New Zealand Government Procurement and Datacom NZ have worked together to develop guidance on agile procurement and agile development.
'Discovery-based' projects are normally small, because they are investigative and the money may need to be written off. They should be small enough to be funded by your organisation (under the Chief Executive’s delegated financial authority) and should not require a business case to go to Cabinet.
For ‘Burn-down’ projects, agile delivery informs the funding requirements. They are usually:
- tranched or phased in line with the initiative roadmap
- funded using a relevant business case and outcome-based
- reported on the success of the previous tranche (such as the Detailed or Single-stage Business Case).
Regardless of the implementation option, the Financial case must provide analysis of the impact of the work on agency cashflow and operating costs.
To support incremental funding, this case might focus on the next or prioritised outcomes (effectively a tranche). The project should deliver these outcomes, and a new management case for the next tranche, before getting the next tranche of funding.
The management case describes the structures and controls that will be implemented to make sure the initiative can succeed. This is as important for agile projects as for traditional, and even more rigorous as agile methods must constantly check that value is being delivered and the backlog burned down.
Agile delivery informs the management case in terms of the prioritisation of functionality and scoping of tranches or phases in the plan for the initiative, and the release of benefits or value following each tranche.
It is also important to have fit-for-purpose ongoing independent assurance, to make sure value is being delivered as often as expected in line with expected outcomes.