Agile Delivery

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

Overview

GoSource has delivered every project using agile methods since the company was founded in 2013. We believe agile exists to solve a specific problem: no set of upfront requirements will ever be complete or exactly right. The only reliable way to converge on the right solution is to iterate over working software, gather real feedback, and adjust. We scale from single-team Scrum for smaller engagements to SAFe programme increments for multi-team programmes.

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” is the single most effective mechanism for catching misunderstandings early. We have run it 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. We demonstrate deployed systems every two weeks. Documentation serves the software, not the other way around.
  • Requirements are a living asset. Initial requirements are a baseline to be refined through delivery. The best requirements emerge from seeing real systems in action.
  • Transparency. Open backlogs, sprint reports, and demonstrations. Our clients have access to all code, issues, and delivery pipelines.

Policy Alignment

  • Digital Service Standard (DSS v2.0) — Our delivery methodology aligns with DSS stage gates (Discovery, Alpha, Beta, Live) and criteria for multidisciplinary teams, user testing, and service monitoring.

Evidence

  • Case Study: National Parks e-Ticketing — 200+ production releases with zero failures over 10+ years of agile delivery.
  • Case Study: Indigenous Ranger Biosecurity — Prototype in 4 weeks, refined over 6 months from user feedback.
  • Staff: Stephen Cushing (Delivery Manager) — Professional Scrum Master I, 26 years delivery experience.
  • Staff: Chris Gough (Solution Architect) — Drives agile delivery practices across all GoSource engagements.

Tools & Technologies

  • Backlog Management: GitHub Issues / GitHub Projects, Azure DevOps Boards
  • CI/CD: GitHub Actions, AWS CodePipeline
  • Documentation: GitHub Wikis, Confluence
  • UX Prototyping: Figma
See all capabilities