Blog

Scrum equals Agile. Agile equals Scrum. It's one of the most common assumptions in the industry, and it's wrong — Scrum predates the Agile Manifesto, and Agile today is a whole family of methods, frameworks, and strategies of which Scrum is just one option among many.

You tried the shortcuts. You realize there is no escalator to success. You want the people around you to be comfortable with you, you to be there for them, and for them to be there for you.

There are no set recipes for how to do things, but we will give you proven ideas, principles, and success patterns to try out and see what works for you. Self-awareness, emergent learning, and adaptation are essential.

You can join one self-contained module, some modules, or the entire series. Some modules cover in-depth topics that others only lightly touch. The content is interconnected yet independent.

Excessive bureaucracy curtails adaptiveness. So does an attitude of keeping promises even when it's learned they were terrible promises. More coherence is needed.

To mitigate the risk of negative consequences, more executives and board members need to embrace paradoxes and avoid false dichotomies. Consider humane effectiveness, adaptiveness, ambidexterity, and timeliness.

As an executive or board member, do you want to turn the tide? Do you want to be personally associated with something different, something positive, something pattern-oriented, something context-oriented? Do you want to protect your legacy? Do you want better results? 

Do you want to be associated with humane effectiveness, adaptiveness, and timeliness?

To maximize the amount of work done, maximize the amount of work not done. Huh? Think of it this way: you're in the plate-spinning business. Would you rather spin your optimal number of plates, or run ragged trying to stop them from hitting the floor? This piece is a quick, no-nonsense reminder that knowledge work is messy, entangled, and unforgiving of overload. Watch your work item age. Use the board itself as an aging chart. Swarm on the oldest and the blocked. Avoid fake items that pretend to deliver value. Push the finish line past delivery to value realization, so you don't end up running a feature factory. Start everything, and everything takes forever to finish. Focus, finish, and feed. Slack time is your friend.

Developers in Scrum aren't just coders — the accountability covers anyone doing the work to deliver the Increment, whether that's marketing, legal, analysis, or testing. They own the Sprint Backlog, build quality in through the Definition of Done, self-manage, and commit to the Sprint Goal. Understanding this accountability clearly — without drawing the lines so tight that team ownership disappears — is one of the most underrated parts of making Scrum actually work.

Should "stakeholder" and "leader" be formal accountabilities in Scrum? The Scrum Guide mentions stakeholders thirteen times without ever defining them, and leaders only in the context of the Scrum Master. This post argues that no team is an island — and that without coherent leadership and effective stakeholder collaboration, even the best-run Scrum Teams will struggle to deliver real value.

Standard, fixed date, expedite, intangible — the four classes of service from the Kanban Method are familiar to most practitioners, but should you actually use them? This piece walks through what each class means (and what doesn't count as a "real" deadline — your grandmother's birthday doesn't), and makes the case that from a pure flow point of view, classes of service hurt more than they help by causing some items to age while others get fast-tracked. There's a better way to handle urgent requests: record a breach in your WIP limit instead of increasing it. Plus a humorous tip involving two sleeping bags for testing how urgent an "urgent" request really is, and a clever real-world example from a large bank where one leader paired classes of service with a four-day ceiling on work item age. The one class of service worth keeping? Intangible — especially when the culture is obsessed with utilization.

The second practice in the Kanban Guide is actively managing items in your workflow — and it's all about striking a balance. Finish work. Watch for aging. Don't let the system starve. Sounds simple, but most teams default to one extreme or another. This piece walks through what active management actually looks like in practice: treating blocked items like a fire in the building, looking at relative item age (an item in column one that's the same age as one in column two is actually older), avoiding the temptation to start something new instead of unblocking what's stuck, and being brave enough to cancel work that's quietly on hold. Plus a tip on banana skins as a low-tech aging signal, why classes of service get sidestepped in the Kanban Guide, and why moving work backwards is almost never the answer. Take items as quickly as possible to "finished" — even if "finished" means cancelled.