DevOps and observability · Illustrative simulation
From backlog to production: an Agile delivery playbook
Agile in one minute · Sprint simulator · A developer's day · Which method fits? · DORA metrics · SLOs · Releasing safely · Security built in · Public sector · Check · Sources
Modern software ships in small, frequent, safe steps. Follow one team through six sprints, from a backlog of ideas to a production release, and see how Agile planning, DevSecOps pipelines and reliability targets work together.
The quotes and sources could not be loaded. Please reload the page.
Agile in one minute
The Agile Manifesto (2001) states four values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Four of its twelve principles:
Agile is a set of values, not a single method. The methods below are different ways of living them.
The sprint simulator
Northgate Services, a fictional organization, is building version 2.0 of a customer self-service portal. Follow its team through six two-week sprints.
- Product owner
- Scrum master
- Full-stack developer
- Full-stack developer
- Full-stack developer
The simulator needs JavaScript. In words: over six sprints the team moves from weekly deployments, a 4-day change lead time, a 15% change fail rate and 6-hour recovery to on-demand deployments, under one day, 5% and under one hour (illustrative). Along the way it adds a daily-merge pipeline, an automated security scan, an error budget policy and a canary then blue-green release.
Illustrative example. The organization, the team and every number are invented to explain the ideas.
How a full-stack developer's day fits in
One day in the life of a developer on this team, from standup to on-call handoff.
- Morning standup15 minutes: what moved, what is blocked.
- Pick the top itemTake the highest-ordered item from the sprint backlog.
- Make a small changeWork on a short-lived branch.
- PushAutomated tests and the security scan run on every push.
- Code reviewA teammate reviews the change.
- Merge to trunkThe merge triggers the build and tests again.
- Deploy behind a feature flagThe change is live in production but switched off for users.
- Check the serviceLook at the service dashboard and the SLOs after the deploy.
- On-call handoffTell the on-call engineer what changed and what to watch.
Scrum, Kanban, XP and scaled Agile: which fits?
| Method | Rhythm | Best when | Watch out for |
|---|---|---|---|
| Scrum | Fixed-length sprints of one month or less, each with a Sprint Goal and a Definition of Done. | One team of typically 10 or fewer people builds a product and wants a regular rhythm of planning, review and improvement. | Treating the events as ritual, or changing the sprint goal every few days. |
| Kanban | Continuous flow, no fixed sprints. Work in progress is limited, and flow is measured by throughput, work item age and cycle time. | Work arrives unpredictably, such as operations, support or maintenance. | Without real limits on work in progress, the board turns into a long queue. |
| Extreme Programming (XP) | Small releases and continuous integration, supported by practices such as test-driven development and pair programming. | The team controls its own code and wants strong engineering habits. | It asks for discipline and close collaboration, and is hard to adopt halfway. |
| SAFe | A Planning Interval of typically 8 to 12 weeks, with a two-day planning event for the whole release train. | Many teams (a release train is typically about 50 to 125 people) must align on one release. | Process weight: the roles, events and planning can outgrow the problem they were adopted to solve. |
| LeSS (Large-Scale Scrum) | Scrum, scaled across several teams working on one product. | Several Scrum teams build one product (basic LeSS is up to about eight teams of about eight people). | It scales Scrum’s simplicity, so it asks the organization to change its structure, not just its meetings. |
| Scrum@Scale | Scrum teams coordinated through a ‘scale-free’ architecture that aims for minimum viable bureaucracy. | You already run Scrum and need to coordinate many teams without heavy overhead. | A light framework leaves more decisions to you, and coordination still needs clear owners. |
| Hybrid | A mix: for example, fixed milestones for contracts and dates, with Agile teams delivering inside them. | Parts of the work are predictable and parts are not. PMI reports hybrid use rose from 20% in 2020 to 31.5% in 2023. | Mixing without clear rules can leave a team with the paperwork of both approaches. |
Most organizations run a hybrid. What matters is short feedback loops, small batches and honest metrics, not the label.
Measuring delivery: the DORA metrics
DORA, the DevOps Research and Assessment program at Google Cloud, uses five software delivery metrics: three about throughput and two about instability.
Change lead time
Deployment frequency
How often the team deploys to production.
Failed deployment recovery time
How long it takes to recover when a deployment causes a failure in production.
Change fail rate
The share of deployments that cause a failure and need a fix.
Deployment rework rate
How much unplanned work deployments create to fix earlier problems.
DORA's wording:
Performance levels in the 2024 report
| Level | Share of respondents | Change lead time | Deployment frequency | Change fail rate | Failed deployment recovery time |
|---|---|---|---|---|---|
| Elite | 19% | Less than one day | On demand | 5% | Less than one hour |
| High | 22% | One day to one week | Daily to weekly | 20% | Less than one day |
| Medium | 35% | One week to one month | Weekly to monthly | 10% | Less than one day |
| Low | 25% | One to six months | Monthly to every six months | 40% | One week to one month |
Survey of more than 39,000 professionals.
As published in the 2024 report. Note that the Medium group reported a lower change fail rate than High.
The 2025 report replaced these levels with seven team archetypes.
AI use is now nearly universal: 90% of 2025 respondents report using it at work, and in 2024, 75.9% relied on it for at least one daily task. It is associated with higher throughput but is still associated with lower delivery stability, so it acts as an amplifier of the practices a team already has.
Reliability as a contract: SLIs, SLOs and error budgets
SLI: what you measure
SLO: the target
Error budget: room to fail
How much downtime does an SLO allow?
The calculator needs JavaScript. In words: a 99.9% SLO over 30 days allows 43.2 minutes of downtime; 99.99% allows 4.32 minutes.
Illustrative calculator. Allowed downtime = (100% − SLO) × length of the window.
When the budget is spent, an error budget policy says what happens next. In Google's example policy, the team halts changes and releases other than P0 issues or security fixes until the service is back within its SLO.
100% is the wrong target. Pick the level your users actually need.
Releasing safely
Blue-green
Google's SRE Workbook notes that blue/green deployment roughly doubles the resources needed.
Canary
Feature flags
Flags carry a cost of their own and should be removed once a feature is fully released.
Continuous delivery and continuous deployment
Continuous Deployment goes one step further and releases every change that passes.
Security built in (DevSecOps)
Standards to measure your pipeline against:
- NIST SSDF (SP 800-218, v1.1, February 2022). Its practices are organized into four groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities.
- NIST SP 800-204D (February 2024). Strategies for integrating software supply chain security into DevSecOps CI/CD pipelines for cloud-native applications.
- CISA Secure by Design. Principles include taking ownership of customer security outcomes, embracing radical transparency and accountability, and leading from the top.
- CISA Secure by Design Pledge (May 2024). Voluntary commitments by 68 software manufacturers.
- OWASP Top 10:2025. A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging and Alerting Failures, A10 Mishandling of Exceptional Conditions.
- SLSA v1.2. The latest approved version of the supply chain security framework; it adds a Source track.
In the public sector
- The US Digital Services Playbook has 13 plays; Play 4 reads “Build the service using agile and iterative practices”.
- “Since 2012, OMB has required investments to deliver functionality every 6 months.” In fiscal 2016, about 64% of 469 projects planned to.
- Texas agencies using adaptive project methods such as agile grew 9% compared with 2020. Among agile users, 46% use Scrum and 22% use Kanban.
- Texas also publishes an Application Development Decision Framework to help agencies choose among Scrum, Kanban, LeSS, DAD and other approaches.
Where is your team? Agile delivery check
Eight questions, about two minutes. You get a scorecard with steps to fix each gap. Your answers stay in your browser unless you choose to send a project request.
The check needs JavaScript.
Sources
Facts checked Oct 12, 2026.
Illustrative simulation. The organization, team and numbers are invented to explain the ideas and are not measured data or a benchmark. Framework names belong to their owners; King Tech is independent and isn't affiliated with them.