How I Think About Agile, Kanban, and the Rest
There’s no shortage of "frameworks" in product development. Agile, Scrum, Kanban, Shape Up, SAFe. The list goes on.
Each of them offers something. But none of them offer everything.
Over time, I’ve seen too many teams get stuck treating process as if it’s the work. They follow the steps, hold the ceremonies, tick the boxes. But something’s missing: Outcomes. Ownership. Judgment.
This post isn’t a teardown of process. It’s a reflection on how I’ve come to use frameworks in practice. What they’re good for, where they fall short, and why the most effective teams I’ve worked with treat methods as tools, not templates.
Agile is a philosophy, not a process
A lot of teams say “we do Agile” when what they really mean is “we follow Scrum.” Standups, retros, sprints, story points. But Agile, in its original form, isn’t a framework at all.
It’s a set of values. A manifesto. A response to heavyweight processes that were too slow and too rigid for real-world software work.
Agile is about adapting quickly, working closely with users, focusing on outcomes, and shipping iteratively.
Scrum is one way to approach that. So is Kanban. So is Shape Up. And so is whatever hybrid a thoughtful team puts together for themselves.
The mistake is treating frameworks as fixed systems. When process becomes the product, teams start measuring success by completion, not impact.
Delivery is only one part of product work
Good product work can be broken up into three parts:
- Strategy: deciding what problems to solve
- Discovery: exploring and validating possible solutions
- Delivery: building and shipping those solutions
Most delivery frameworks focus entirely on that last piece. And while structure and cadence are helpful, they can only take you so far. If you’re missing strategy, you risk building things that don’t matter. If you skip discovery, you risk shipping things that don’t work.
A team can sprint consistently, hit velocity targets, and still miss every opportunity to create value.
What I’ve seen that actually works
The best teams I’ve worked with aren’t the ones who followed a textbook. They’re the ones who stayed close to context. They chose their practices based on the team, the stage, and the problem in front of them.
In some cases, two-week sprints worked well. The rhythm helped us stay focused. In other cases, that same structure created unnecessary tension and encouraged shallow planning.
I’ve also worked with teams using Shape Up-style cycles. The longer blocks gave us time to breathe, but they only worked when paired with strong upfront shaping and a clear appetite for the work.
And then there were times, especially earlier in my career, when I got too caught up in process itself. I spent time designing clean systems, structuring ceremonies, and setting up beautiful flows of work. On paper, it was elegant. In practice, it was friction.
We had discipline. We had structure. But throughput was sluggish, and outcomes were nearly impossible to measure. The process looked right, but it didn’t serve the team we actually were at the time. The maturity of the product, the size of the team, and the realities of what needed to be delivered were all telling us to keep it simpler. I just wasn’t listening closely enough.
That experience stayed with me. It is why I now view process as something provisional. A tool, not an identity.
Frameworks are tools, not belief systems
This is the core of how I work now.
I look at process as something to support the work, not define it. I like to think that I have a toolbox which I can draw from, so that I pull out the appropriate tool for the task at hand. I talk with my team about what’s working and what isn’t. I keep what serves us and leave the rest behind.
None of this is radical. But it takes intention. It takes trust. And it takes a willingness to stop asking “Are we following the framework right?” and start asking “Are we solving the right problems in the right way?”
That shift changes how a team works together. It gives people the freedom to think critically. It encourages better questions. It invites better answers.
To close this out
Every framework carries value. But none of them will tell you what your users need, or how to solve a hard problem, or what your team needs in order to do their best work.
That kind of insight comes from context. It comes from listening. It comes from being willing to change your mind.
When process becomes the goal, you stop adapting. But when process is treated as a living toolset, you can build things that matter, work more confidently, and help your team move with clarity and focus.
That’s the kind of environment I want to build. Not one that’s perfectly Agile. One that works.