Why don't you use Agile?

Because Agile was built for large teams - the Agile Manifesto addressed miscommunication and rigid process across big organizations. Its ceremonies make sense with 8 to 12 engineers plus PMs, designers, and QA. For a fixed-scope project where people can just look or ask, those ceremonies are overhead that eats roughly 4 to 5 percent of engineering time.

What do you do instead of Agile?

Fixed scope and fixed price defined by a detailed written spec that acts as the contract, weekly demos instead of daily standups, detailed written specs instead of vague user stories, and shipping working features to staging every Friday. For internal communication, async messages replace scheduled ceremonies.

When does Agile actually make sense?

When your team is 8 or more people across multiple functions, when requirements are genuinely unknown and evolving weekly, when you have a dedicated product manager whose full-time job is prioritization, and when you're building a product you'll maintain for years rather than a fixed-scope project. For a fixed-scope project, its ceremonies are overhead.

Process

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

Not Scrum. Not SAFe. Not whatever certification LinkedIn is selling this week. Here's why most delivery teams don't need Agile frameworks — and what actually works.

March 7, 20263 min readProcess

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 our engineers work a focused scope in one 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 costs a product engineering team:

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:

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. See how this process applies to MVP development and AI app rescue.