The old Drum of When Scrum Works

mandag den 18. november 2024

When Scrum works, organizations and teams, I've observed, can become accountable and predictable.

This will sound like the beat of an old drum - nonetheless, I believe it's an old drum worth beating. This is yet another opinionated piece delving into why, as a field, we still struggle with Scrum - a process that, on paper, is quite approachable but demands professionalism, time, understanding, and respect to truly succeed.

Over the past years, Agile - and particularly Scrum - has been criticized for being tedious and difficult. I come from a different school of thought, one that might seem a bit too "square" for the pop-culture-inspired "young guns". I do not mean that in any harsh way, I myself was a "young gun" plowing away. But I was raised in software development with some notion of real agility, but my own context and setting for many years was in environments of small teams and limited resources - untill I tried the powers of larger organizations and teams.

Different approaches work in different contexts and settings, and this distinction is key. Process can be beneficial, but process for the sake of process is irrelevant and often counterproductive in certain circumstances.

Blaming the process, in my view, is a mistake - usually stemming from a misunderstanding of the context and setting. This, of course, is not the fault of the process.

Hanlon's Razor reminds us: "Never attribute to malice what can adequately be explained by incompetence."

Programmers are often creative beings, driven by a desire to unlock their potential through code. In that light, a process like Scrum might feel restrictive, or even stifling. It may feel like it slows progress, though often it doesn't. The tension comes from misaligned expectations and a lack of solidarity within the given context and setting.

Rather than asking how a process is failing, we should ask why the process is needed. In some contexts, it may not be. But context and setting should inform that decision, not blind faith or frustration.

Scrum has been sold as an Agile framework for sustaining flow and improving output, but it has never claimed to guarantee correct outcomes. That distinction - between output and outcome - is critical. Scrum won't save you if you don't know your goals.

Over my years in programming, I've seen this misplaced hope time and time again: a belief that process alone will deliver good outcomes, as if it could somehow walk on water.

A better approach is to ask why a process like Scrum is crucial for a particular organization or team. Software development is notoriously unpredictable (seriously, read the books!), but unpredictability doesn't mean we shouldn't try. Predictability is a shared responsibility - not just among developers but also for those setting business goals.

Scrum isn't perfect for every scenario. It's not great for validating hypotheses or scenarios requiring rapid iteration. It's too ceremonial for that. But in the right contexts - especially those demanding stability, predictability, and accountability - it excels.

Professionalism and respect are non-negotiable.

There are no shortcuts if the desired outcome is valuable. Sometimes, value means discarding an idea early because you've identified it as infeasible within your context and setting.

I believe Scrum is a fine process. Having worked through a wide range of issues with it, I've learned that the core problems often come down to maturity - or lack thereof - and an overload of noise.

Large egos often complicate things. Just as architects can dictate from ivory towers, claiming the map is the territory, colleagues might whisper (or shout) that Scrum isn't working. Some might claim Scrum isn't "truly Agile." I've even done so myself at times - but only when it's clear that someone has misunderstood or misapplied the process.

Scrum is a well - documented, robust framework.

When I've seen it work brilliantly, it's been transformative - like a seafarer discovering new continents. In these cases, teams understood the context and setting that made Scrum both helpful and necessary. Conversely, I've also seen Scrum fail miserably, often because it was implemented without consideration of those same factors.

Agility for individuals vs. teams

Individual agility and team agility are not the same. Teams are not just collections of individuals. A team of five agile individuals is not necessarily an agile team. Scrum is a tool for teams, not individuals. It emphasizes stability, predictability, and accountability within a collective, which may feel stifling for individual contributors who value creative freedom above all else.

This tension often stems from broader social constructs. In a world that prizes individuality, true teamwork - with no egos - can be a hard sell.

That said, many organizations have embraced Scrum as a default process, often misunderstanding its purpose. Scrum doesn't promise "swiftness" or ease of execution - it promises a framework. It supports teams by providing structure, but success requires professionalism and respect.

Introducing Scrum is a big deal.

Its ceremonies and roles are deliberate, and if the process isn't followed properly, it's not Scrum's fault. The expectation that Scrum is simple or intuitive is misguided. Implementing it requires significant effort and discipline.

In every organization, there are underlying factors - politics, pressure, dishonesty, incentives, communication barriers - that can derail even the best intentions. Before choosing a process, these factors need to be acknowledged and addressed.

Scrum is not complex in itself, but getting people to work together within its framework is. Don't be fooled by thin books or easy certifications. "The word is not the thing," as Korzybski famously said.

Beyond understanding Scrum, people need to respect it. Retrospectives, for example, are a vital space for actionable discussions. But if those discussions don't lead to tangible change, retrospectives lose their value.

Scrum is not agility - it's accountability.

In my opinion, Scrum works best when teams are in a stable, norming state - not forming or storming. For teams still finding their footing, lighter-weight processes are often more appropriate.

Yes, Scrum can feel tedious, but that's part of its DNA. It's designed to foster accountability and predictability. For teams focusing solely on business capabilities and neglecting technical growth, Scrum doesn't dictate that imbalance. Professional developers should know when to prioritize technical improvements.

The problem with Scrum isn't Scrum - it's expectations.

If leadership doesn't support it, Scrum won't work. If your work items are ambiguous, Scrum won't save you. If your Scrum Master fails to follow through on retrospectives, Scrum will falter. And so on.

Scrum is difficult to get right, but the process itself is rarely to blame for failures.