Blog

Keeping people busy isn't the same as getting work done, and responding to every challenge the same way isn't leadership — it's habit. Traditional project management tends to struggle with flow, with reading what kind of problem it's actually facing, and with finding a meaningful place for the project manager when teams move toward agile. Kanplexity addresses all three directly, and gives leaders a clearer guide than "pick a Scrum role and hope it fits."

Technically, one person can hold both the Scrum Master and Product Owner accountabilities. The Scrum Guide doesn't forbid it. But each role is genuinely a full-time job, the two pull in different directions, and when you combine them you tend to get a concentration of power that quietly kills healthy conflict inside the team.

Kanban is a powerful strategy for optimizing the flow of value through a visual pull-based system — but it's missing one important thing: a compass. This piece explores what Kanplexity adds to the picture, starting with the Cynefin sensemaking framework as a way to navigate complexity. When do you let the experts crack on? When do you run experiments? When does someone need to step in as a dictator in negative chaos? Cynefin helps answer those questions, but only if someone on the team can actually read the compass. That's where the Kanplexity guide comes in — defining the role of a guide, giving clear guidance for leaders cultivating environments where agility can grow, and showing how multiple teams (and even project managers) fit into the picture. Here's how Kanplexity creates clear water between itself and standalone Kanban.

Most product ideas shouldn't be built. Somewhere between 60% and 90% of what ends up in a backlog won't actually deliver value — but most organizations only discover that after they've already sunk time and money into the build. Lean UX, design thinking, and cheap experiments offer a way to find out much earlier, which is why the real wave in agility today isn't about faster delivery at all. It's about discovery.

What is a product, really? If you're a Scrum product owner who's supposed to be on the hook for maximizing value, you'd better be clear on what you actually own. This piece tackles a confusion that runs deep in product development: the conflation of product, platform, project, and service. Drawing on Bas Vodde's idea that "a product does not have scope" and Craig Larman's framing that a product is something an external customer recognizes and pays for, it offers definitions from the Kanplexity guide for product, platform, and service — and explains why the distinction matters. Why is your CRM not a product? When does a platform become a product? And why does it all come back to one core question: are you worrying about the short term or the long term?

Throughput sounds simple — the number of items delivered to the finish point of your workflow in a given time period — but there's more nuance to it than meets the eye. This piece breaks down what throughput actually measures, why it's tied to valuable work items (not sub-tasks or noise), and how to avoid the apples-and-oranges trap that pollutes so many teams' numbers. It also covers how to handle multiple finish points, why work item types matter more in non-software contexts, and the bigger question lurking behind every throughput conversation: are you delivering real value, or just turning Kanban into another velocity game? Because the goal isn't just shipping more outputs — it's delivering fewer outputs that produce more outcomes.

There's a critical difference between opinions and evidence — and even smart people inside the building often confuse the two. Customers don't know what they want, so how do we figure out what they actually need? This piece explores when to trust internal expertise, when to just build something, and when to run experiments instead. Drawing on Jeff Gothelf and Joshua Seiden's prioritization canvas from Lean UX, it offers a simple two-dimensional way to think about value and the risk of harvesting that value — and a clear answer to the question every product team wrestles with: when is it time to experiment?

Most learning programs fail for the same reason: they offer people hours they don't have. Four hours a week of development time sounds generous, but when the week already contains 44 hours of work crammed into 40, that time never arrives. Nine minutes at 9am — every day, protected, no meetings — is smaller, simpler, and far more likely to actually happen.

Scrum has been used in all kinds of domains, and the 2020 Scrum Guide made that reach even broader by removing most references to software. But "used widely" isn't the same as "works everywhere." There's one specific constraint that determines whether Scrum will actually serve you — or whether you'd be better off looking somewhere else entirely.