Why Agile ceremonies can grow yet software delivery gets worse

A team can look more agile while shipping less reliably

A CTO can see healthier charts of estimated work completed while software releases become less dependable. Jira, a delivery timeline relabeled as a sprint, a short development cycle, and a calendar full of ceremonies give management a visible process. Delivery capability needs different evidence: ideas reaching production sooner, usable builds, and releases that need fewer emergency repairs. Those outcomes should guide the next investment.

An unnamed practitioner writing under the title Agile SDLC: How It Actually Works (and Where It Breaks) calls this failure cargo-cult agile, including the variant Martin Fowler calls flaccid Scrum. Scrum organizes work into repeated development cycles, but meetings can continue while code quality, build reliability, and release predictability decline. The practitioner compares cowboy development, cargo-cult agile, and functional agile to separate engineering practice from ceremony. Engineering habits make releases dependable; frameworks help people organize that work.

Make completion and ownership explicit

To examine those habits, start with the work, the person accountable for it, and the conditions for completion. A sequential waterfall lifecycle begins with extensive documentation and moves toward one large release. An agile software development lifecycle, or SDLC, develops and delivers smaller increments repeatedly. The practitioner organizes that work into six operational phases, with iteration and construction recurring every two weeks.

These phases make responsibility visible across the lifecycle. The Scrum Guide calls Scrum’s activities events, while this model groups work by its accountable owner and expected output. Each owner determines completion at the project-team level, and phases can overlap. The model also makes continuous integration (CI), which means building and testing changes as developers merge them into a shared codebase, an explicit part of delivery.

Unclear completion standards cause problems at both ends of this lifecycle. The practitioner describes “Sprint 0” stretching into six sprints as preparation continues without a delivery cadence. At retirement, a “we’ll get to it” approach leaves a zombie service consuming attention. Starting and ending work both need an owner who can decide when the necessary conditions have been met.

Within that lifecycle, each iteration begins by choosing work the team can complete. The practitioner favors conservative commitments over those inflated by PM pressure. A fifteen-minute daily stand-up then lets colleagues expose blockers and coordinate their planned work. But turning it into an upward status report weakens the coordination it was meant to provide.

Coordination helps when it supports a clear development sequence: code, review, test, and integrate. Automated tests on every commit give developers feedback while a change is still small enough to investigate. Without that feedback, quality assurance (QA) finds surprises late, even after the team has spent time on all its ceremonies. The sprint review should therefore demonstrate working software and clearly identify what has been released and what remains in progress.

The retrospective applies the same completion discipline to improvements in how the team works. Participants identify successes, failures, and changes to make, then assign feasible actions to people with the authority to carry them out. An unowned action is unlikely to happen, and repeated inaction creates cynicism. Discussion leads to change only when someone can alter the conditions being discussed.

Authority matters equally in product ownership and production feedback. A product owner (PO) who cannot make trade-offs becomes a channel for demands, while a proxy can filter customer feedback before it reaches decision-makers. Production monitoring also needs an owner who can use its findings to change the backlog. CI improves technical feedback, but decisions still require people empowered to act.

Measure delivery before investing in more process

Accountable work gives a team a functioning process; delivery results show whether it is improving. The practitioner illustrates the difference with a constructed organizational example: an expensive consultancy introduces the Scaled Agile Framework, or SAFe, to 200 engineers across twelve product teams. The framework adds coordination, yet the organization’s ability to release software deteriorates. Leaders see the problem only when they compare process activity with delivery outcomes.

In the practitioner’s example, six months into the rollout, Program Increment Planning, a shared planning event for the teams’ next period of work, takes place every ten weeks. All twelve teams spend two days together, in a room or on Zoom, mapping dependencies, updating program boards, and voting on confidence in the plan. Velocity charts and burn-down reports, which show work completed or remaining, give the CTO encouraging management reports. Delivery measures tell a different story.

The example’s underlying failure is the lack of CI beneath the expanded planning process. Teams have more ways to coordinate, but code remains difficult to combine, test, and release. So a rollout can produce healthy-looking reports alongside worsening delivery. Leaders need to measure the development system’s output before treating coordination activity as progress.

Velocity is easy to confuse with progress because it counts estimated work completed within a sprint. When management makes velocity a target, the practitioner describes teams padding estimates, weakening its value for planning. More completed tickets can then appear to signal improvement while usable software still waits to reach users. Keep velocity as an internal planning aid and measure delivery separately.

Separate delivery measures also make the next investment easier to choose. The practitioner recommends gathering at least six weeks of baseline data before adopting a scaling framework. Monthly or less frequent deployments, or a change fail rate in double digits, point first toward CI, automated tests, and trunk-based development: frequent integration into the main shared code branch. These rules direct investment toward the technical conditions limiting delivery.

The baseline can reveal a different problem when teams deliver well individually but repeatedly block one another. They may need clearer interfaces, shared priorities, or coordination across dependencies. Measuring before a rollout helps distinguish that situation from unreliable integration, since each problem calls for a different use of people, time, and budget.

For the baseline, the practitioner identifies DORA’s research at dora.dev as the strongest available evidence base and recommends its five software delivery performance metrics. The measures cover the movement of changes into production and the work caused by failed changes. The practitioner uses “Instability and instability” for the groupings, throughput and instability in the diagram description, and Instability for all five entries in the metric table.

Using these measures over time means tracking changes in DORA’s definitions and benchmarking. Recovery measures now focus on failed production changes, while deployment rework identifies incident-driven work. DORA has also changed how it groups teams for comparison. These updates affect what an older dashboard measures and which teams offer a useful benchmark.

The seven archetypes come from cluster analysis, a method that groups teams with similar measured characteristics. The practitioner describes the inputs as Instability, stability, and team well-being data. Choosing a relevant archetype therefore means looking beyond deployment frequency to the broader conditions under which a team delivers.

AI adoption makes those conditions more important because additional code creates more work to validate and integrate. DORA’s 2025 research found that 90% of surveyed technology professionals used AI at work. The reported findings associate adoption positively with Instability and product performance, using the practitioner’s terminology, while showing a negative relationship with delivery stability among teams lacking strong automated testing and fast feedback. These findings describe associations between adoption and outcomes.

Subsequent DORA analysis also associates greater AI adoption with increases in both software-delivery Instability and instability. The practitioner interprets this as amplification of existing engineering strengths and weaknesses. For leaders expanding AI-assisted development, the immediate question is whether testing and integration can handle the additional changes. Faster code generation exposes weaknesses in those systems sooner.

Even a strong delivery system measures only part of the path to a useful product change. Idea-to-customer cycle time covers prioritization, preparation, development, and release, including waiting before a code commit. Tracking that broader interval alongside DORA’s measures helps locate delays in engineering execution, decisions, or handoffs. A shorter committed-code interval can otherwise conceal a long wait elsewhere.

Once a change reaches customers, product outcomes establish its usefulness. Activation, retention, customer satisfaction, and other outcomes relevant to the product answer questions that delivery measures leave open. Faster and safer releases let teams learn and respond, while product measures show the effect of what they release. The practitioner’s recommendation to implement DORA’s five measures “this quarter” gives leaders a bounded next step: establish the baseline, pair it with product outcomes, and use the results to choose the constraint to address.

Strengthen the engineering practices behind each iteration

When the baseline reveals unreliable integration or late defect discovery, the next investment belongs in engineering practice. The practitioner identifies five foundations: CI, testing at several levels, selective test-driven development, short-lived branches, and continuous refactoring. Together, they make the expectation of “Working software at the end of every sprint.” achievable through the way developers handle each change.

CI begins with every commit to the main branch triggering a build and an automated test suite. A failed build takes immediate priority because further changes would increase the work needed to restore a usable shared state. Developers get feedback as changes enter the common codebase. Repeated building and checking also give the sprint review dependable software to demonstrate.

The test suite needs several levels of checks because different tests catch different failures. The practitioner recommends unit tests for individual pieces of logic, integration tests for interactions, and a small set of end-to-end and user acceptance tests for broader behavior. These checks should detect meaningful defects quickly enough to guide development. A coverage percentage alone shows how much code tests exercise; it does not establish whether they protect behavior users depend on.

Fast checks bring QA decisions into everyday development. Developers can correct a defect while they still understand the change and before later work depends on it. Broader acceptance checks remain useful, but they build on feedback already received during implementation. This reduces the late surprises that arise when most testing waits until development has finished.

Test-driven development (TDD), which starts with a test written before the behavior it checks is implemented, can strengthen that feedback for selected work. The practitioner recommends it particularly for non-trivial logic, where defining expected behavior first can improve design and protect quality under delivery pressure. Developers still need to judge where that sequence helps, since a universal mandate would discard the recommendation’s selectivity.

Branching practices determine how much change accumulates between integration checks. Trunk-based development and very short-lived branches keep the interval small, while long-lived feature branches allow independently developed changes to build up. Combining those larger changes becomes harder at scale. The practitioner cites Martin Fowler’s source-code branching patterns in support of frequent merges that keep integration work small and continuous.

Frequent integration is easier when the code remains understandable. The practitioner recommends refactoring, improving code structure while preserving its behavior, as part of each story, including cleanup of the code being changed. Deferring that work to a periodic “tech debt sprint” allows technical debt, the accumulated burden of earlier shortcuts, to make later changes harder. The practitioner describes a failure pattern in which cycle time doubles and then triples as that debt grows.

Continuous cleanup connects daily implementation to the Agile Manifesto’s ninth principle, which concerns technical excellence and good design. Responding to changing requirements and delivering working software frequently both depend on code remaining practical to change. A maintainable codebase, fast tests, and reliable integration let teams fulfill the commitments their frameworks help them coordinate. Other teams and product leaders can then plan around a credible delivery cadence.

Choose coordination that matches the dependencies

Once engineering foundations are understood, framework choice becomes a question of what people need to coordinate. The practitioner compares Scrum, Kanban, Extreme Programming, Lean Software Development, and SAFe by their objectives, suitable settings, and weaknesses. Each organizes work differently, so the choice should follow the team’s conditions. Added process complexity earns its place only when it solves a coordination problem.

Teams can also combine practices from these approaches. XP’s pair programming, in which two developers work together on code, TDD, and CI can operate within another planning structure. A team can therefore improve its engineering habits while keeping a useful way to organize work. Kanban’s limits on simultaneous work can likewise address flow problems within an adapted process.

Adaptation is already widespread in Digital.ai’s 18th State of Agile Report, identified with its 2025 findings. Digital.ai has a commercial stake in agile adoption, and its report says 74% of organizations use hybrid, blended, or homegrown agile models. The practitioner similarly observes teams combining planning structures with engineering and flow practices suited to local constraints. Each organization still needs to judge whether its combination improves delivery.

At larger scale, coordination can justify substantial overhead. The practitioner typically encounters SAFe where twenty or more teams share a roadmap and substantial dependencies, and describes it as program-level risk management requiring serious leadership investment. Digital.ai’s 2025 report puts SAFe adoption at 44% among organizations using a scaling framework. That figure measures adoption within the scaling-framework group.

Smaller dependency networks can use a lighter structure. For more than three teams working on related systems, the practitioner recommends considering a few cross-team rituals, a weekly architecture sync, a shared roadmap, clearly owned interfaces, and explicit responsibility for requirements and goals. In the practitioner’s experience, this arrangement usually works better in organizations with 100 to 500 engineers. Actual dependencies determine which coordination mechanisms the organization needs.

Team count helps begin that assessment when considered alongside dependencies. The practitioner’s guidance distinguishes small-team collaboration, deliberate coordination across several teams, and the conditions that may justify a scaling framework. Leaders can use the ranges as a starting point, then examine where work actually blocks. The aim is enough coordination to resolve those blocks.

Adapt participation to the work and the team

Coordination also has to fit the demand arriving at a team. Platform teams, SRE rotations, and support engineering often handle work that resists a sprint cadence, so the practitioner recommends Kanban as an alternative. Limiting work in progress helps organize continuous demand without fitting every item into a fixed iteration. The team still needs a planning rhythm to prevent drift.

Geography changes how planning and coordination should happen. For teams spanning three time zones, the practitioner recommends asynchronous-first collaboration, sharing information without requiring everyone to participate at the same time, so meeting availability does not give one location control over decisions. Slack supports written updates and lightweight coordination, while documents and recordings let colleagues participate at different times. For these alternatives to work, information must be prepared and shared in forms others can use independently.

Participation across locations also depends on how the organization treats contributors. Nearshore and external partners should share the team’s ceremonies, backlog, and ownership so they take part in the same decisions and responsibilities. Shared membership preserves context as work moves among contributors. Treating partners as outside recipients of tasks creates handoffs where both context and accountability can disappear.

Design the lifecycle around regulatory and commercial constraints

Some constraints reach beyond collaboration and determine how software can be accepted or released. Safety-critical embedded systems in medical devices, aviation, and automotive products, along with FDA Class II and Class III products and audit-graded work, can require verification and validation beyond a two-week sprint. Verification checks whether the system meets its specified requirements; validation checks whether it serves its intended use. Teams can develop iteratively while completing those obligations, so production release frequency alone gives an incomplete view of their success.

These obligations shape how leaders apply the practitioner’s first investment question: can the organization deliver working software at least every two weeks? Interpret that cadence within the safety and commercial conditions governing the work. When teams cannot produce working increments, inspect CI, testing, and branching before purchasing another framework. Release approval may take longer even when the engineering team can produce usable software regularly.

Commercial agreements create another boundary. Under fixed-scope, fixed-price contracts, teams can iterate within the agreed envelope, but scope and price limit their decisions. An explicit hybrid makes those limits visible during development planning and acceptance. The Agile Manifesto favors changing requirements and frequent working software while leaving room to design a lifecycle for the commercial and regulatory setting.

Making those limits visible answers the practitioner’s remaining lifecycle question: which requirements must the process accommodate? Verification and validation obligations may require specific acceptance steps, while fixed-price commitments establish commercial boundaries and dependencies may require shared planning. Leaders should choose the least overhead that satisfies those conditions. Engineering practices improve execution within that design, while coordination and authority address decisions that code and tests cannot resolve.

A deliberate hybrid differs from Water-Scrum-fall in how it handles those boundaries. Water-Scrum-fall surrounds iterative development with extensive upfront planning and heavyweight release controls, adding agile overhead while preserving a slow release calendar. A deliberate hybrid identifies which steps must remain constrained and explains why. This makes the remaining decisions visible, giving the team a clear basis for improving the parts of the lifecycle it has authority to change.

Final thoughts

An agile process earns its cost when it helps teams deliver useful software reliably. More ceremonies, higher velocity, and detailed program boards do not establish that result. Leaders need evidence that changes reach production sooner, releases require less repair, and customers benefit from what ships.

Start with a delivery baseline, then identify where work waits or fails. Unreliable builds and late defect discovery call for investment in integration, testing, and maintainable code. Repeated blocks between otherwise capable teams call for clearer interfaces, shared priorities, and coordination. Delayed decisions call for owners with the authority to make trade-offs. These problems require different investments.

Choose the lifecycle around those findings and the constraints the business must meet. Regulatory obligations, commercial commitments, and shared dependencies can justify additional steps, but each step should have a clear purpose and an accountable owner. The executive responsibility is to fund the capabilities that improve delivery and remove process that consumes time without improving the result.