"Software development is something very, very long-term. It is something very consistent; you shouldn't plan for the next month to come." – from the video
It hit me by the lake one evening. Calm water, sunset reflections, and this annoying voice in my head: "You’re not doing it right. Agile says... Scrum says... TDD says..." And for a second, I almost believed it again.
But then I remembered what building products really feels like: messy, chaotic, fast, and sometimes even reckless. And I asked myself – when did we decide that doing things by the book mattered more than actually making progress?
👉 Follow my short video feed on LinkedIn and YouTube.
How Dogma Creeps In
"All systems out there, which exist, methodologies or something like that, follow a specific purpose. What I want to do is understand the purposes behind that..." – from the video
As a founder and CTO, I've spent the last 15 years in startups, tech teams, and chaos. And here's what I know: the biggest trap we fall into is mistaking methodology for strategy. We fall in love with rituals, ceremonies, and diagrams. We forget to ask: "What problem are we solving right now?"
In one of my earlier ventures, I insisted we follow XYZ by the book. Burndown charts, daily stand-ups, and sprint rituals—the whole package—made me feel like we were a professional, organized, and serious team.
But we weren’t building faster. We weren’t solving the problems our users had. We were not performing software development; we were doing it.
The real wake-up call was that we delayed a key feature by six weeks because it didn't fit our current sprint planning cycle. A customer left, which hurt.
From Systems to Context
"Everyone should develop their own way of doing things. And to do that, you either need to make your own mistakes, or deeply understand the reasoning behind existing systems." – from the video
That’s when I stopped asking, “Which method should we follow?” and started asking, “Why was this method invented?”
I realized most methodologies came from large organizations with totally different problems: scale, coordination, and alignment, not speed, survival, or relevance.
The energy in a small startup is different. We need to learn quickly, act quickly, and sometimes fail quickly. Context is everything. The way you build in a five-person team is not how you build in a 50-person organization.
So instead of choosing a dogma, I began treating methodologies like toolboxes. Not prescriptions, but inspirations.
Sometimes we used Kanban. Sometimes we worked without any system for weeks, just shipping what mattered. And sometimes, yeah, we borrowed from Agile – but on our terms.
What I Learned
"As long as you stay in an iterative approach, which means that you're allowed to make mistakes because you can act on those, you're actually good to go." – from the video
Here’s what I came to believe, not from books, but from getting things wrong, missing goals, and learning fast:
Context matters more than method. Always ask: What’s the goal? What’s the constraint? What’s the urgency?
Dogma is dead weight. If you can't explain why you're using a system, you probably shouldn't be.
Speed is feedback. In startups, progress beats polish. Every delivery teaches you something.
Culture eats process. Teams that trust each other can work in chaos and still win.
Iteration is survival. Planning is guessing. Iterating is listening.
You don’t need permission to adapt. No one is watching, so you’re free to do what works for you.
Final Thoughts
I’m not here to burn the Agile manifesto or rewrite Lean Startup. I am a supporter of original Agile. 😀 But I'm here to remind you that your startup is truly unique. Your context matters. And if your intuition tells you a particular approach isn’t right, you’re probably right.
Progress isn't about being right; it's about getting better.
When a methodology is useful to you and you have understood it, that’s great. Use it as it fits your context.
Adrian
Share this post