Blog

A mature product living on autopilot and a brand-new product searching for its first customer aren't just at different lifecycle stages — they live in entirely different complexity domains. Mapping Cynefin onto the product lifecycle reveals a pattern worth paying attention to: what works for one stage can be actively dangerous in another. And assuming you're in a simpler space than you actually are is one of the fastest routes into chaos.

Most product owners in the world are scribes or proxies, which means they don't have much real power. Pretending otherwise doesn't fix it — but there are two coping strategies that can help. One borrows a concept from Large-Scale Scrum, the other is a simple "speak now or forever hold your silence" meeting that can buy you real authority for a sprint at a time.

The phrase "product owner" hides a wide range of realities. Some are scribes — taking orders they know are wrong. Others are proxies, business representatives, sponsors, or the rare "CEO of the product" who can actually make decisions — and understanding which one you are is the starting point for doing the job well.

Large-Scale Scrum (LeSS) is often filed under "scaling frameworks," but that label undersells it — LeSS is really a de-scaling framework built around simplification, queueing theory, and a genuine whole-product focus. It keeps the essentials of Scrum but modifies events like sprint planning and backlog refinement for multi-team reality, adds an overall retrospective to unlock organizational improvement, and has officially aligned itself with the 2017 Scrum Guide rather than 2020. Whether or not you adopt it, the underlying ideas are worth knowing.

Agile outside software is absolutely possible — but it comes with a credibility problem most coaches underestimate. If you don't understand the business and technical domain the team actually works in, you'll push frameworks that don't fit, and the "resistance" you run into won't be imagined — there really is a wall, and you just haven't found it yet. Sometimes the right move is Scrum; sometimes it's Kanban, Kanplexity, or something you invent — and knowing the difference is the real skill.

A lot of what passes for Scrum today isn't really Scrum at all. It's Water Scrum Fall dressed up in agile language, with confused roles, broken definitions of "done," and Product Owners chosen for their availability rather than their authority. But alongside that decline, something more authentic is quietly growing — and it's worth paying attention to which version of Scrum you're actually part of.

What separates a scrum master from an agile leader? And while we're at it — what's the difference between a scrum master and an agile coach? (Answer: about $200 a day.) Beyond the punchline, there's a meaningful conversation to be had about the overlapping roles that shape agile organizations. This piece breaks down what scrum masters actually do, what leaders add to the mix, and why the best leaders often make excellent scrum masters — provided they leave their controlling-manager instincts at the door. From walking the gemba to cultivating environments where agility can grow, here's a practical look at where these roles meet, where they diverge, and why the overlap matters more than the distinction.

Scrum Masters and agile leaders do a lot of the same work: observing, coaching, removing impediments, and cultivating the environment where agility can actually grow. The main differences are about reach — leaders walk the Gemba of value creation and consumption, connect funding to learning, and use their power to clear the obstacles Scrum Masters can't. Done right, the line between the two starts to blur — and that's a good thing.

Developers build the product. The product owner sets the direction. So when a scrum team is struggling, whose name is on the line? Since the 2020 Scrum Guide, the answer is clearer than it used to be — and it has real implications for how scrum masters show up, intervene, and work beyond the team itself.