Agile Delivery

Fortnightly sprints, "show the thing" demos, disciplined backlog management, and automated release pipelines.

Overview

Every project since the company started in 2013 has run this way.

Agile solves one problem, and it is worth being precise about which. No set of requirements written up front is ever complete or quite right. You can spend longer writing them and they still will not be. The only thing that reliably closes the gap is putting working software in front of people and changing it based on what happens.

Single-team Scrum for smaller engagements, SAFe programme increments when several teams have to move together.

How We Deliver

Sprint Cycle

Every project runs in fortnightly sprints within broader delivery stages (typically 3-month programme increments). Detailed scope for each stage is agreed at stage commencement, with fine-grained adjustments at the start of each sprint.

Each fortnight follows the same rhythm:

  • Day 1 morning — Sprint planning. Prioritised sprint backlog of detailed user stories with clear definitions of done.
  • Days 1–10 — Delivery. Developers pull items, build features, write tests, submit for QA. Daily standups (15 minutes, or async via Slack) keep the team aligned.
  • Day 10 afternoon — “Show the thing.” Live demonstration of deployed software to stakeholders. Feedback collected, next sprint priorities agreed.
  • Retrospective — What went well, what to improve.

“Show the thing” catches misunderstandings earlier than anything else we have tried, because a demonstration cannot be talked up the way a status report can. Every sprint, every project, for over a decade.

Issue Lifecycle

Every Product Backlog Item follows a Kanban workflow visible to both the delivery team and the client:

Backlog → In Dev → In QA → Done

Items that fail QA return to development with clear feedback. This workflow runs on GitHub Projects or Azure DevOps Boards, giving stakeholders real-time visibility without status meetings.

Release Process

Our release pipeline is automated end to end:

  1. Developer commits code; automated tests run in the feature branch.
  2. Pull request raised; peer review by other developers.
  3. Tech lead approves and merges; full test suite runs.
  4. Auto-deploy to test environment.
  5. QA against story requirements.
  6. Tag for release; deploy to pre-production for UAT.
  7. Production release triggered by DevOps staff.

On mature projects such as National Parks, this pipeline has supported over 200 production releases with zero failures.

Principles

  • Working software over documentation. Something deployed gets demonstrated every fortnight. Documentation serves the software rather than standing in for it.
  • Requirements are a living asset. What you start with is a baseline, not a contract with reality. The best requirements turn up once somebody has used the thing.
  • Transparency. Backlogs, sprint reports and demonstrations are open. Clients have access to the code, the issues and the pipelines, not a summary of them.

Policy Alignment

The method maps onto the Digital Service Standard’s stage gates, Discovery through Alpha, Beta and Live, and onto its criteria for multidisciplinary teams, user testing and service monitoring.

Evidence

National Parks e-ticketing has taken more than 200 production releases without a failure, across ten years of this. Indigenous ranger biosecurity had a prototype in four weeks and spent the next six months being shaped by what users did with it.

Chris Gough drives the delivery practice across engagements. Backlogs run on GitHub Projects or Azure DevOps Boards, pipelines on GitHub Actions or AWS CodePipeline, with Figma for prototyping.

See all capabilities