It was never there. And if it had been, I’d have dissolved it on day one.
How I run my mega one-person enterprise — without Scrum Masters, daily stand-ups, or agile theater
I run what some would call a software company.
On paper, it’s a complete organization with:
- a developer,
- an architect,
- a product owner,
- a DevOps engineer,
- and even a quality manager.
In practice, all of that is me.
And I have a dog who barks at every deployment — probably my only truly engaged stakeholder.
Everyone says you need an agile team to build anything serious — a Scrum Master, a Product Owner, a few meetings to prove you exist.
I considered playing all those roles myself — Scrum Master on Mondays, PO on Tuesdays, Agile Coach on Wednesdays…
**Then I realized: none of these roles sh…
It was never there. And if it had been, I’d have dissolved it on day one.
How I run my mega one-person enterprise — without Scrum Masters, daily stand-ups, or agile theater
I run what some would call a software company.
On paper, it’s a complete organization with:
- a developer,
- an architect,
- a product owner,
- a DevOps engineer,
- and even a quality manager.
In practice, all of that is me.
And I have a dog who barks at every deployment — probably my only truly engaged stakeholder.
Everyone says you need an agile team to build anything serious — a Scrum Master, a Product Owner, a few meetings to prove you exist.
I considered playing all those roles myself — Scrum Master on Mondays, PO on Tuesdays, Agile Coach on Wednesdays…
Then I realized: none of these roles ship code. So I never hired them.
And since then… everything just works.
No meetings. No ceremonies.
Just code, decisions, and a bit of thinking before acting. Oh, and coffee — coffee is key.
💡 This article is the logical follow-up to Actually Agile: Against Performance Theater in Software Development, where I explained why Agile has become theater. Here, I show how I apply this criticism in practice. Because between the two, I found nothing better than laziness. But well-thought-out laziness.
🧩 When Agile Replaced Thinking with Ritualization
I have nothing against agile methods. On the contrary, I believed in the original idea: breaking free from useless constructions to talk to customers, pivot, and communicate.
But after watching teams spend more time talking about agility than shipping code, I finally understood:
we had replaced thinking with ritualization.
The most cynical part? Even the creators of Agile say so.
Following my previous article, Toby Farley — one of the earliest signatories of the Agile Manifesto (March 2002) — validated this observation:
“As an early signatory (March 2002), I have watched the entire descent into the Seventh Circle of Agile. We never adopted anything beyond what the document says. We just DO it. It doesn’t require any of this scaffolding to be agile. That was the whole point! We were trying to break free of the useless constructions that hampered what we wanted to build. We wanted to talk to customers, pivot when needed, discard what wasn’t working and communicate at every level all the time. What is now called agile is the opposite of what was intended; it is dystopian.”
Toby Farley co-created Agile. And he says it’s become dystopian.
The circle is complete.
Daily stand-ups that only serve to repeat what we did yesterday.
Sprint plannings where we “estimate” tasks we’ll never do.
Retrospectives where we note the same problems for six months without changing anything.
In short, theater. And I left the stage.
🔥 What I Eliminated (And Why)
Here’s the list of rituals I eliminated without the slightest regret.
And no, the world didn’t collapse.
- Daily stand-ups → I know what I’m doing, thanks. And if one day I don’t remember what I did yesterday, it’s Alzheimer’s, and 15 minutes of standing theater won’t save the project. Nor me, in the end.
- Sprint plannings → I plan when I need to, not Monday morning. Otherwise, I risk spending the week waiting for the next Monday’s planning.
- Backlog grooming → my backlog fits on a single post-it — or doesn’t exist at all.
- Velocity tracking → I deliver when it’s ready, not when the sprint ends.
- Story points → 1 = it’s doable; 0 = don’t bother.
Result:
✅ 0 hours of meetings per week ✅ 40 hours of real development ✅ Continuous delivery, without useless ceremonies ✅ Only one ceremony maintained: the coffee ritual (Neapolitan coffee maker required).
And above all: never again that feeling of running after a method supposed to make me faster. Besides, I have a treadmill, but I don’t use it either: I already run enough after my dog when I walk him.
🧠 Efficient Laziness – My Real Driver
I’m not productive. I’m lazy, but efficiently so.
Efficient laziness is refusing to confuse movement with progress.
It’s the chemist’s laziness: the one who spends two days setting up a complex experimental apparatus... to manipulate only once instead of twenty times.
He doesn’t do less work. He does the right work, once.
While his colleagues repeat the same manipulation twenty times “because it’s faster,” he automates. He thinks. He builds.
And in the end, he saves two weeks.
That’s efficient laziness:
- Spending two hours automating a ten-minute chore
- Because I know I’ll do it twenty times
- And I prefer to think once rather than repeat twenty times
Inefficient laziness postpones everything until tomorrow.
My laziness builds systems that do the work for me.
The 4 Principles of My Efficient Laziness
- Think once, well. A good mental model is worth a thousand Jira tickets, which I won’t write anyway and therefore can’t read.
- Zero ceremonies, just decisions. Decisions are made in five minutes when you’ve thought about it beforehand over a good coffee.
- Automate rather than document. If something needs to be redone, I turn it into a script.
- Ship, observe, adjust. Running code is always right. The code, not the client.
This approach doesn’t save time on a sprint.
It saves time over an entire project.
🤖 The New Level of Theater: AI in Service of Process
As if agile processes weren’t enough, the industry found a fresh coat of paint: AI-powered bullshit.
“AI-assisted sprint planning” “LLM-based backlog grooming” “Automated standup summaries”
We take the same useless meetings, slap an OpenAI logo on them, and boom — we’ve “reinvented” productivity.
For my part, I use AI, of course. But not to replace thinking.
Only to accelerate tasks that don’t deserve human attention.
- Repetitive code generation? ✅ Of course.
- Log analysis? ✅ Sure.
- Structure brainstorming? Sometimes, yes, but only to feed my thinking from an initial idea. AI doesn’t think for me, it serves as my sparring partner.
- Sprint planning? Never.
AI didn’t kill Agile — it just gave it a mirror.
Truly useful AI is the kind that frees time to think better, not the kind that lets you pretend faster.
AI doesn’t make you agile. It only reveals how fast you’re running in circles. And still…
🧱 What If We Wanted to “Scale” This Efficient Laziness?
Yes, it’s easy when you’re alone.
But could this approach work with multiple people?
Definitely yes — as long as we don’t betray the basic principles:
- Small teams (3 to 5 people max)
- Clear responsibility
- Minimal process
- Real autonomy
If I were to hire tomorrow?
I wouldn’t look for “a senior developer who knows Scrum.”
I’d look for “someone who, when I give them a problem, comes back 3 days later with a working solution — not a sprint plan.”
Someone who:
- Thinks before coding
- Automates what’s repetitive
- Doesn’t need to be told what to do
- Communicates when necessary (not at 9 a.m.; that’s coffee time)
What if there were 5 of us like that?
We wouldn’t need a Scrum Master (everyone self-organizes).
We wouldn’t need a PO (everyone understands the problem).
We wouldn’t need dailies (we talk when it’s useful).
The problem isn’t scaling.
It’s hiring people who NEED to be managed.
The problem has never been team size.
It’s the complexity we add to compensate for it.
Every new layer of validation, every “facilitator” role, every tool meant to simplify... ends up slowing everyone down.
Companies think they’re “scaling agility” when they’re scaling theater.
🧡 My Own “Rituals”
I don’t have daily stand-ups.
But I have questions I ask myself regularly:
- Why am I doing this? (really)
- What’s the simplest way to test this idea?
- What can break?
- Can I automate it?
And at the end of the week:
- What did I learn?
- What slowed me down?
- How can I avoid that next time?
And I have ONE real stakeholder: my dog.
His requirements are clear:
- No deployments during nap time (2pm-4pm)
- Non-negotiable walks (when he decides)
- Bugs that make noise are critical blockers
Honestly? Better product management than most POs I’ve encountered.
At least he’s honest about his priorities.
No need for post-its to remind me to read other post-its, sprint reviews, or retrospectives.
Just a bit of honesty and perspective.
🚀 Conclusion – Real Agility, Not Staged
My “enterprise” has no Scrum Master, no Product Manager, no ceremonies.
Yet I’m more agile than most agile teams.
Not because I’m exceptional. (Although... but that’s not for me to say.)
But because I’ve eliminated everything that hinders agility:
- Meetings that annihilate thinking
- Processes that replace decisions
- Roles that replace accountability
Efficient laziness isn’t a method, it’s what remains when you stop performing theater and finally get down to serious work.
Think once, well. Ship. Learn. Repeat, but not for nothing.
That’s all. And it’s largely sufficient.
No need to do more, or pretend to do more.
The rest is theater.
💬 Two Questions for You:
For those in teams: Have you seen an organization (5+ people) shed the agile theater? How did they do it? 1.
For solos/small teams: Do you practice this “efficient laziness”? What did you eliminate first?