Why We Don't Use Agile (And What We Do Instead)

This is going to be controversial. We don't do Agile. Not Scrum, not SAFe, not Kanban with a capital K, and definitely not whatever new certification LinkedIn thought leaders are selling this week.

Before the Agile coaches come for us: we're not saying Agile is bad. We're saying it's designed for a problem we don't have.

Agile Was Built for Big Teams

The Agile Manifesto was written in 2001 by 17 people who were frustrated with waterfall development at large organizations. The problems they were solving — miscommunication across large teams, rigid processes that couldn't adapt, documentation replacing actual conversation — are real problems. At scale.

Scrum ceremonies make sense when you have 8-12 engineers, a product manager, a designer, a QA team, and multiple stakeholders who all need to stay aligned. Daily standups exist because in a team of 10+, people genuinely don't know what each other is working on.

But we're a team of 3-5 engineers. We sit in the same room (or the same Slack channel). We know what each other is doing because we can just... look. Or ask.

The Overhead Problem

Here's what a typical Scrum implementation looks like for a small agency:

• •Daily standups: 15 minutes × 5 days = 75 minutes/week per person
• •Sprint planning: 2-4 hours every 2 weeks
• •Sprint review: 1-2 hours every 2 weeks
• •Sprint retrospective: 1-2 hours every 2 weeks
• •Backlog grooming: 1-2 hours every 2 weeks
• •Story point estimation: Scattered throughout

For a 5-person team, that's roughly 15-20 hours of ceremony per sprint. On a 2-week sprint with 400 total engineering hours, you're spending 4-5% of your time talking about work instead of doing it.

"But 5% isn't that much!" Maybe not. But for a client paying $15K for an MVP, that's $750 worth of meetings. And the indirect cost is worse — context switching between ceremonies and deep coding work fragments the engineering day.

What We Do Instead

### 1. Fixed Scope, Fixed Price

We don't estimate in story points. We don't have a product backlog that grows forever. Before a single line of code is written, we produce a detailed written specification that covers every feature, every screen, every edge case, and every exclusion.

This spec is the contract. It doesn't change mid-sprint. If the founder wants to add something, it goes into V2 with a separate scope and price. This sounds rigid, but it's actually liberating — everyone knows exactly what they're building and exactly what "done" looks like.

### 2. Weekly Demos Instead of Daily Standups

We replaced daily standups with one weekly demo. Every Friday, the client sees working software. Not a Sprint Review with velocity charts and burndown graphs. A URL they can click, test, and give feedback on.

For internal communication, we use async messages. If something's blocked, we say so in Slack — we don't wait for a 9 AM ceremony tomorrow.

### 3. Written Specs Over User Stories

"As a user, I want to log in so that I can access my dashboard."

What does that actually tell the developer? Nothing about:

• •OAuth vs email/password vs magic links
• •What happens if the user doesn't exist
• •Password requirements
• •Rate limiting on failed attempts
• •Session duration
• •Multi-device handling

Our specs are detailed documents that answer every question a developer might have before they start coding. This eliminates the back-and-forth that slows down Scrum teams.

### 4. Ship Every Friday

Not "increment the sprint counter." Ship to staging. Deploy working features. If something isn't ready by Friday, it ships next Friday — it doesn't get rushed out with bugs.

When Agile Makes Sense

We're not anti-Agile fundamentally. Agile frameworks make sense when:

• •Your team is 8+ people across multiple functions
• •Requirements are genuinely unknown and evolving weekly
• •You have a dedicated product manager whose full-time job is prioritization
• •You're building a product you'll maintain for years (not a fixed-scope project)

For a 3-5 person team delivering a fixed-scope MVP or web application, Agile ceremonies are overhead. Your process should be as lean as your team.

The Results

Our "no Agile" approach has delivered:

• •9 MVPs shipped in 5 weeks or less
• •Zero missed deadlines on fixed-scope projects
• •Client NPS consistently above 9/10
• •7 of 9 MVPs still in production with real users

The best process is the one you don't notice. It just works.

Want to see this process in action? Book a free scoping call and we'll show you exactly how we'd approach your project — no ceremonies required.