We've worked with engineering teams running every flavor of agile — Scrum, Kanban, SAFe, "ScrumBan," and home-brewed combinations. Some ship great software. Most don't. The pattern we've seen: teams that ship well share four or five concrete practices, regardless of which agile framework they claim. Teams that ship poorly are usually doing every ceremony in the textbook and still missing deadlines.
This is the field guide to what actually works. It's opinionated. If you're holding a CSM certificate, some of this will sting.
What does "agile that works" actually look like?
An agile process that works ships small, working changes to production frequently — usually multiple times per day. It optimizes for short feedback loops, trunk-based development, and team autonomy. It treats ceremonies as a means, not an end. Most teams calling themselves agile are running scheduled ceremonies without the underlying delivery practices that make agile actually agile.
Watch first: the Spotify model and what it really teaches
Before the patterns, watch Henrik Kniberg's "Spotify Engineering Culture" — the most-cited and most-misunderstood agile case study of the last decade. The lesson most teams take from it ("squads and tribes!") is wrong. The real lesson is the principles: aligned autonomy, trusted teams, failure recovery over failure avoidance. Frameworks are downstream of culture.
Why most "agile" doesn't ship
Three patterns we see in struggling teams:
- Two-week sprints with one-week planning. By the time sprint planning, refinement, retro, and review take their toll, half the sprint is in meetings. Net productive time: 3-4 days per developer per fortnight. The team feels "agile" because they're moving sticky notes; they're shipping a feature a month.
- Story points as currency. Teams negotiate scope by haggling 5-point vs 8-point estimates. The estimate isn't accurate at either resolution. Time spent estimating is time not spent building.
- Sprint commitments treated as contracts. The team promised 40 points; they delivered 32. Retro becomes blame analysis instead of process improvement. Predictability becomes more important than learning. Original agile killed this dynamic — modern Scrum reintroduced it.
The 5 practices that actually correlate with shipping
From the State of DevOps reports (now Google DORA) and our own production experience:
1. Deploy frequency > sprint frequency
Elite-performing teams deploy on demand — multiple times per day. High-performing teams deploy weekly. Mediocre teams deploy monthly. There is no correlation between "doing Scrum" and deploy frequency; there's a strong correlation between deploy frequency and business outcomes.
If your sprint is two weeks and you deploy at the end, you're not agile — you're doing two-week waterfall. Real agile teams break the sprint/release link entirely. Ship when something's ready.
2. Trunk-based development
Long-lived feature branches are agile's slowest poison. They look productive — work is happening! — while merge conflicts pile up and integration becomes a separate engineering exercise that takes days. Trunk-based development with feature flags removes the entire problem.
Practical rule: branches live under 48 hours. Anything that takes longer ships behind a feature flag, hidden until ready. If your team's branches live for weeks, the bottleneck isn't agile — it's branch strategy.
3. Daily standups (only if they take 5 minutes)
The standup has one purpose: surface blockers. It should take 5-10 minutes max. The format that works: each person says what they're blocked on. That's it. "What I did yesterday" is what your commit history is for. "What I'll do today" doesn't need group approval.
Standups that drift past 15 minutes are status meetings in disguise. Either fix them or kill them — the team isn't broken; the meeting is.
4. Continuous integration that actually integrates
"CI" means every commit gets merged to main and tested. Most teams have "CI tools" running tests on branches. That's automated testing, not continuous integration. The agile-original meaning was: integrate the codebase continuously so problems surface in hours, not weeks.
You can't trunk-based-develop without real CI, and you can't ship daily without trunk-based development. This is the unbroken chain that 90% of "agile" teams skip.
5. Small teams with autonomy
Teams of 4-7 engineers with end-to-end ownership of a slice of the product ship faster than teams of 15 broken into specialized roles. Conway's Law applies: your architecture mirrors your team structure. Want a modular system? Build modular teams.
For early-stage teams, this is easier — small by default. For scale-ups, the trap is hiring fast and keeping the team monolithic. Split before the team hits 9, not after.
The patterns to drop (agile theater)
| Practice | Why it doesn't work | What to do instead |
|---|---|---|
| Story points | Estimating is the work; you do it anyway | T-shirt sizes (S/M/L) for capacity planning; nothing for tracking |
| Sprint commitments | Discourages learning, encourages padding | Cycle time as the metric — how long from "started" to "deployed" |
| 2-hour sprint planning | Plans go stale within days | 15-minute weekly check on direction; daily decisions are the team's |
| Backlog refinement as a separate ceremony | Refining items you'll never build wastes time | Just-in-time refinement — refine when you're about to start |
| Sprint reviews with demos | Demos are for stakeholders, not the team | Ship the feature; let it speak for itself. Async loom for stakeholders. |
What we run on actual projects
On RankLoop — a Rails SaaS we built and operate — the process looks nothing like textbook Scrum:
- Weekly cadence: Monday morning, 30-minute "what are we building this week" call. That's the only planning meeting.
- Daily async check-in in Slack: each engineer writes one line on what they're blocked on. No video standup.
- Trunk-based development with feature flags. Branches under 24 hours. Multiple deploys per day.
- Bi-weekly retro: 30 minutes, three questions ("what worked, what didn't, what to change"). Action items are 2-3 max.
- No story points. No velocity tracking. We measure deploy frequency and incident rate.
This works because the team is 4 senior engineers who've all worked together for years. The overhead a 20-person team needs would crush a 4-person team. Pick the process to fit the team size, not the other way around.
When you DO need more process
Process exists to coordinate uncertainty. As team size and external dependencies grow, you genuinely need more of it:
- 4-person team: almost no formal process. Shared context, fast communication.
- 10-person team: introduce explicit planning cadence, written tech docs, on-call rotation.
- 25-person team: split into 3-4 sub-teams with autonomous decisions, lightweight architecture reviews, written RFCs.
- 50+ engineers: formal product management, SRE function, internal platform team, structured promotion process.
The mistake we see: 6-person startups running 50-person-company process. The ceremonies were invented to coordinate teams that need coordination. Small teams that adopt them prematurely get the cost without the benefit.
What this means for outsourced/dedicated teams
If you're hiring an agency or dedicated developers, the right process question isn't "do they do Scrum." It's: "How often do they deploy? How long do feature branches live? What's their incident response process?" Those answers tell you whether they're shipping or performing.
The same calculation applies to picking a tech stack — see our MVP development guide for the tech-side of "what actually ships." And if you're choosing between an internal team and an agency, our technical debt vs feature velocity writeup covers the trade-off most teams get wrong.
External references worth reading
- The Agile Manifesto — 12 principles in a couple of paragraphs. Re-read it; you'll realize most "agile" practices contradict it.
- Atlassian — Agile Coach — comprehensive practitioner guide. Skews toward Scrum but covers Kanban and team practices well.
- Spotify Engineering Culture (original blog post) — the source for the famous video. Worth reading the caveats Kniberg himself added later.
FAQ: Agile methodology
What is the difference between Agile and Scrum?
Agile is a set of principles (the Manifesto, 12 principles). Scrum is one specific framework that implements those principles via roles, ceremonies, and artifacts. You can be agile without Scrum; you can do Scrum without being agile. Most teams running "Scrum" are running Scrum theater — the ceremonies without the underlying delivery practices.
Should small startup teams use Scrum?
No. Scrum's ceremonies were designed for teams of 7-9 with coordination needs that a 4-person startup doesn't have. Run a weekly direction check, daily async standup, bi-weekly retro. Skip everything else. You can graduate to more process when the team hits 10+ engineers.
What's the most important agile practice?
Short feedback loops. Everything else flows from that — deploy daily, trunk-based development, real CI, small teams. If you do those four things, the framework you call it (Scrum, Kanban, XP) doesn't matter. If you don't do those four things, no framework will save you.
Are story points useful?
For coarse capacity planning at a 10+ engineer scale, t-shirt sizes (S/M/L) are useful. For tracking velocity, no — velocity is a vanity metric that incentivizes padding estimates. Measure cycle time (start-to-deploy) and deploy frequency instead. Those numbers map to actual business outcomes.
What is the DORA framework?
Google's DevOps Research and Assessment program measures team performance via four metrics: deploy frequency, lead time for changes, mean time to recovery, and change failure rate. Decades of research show these four metrics predict business outcomes better than any agile-process measurement. If you measure one thing, measure deploy frequency.
How we can help
At TechVinta, we embed senior engineers into client teams and run our own internal projects on the same process described above — short cycles, trunk-based development, multiple deploys per day. We've helped teams transition off heavyweight Scrum into something that actually ships. Most of our engagements include process work alongside the engineering.
Engineering team stuck in agile theater, or hiring a team that ships fast? Talk to our team about dedicated engineers or get a free estimate — we'll review your team setup and propose a plan within 48 hours.
