A logistics firm in Gurugram signs off the spec for a new dispatch system in April, and the vendor builds against it until December. The first time a dispatch manager clicks through it, she asks why the pin code rules are the ones from last year. Eight months of budget went into software nobody outside the project had touched, and the correction now costs far more than it would have in May. Agile is meant to prevent exactly this, yet plenty of teams that run sprints and daily stand-ups still end up in the same place.
What Agile Is Supposed to Buy You
The Agile Manifesto lists four preferences: individuals and interactions over processes and tools, working software over extensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The right-hand side still matters. We still write documents and we still sign contracts. The question is which side wins when the two pull against each other on an ordinary Tuesday, and in my view it should be the left.
For the person paying for the software, it comes down to two things. How soon does someone who will use the product see it working, and how cheaply can the plan change once they have? The two-week cycles, the task board and the meetings are machinery for getting good answers to those two questions. If the machinery runs and the answers do not improve, the money is going into ceremony.
The machinery has its own vocabulary, so here it is in plain terms. A sprint is a fixed cycle, usually two weeks, that ends with something a stakeholder can click or run. The backlog is the ordered list of work still to do, and the top of it is what gets built next. A stand-up is a short daily meeting where people raise whatever is blocking them. A retrospective is the meeting at the end of a cycle where the team decides what to change about how it works.
For the dispatch system, short cycles would have meant a first sprint that shipped one screen where a manager assigns a consignment to a vehicle. The pin code rules would have been corrected in week three, when the fix was a day's work, instead of month nine, when they had been wired into routing and billing.
- Requirements fixed up front
- Testing at the end
- First user feedback after launch
- Changing direction means rework
- Small slice planned each cycle
- Tested as it is built
- Feedback after every demo
- Next cycle reflects what was learned
The feature set is identical. What differs is when anyone outside the team sees working software.
Why Small Releases Are Cheaper to Fix
When a release carries two weeks of work and something breaks, there are perhaps ten things it could be. When it carries six months of work there are hundreds, and the developer who wrote the suspect code may have moved to another project. Small increments make defects cheaper to trace and wrong assumptions cheaper to find. They also let the business move a feature up or down the list without raising a change request and waiting for a fresh quote.
Demos matter for the same reason. People react to a working screen far more precisely than to a requirements document. The accounts head at a mid-size manufacturer will read a forty-page spec on invoice approvals and sign it. Put the approval screen in front of her and within a minute she will tell you the tax breakup sits in the wrong place, because her team checks it on every invoice before month-end.
Where Sprints Slide Back into Waterfall
Waterfall is the older way of running a project, where requirements, design, build and testing each finish before the next one starts. Most of the failed Agile adoptions I have seen are waterfall cut into smaller pieces. Design happens in week one, development in week two, testing gets squeezed into the last two days, and nothing is ready to show until the final afternoon. The board says Agile. The calendar says waterfall with a fortnightly deadline.
The backlog is the next giveaway. If nothing has been reordered or dropped since the first month, it is a frozen requirements list under a new name, and the team is building what someone wrote down before anybody had seen the product. Close behind is the demo with no real audience. If the people who will use the software never see the increment, the loop has not closed, however good the demo looked to the project manager.
Then come the meetings. Stand-ups turn into a daily status report for a manager instead of a place to raise blockers. Retrospectives produce a list and no changes, so the same complaint about the staging server comes up three sprints running. Releases stay manual, so the sprint closes on time while getting the build to users still takes two days of hand-run steps.
Most of this comes from adopting the vocabulary before the feedback loop. Jira, Trello and Azure DevOps make the backlog visible to everyone, and none of them makes anyone act on it. The first thing I look at on a new board is the date an item last changed position.
Who Pays When the Loop Breaks
Be honest about who carries the cost. It is rarely the team in the current sprint. It is the business, a few months later, in rework and a missed date that the MD had already promised someone. I put the open decisions in a table like this one when talking to founders and finance heads, because it turns process complaints into money and time.
| Decision left open | Who signs off | Cost of leaving it a month |
|---|---|---|
| Which screen real users see first | Product owner | The team builds the wrong thing first |
| Whether a user attends each demo | Business sponsor | Wrong assumptions survive two more cycles |
| Automating the release | Delivery lead | Cycles stretch quietly to avoid releasing |
| Acting on retrospective points | Team lead | The same problem costs another fortnight |
None of these needs a new tool or a certification. Each needs a name against it and a date by which it gets decided.
The Release Has to Be Cheap
If building and releasing is a manual job, the team will stretch the cycle to avoid doing it often, and nobody will say so in a meeting. A CI/CD pipeline, meaning the automated build, test and deploy steps that run on every change, keeps each release cheap enough that a two-week cycle stays two weeks. We treat the pipeline as sprint work with its own owner, not as a favour from the operations side. The way DevOps and development work fit together is worth reading if your releases still depend on one person's laptop.
- 01Plansmall slice, clear goal
- 02Buildtested as it goes
- 03Releaseautomated pipeline
- 04Showto real users
- 05Adjustreorder the backlog
Next cycle
If any step is skipped, the cycle stops producing information the business can use.
Testing follows the same rule. A cycle that ends with a week of manual regression checks is a long cycle pretending to be short. The shortcuts teams take to keep a fortnight on schedule also add up, which is how technical debt builds up in long-running projects without anyone deciding to take it on.
What I Check at a Sprint Review
- Does each item in the sprint end in something a user could try?
- Is at least one person who uses the product in the room, or on the call?
- Did the last review change the order of the backlog? If it did not, ask why.
- Does the sprint goal fit in one sentence?
- Is last time's retrospective action done, assigned, or dropped on purpose?
- Can the build reach a test environment without anyone running steps by hand?
A team that answers no to three or four of these is usually running sprint-shaped waterfall. The fix is rarely a new framework or another training course, and it does not need a reorganisation either.
What to Do on Monday
- Put the current build in front of one real user this week, even if that means a dispatch manager on a WhatsApp video call.
- Let what they say reorder the top of the backlog, and write down what moved and why.
- Put a date on automating the release, with one person's name against it.
- Pick one retrospective point from last time and close it before the next sprint starts.
The first item does the most work, because everything after it is a response to what the user said. Our own cadence, short cycles that each end with a release to staging, is set out in how we run projects, and the same review questions apply to it.
