Most founders learn about Agile like it’s a law of physics. There are sprints, there are standups, and if you’re not doing both, you’re doing it wrong. That’s not how software actually gets built.
Why Agile Became the Default (and Where It Breaks)
Agile was a 2001 manifesto written by developers tired of waterfall, which the old model where you planned everything up front and shipped a year later. Its core insight: ship small things often, talk to users, adjust. Genuinely good advice.
The problem is what came after: an entire industry of certified Scrum masters, complex Jira configurations, and bi-weekly sprint ceremonies that turned a simple idea into a bureaucracy.
For a small startup or agency team, “doing Agile properly” often means spending more time managing the process than doing the work. You’re writing acceptance criteria for a feature that might not survive first contact with users. You’re running retrospectives for a sprint that produced half of what you planned.
The framework was designed for enterprise teams coordinating dozens of engineers. If you have four people, the math doesn’t hold.
Scrum vs. Kanban: What Actually Differs
Both fall under the Agile umbrella. They solve different problems.
Scrum is time-boxed. You commit to a set of work for a fixed period (a sprint, typically two weeks). At the end, you review, retrospect, and plan again. It works well when work comes in discrete, defined chunks: features with a clear start and end, and stakeholders who need to know what’s shipping this week. The overhead is real: sprint planning, daily standup, sprint review, retrospective. That’s four recurring meetings before a line of code is written.
Kanban is flow-based. Work items move through stages (To Do → In Progress → Done) and you limit how many things can be in progress at once. No sprints. No fixed commitments per cycle. It works well when work is continuous or unpredictable: support queues, maintenance, anything where priorities shift mid-week.
When Scrum fits
- Your team is building a product with defined features and a release cadence
- Stakeholders need a regular window into what’s shipping
- Your scope is stable enough that two-week planning isn’t pure guesswork
When Kanban fits
- Your work is reactive — bugs, client requests, content updates
- Your team is small (two or three people) and ceremony kills momentum
- You’re in maintenance mode, not active feature development
Neither fits perfectly when you’re early-stage and everything is in flux.
The “Make It Happens” Method
You have a list of things that need to get done. You look at it on Monday. You pick what matters most this week. You build it. You ship it. You update the list. You repeat.
I call it “make it happens.” It’s closer to Kanban without the theory — but naming it matters because it removes the guilt of not being “Agile enough.”
The practical structure:
- A single backlog. One list, roughly prioritized. Not organized by sprint, not grouped by epic. A list.
- A weekly check-in. Not a daily standup unless your team genuinely needs it. What shipped last week? What’s the plan this week? Are there blockers?
- A done column. Move finished work somewhere visible. This sounds trivial. It keeps teams sane and stakeholders from asking the same question twice.
- No perfect sprint planning. If a task bleeds into next week, it bleeds. The goal is working software, not clean velocity metrics.
The one rule that overrides everything else: if the process is taking more time than it saves, cut the process.
Skip the retrospective when there’s nothing to say. Delay standup until after someone finishes a critical PR. Close the Jira board and use a Notion page if that’s what your team actually opens. The tool is not the method.
The Mistake Business Owners Make with Process
Founders who hire their first developer tend to do one of two things: enforce full Scrum (“I read about it, let’s do it”) or do nothing (“just tell me when it’s done”).
Both create problems. Full Scrum without organizational maturity burns time on coordination that a small team could handle with a five-minute call. No process creates invisible blockers — something is stuck for three days and nobody knew to ask.
The right level of process gives you two things: visibility and predictability. You need to know what’s being worked on and roughly when it’ll be done. Everything else is optional overhead until proven necessary.
If you don’t have visibility, add a lightweight board. If you don’t have predictability, add a weekly sync. If you have both and work is moving, don’t add more. Resist the urge to add process as a response to anxiety rather than an actual breakdown.
What to Do Next
Start by diagnosing your real problem.
- Work is invisible and you don’t know what anyone is doing. Do this: add a board with three columns
- Deadlines keep slipping with no warning. Do this: add a weekly fifteen-minute review
- Your team is drowning in meetings and velocity is suffering. Do this: cut a ceremony and see what happens
A good product team runs on a system simple enough that people use it, and the discipline to drop what stops working.
If you’re building a web product and want a partner who thinks about process the same way — pragmatic, no overhead for its own sake — let’s talk.