The more I try and help teams adopt Scrum, the most I dislike it. And really, maybe it’s not Scrum so much as it is Planning. Plans change! And while the Agile community seems fine telling that to Management, we wring our hands when teams deviate from The Sprint Plan™️. Why? Indeed, the Agile manifesto calls out that responding to change is more important than following a plan. So what’s the point in Planning in depth, as Scrum would suggest we do?
Scrum feels rooted in idealism: That all teams are stable, cross-functional, with experienced Product Owners and a clear purpose. In reality, the most organizations are dynamic, with changing priorities, new and experienced talent alike, with organizational and funding models that are outdated. Applying Scrum to this mishmash of pros and cons feels a bit like willful ignorance: “Let’s just pretend everything is fine and be sure to close out your stories!” The duality of these environments – the reality the organization is present, and the space the Scrum Master is trying to create – is frustrating to team members who are likely incentivized in ways complete counter to “Agile values”. Trying to change behavior without changing the incentives is a fool errands.
And so what then? How do we get teams to change? Well it’s no secret that it has to start at the top, or at least at the highest level of an organization you can get. The higher up the mandate comes from, the easier (mostly) re-aligning teams to a different reality can be. But if that mandate doesn’t exist at all, your Scrum team may find itself on an island of Agile. Here’s how I’m picturing this:
In emergency services they call this the “span of control”: there’s only so much change you can affect (directly or indirectly.) Managers who are supportive of Scrum may never see lasting success, because the wider organization isn’t set up to support scrum teams at a system level. This sucks, but it is the reality for many, many organizations. Frameworks that aim to scale Scrum focus heavily on Leadership buy-in for this exact reason (allegedly1.) Thing is, systemic change is time consuming, costly, and really difficult to sell to others.
Now of course, if you’re a Scrum Master, your ability to change the system is likely very limited. So, now what? How do we enable teams to be more Scrum-like, in a system that doesn’t really enable that? What do we do with high-performing teams that struggling with sticking to a plan, but get stuff done when they work on it? I think the answer is kanban. Maybe Scrum with Kanban if you must. But I really think the answer is kanban.
Now of course, this discussion has been had, and a Kanban for Scrum Teams Guide exists. It nicely marries some core functions of Scrum with some core practices of Kanban. This is all to say, I’m not the first to have this idea. But the more I work with leadership and teams, the more I see a dissonance between what Scrum sells itself to be, and what is actually possible to do.
1 Maybe. Or maybe it’s because Leadership has the power to spend a ton of money, which these frameworks would love to get a piece of. Who knows!
Goscin.ski 