There are plenty of teams that are able to do two week sprints and still get to production once a quarter. The board moves on a daily basis while completed work is queued up for review, regression and approval. This is where delivery time goes and what is done by experienced teams to get it back.
Digital Agility Is a Delivery Capability, Not a Methodology
Agile ceremonies are the way that a development team works. Digital agility is more comprehensive – how fast and secure an organisation can switch running software when the business requires it. This depends on the structure of the code, infrastructure, test automation and who has the authority to approve a release. It is possible for a team to perform all the Scrum Rituals perfectly and still not achieve all four.
The two-week sprints are pushed to a monthly release train which waits on manual regression and a change advisory board. A story is considered done when it is marked as such by the developers on day 9, and is visible to customers 6 weeks later. That setup is just for looks, the cadence of the sprints is cosmetic.
Here, speed is not about the time taken from ticket start to “dev done”, but rather from idea to production.
Finding Where Delivery Time Really Goes
Any change traced will have a small working time. Most of the lead time is waiting time: waiting for a reviewer, waiting for a test environment, waiting for the QA handoff, waiting for security sign-off, waiting for next release window, etc.
The four metrics from DevOps Research and Assessment (DORA) make a practical baseline. Deployment frequency counts how often code reaches production. Lead time for changes measures commit to production. Change failure rate tracks the share of deployments that cause incidents, and time to restore measures how long recovery takes.
One real feature value stream mapping is the least expensive diagnostic. Capture the timestamps from the ticket, pull request (PR) and pipeline, and measure the time for each stage. A typical outcome: 4 hours of coding and 2-3 days for PR to be reviewed. This is not new tooling, this is a review/turnaround agreement and smaller PRs.
Ignore story points, cross team velocity comparisons and lines of code. They measure activity and teams learn to inflate activity.
Engineering Practices That Make Small, Frequent Changes Safe
Batch size is the main lever. A 50-line change can be easily reviewed, tested quickly and easily rolled back. A 2,000-line change is skimmed, goes in QA and makes every deployment an event.
By default, batches are small, since the trunk-based development with two or three days of branches’ lives. Feature branches evolve from main over a long period of time until the merge is a project in its own right.
Using feature flags, teams can deploy unfinished work without shipping it, and avoid the risk of shipping a feature. Without an owner and removal date, the codebase is littered with old toggles and untested combinations.
A Continuous Integration and Continuous Delivery (CI/CD) pipeline that works stealthily behind the scenes for an hour will push back developers to batching. Another queue is eliminated in the form of self-service ephemeral environments and infrastructure as code, the ops ticket for a test server.
Microservices are optional. A monolith with a good modularization and fast pipeline can deploy on a daily basis.
Testing as the Real Throughput Constraint
Typically, when development picks up, testing becomes the limiting factor. When automation is not up to date with the codebase, it becomes a release gate, and manual regression grows to fill the time until the next release.
Shift-left practices are practices that shift that work earlier. Testers participate in refinement, acceptance criteria are documented as concrete examples that become tests, and developers’ unit and integration coverage. The most common anti-pattern is suites of brittle end-to-end UI tests, and a 10-minute pipeline isn’t possible.
Flaky tests are worthy of special mention. Each time a red build occurs without explanation, the engineers learn to re-run it until no one believes a failure. Fast teams quarantine flaky tests, assign an owner and resolve or remove the test within a specified time frame. Risk-based testing reduces effort even more: a change to a settings page does not require the regression run to be performed as does a change to a payments change.
Capacity is the remaining problem. When product scope outgrows the in-house QA team, the options are hiring, upskilling developers, or bringing in external specialists, where time-zone overlap, regulated-domain experience, and the ability to work inside the team’s pipeline matter most. Aerospace and defense projects around Huntsville or healthcare systems in Birmingham often shortlist from lists like the top software testing companies in Alabama rather than accept overnight feedback loops from offshore vendors.
Sustaining Speed Without Trading Away Stability
As well as tooling, decision rights are important. If routine changes must be approved by the committee, then the committee will be the lead time. Most compliance requirements are met with automated checks with an audit trail, and only the really risky changes are left for human review.
Frequent releases are psychologically safe because they are observable and rollback can be done quickly. The engineers will be deployed on a Friday when they will be alerted to the regressions and when they will be reverted.
Pace is an engineering issue, too. The speed of delivery, based on overtime and heroics, comes to a halt the first time the key person is gone.
Conclusion
Choose the slowest point on the value-stream map and correct this quarter. If PRs wait days, make a ground rule about how long it will take for them to review. If regression occurs in a week, quarantine flaky tests and trim end to end suite. Then re-draw the same flow as this will often reveal the next queue.