Scrum was a revolution. Is it time for another?
Tags: agile, scrum, software, engineering
Published: 2024-05-07 14:29:32

---
title: Scrum was a revolution. Is it time for another?
published: true
description: 
tags: agile, scrum, software, engineering
# cover_image: https://miro.medium.com/v2/resize:fit:1400/format:webp/1*ef3nvjExqxtz9MR6P4ti8A.jpeg
# Use a ratio of 100:42 for best results.
# published_at: 2024-05-07 14:22 +0000
---

Scrum was an indisputable game-changer in the world of software product development. Its iterative approach has long empowered teams to attack projects in manageable, time-boxed chunks, adapting on the fly and improving the process as they go. And yet, industry lore is littered with anecdotes of dysfunctional Scrum teams. Scrum’s prized “agility” and self-organized teams generally require a prohibitively high caliber of discipline and communication across team members and organizations to truly access its many storied benefits. In an industry in which such skills and qualities vary wildly across individuals, are Scrum’s promises too often just too hard to collect on?

## Scrum just cares about one thing.
![Gears and dials](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*9V0oKwr9Pp2Af5XPkVrrxQ.png)
Scrum isn’t trying to solve all problems, just one: maximizing productivity (a.k.a., velocity). There are plenty of other considerations that Scrum intentionally leaves up to the implementer. Such activities can occur during the Sprint (while not being defined by Scrum — like quality assurance — or can occur entirely outside of the Scrum workflow — like business metrics analysis. Scrum is, by design, single-minded.

The issue lies in how Scrum prescribes distinct roles tailored specifically for its single-minded mission. Over time, these Scrum-specific roles have been adopted as standardized organizational positions, despite not being designed for such broad application. We’ve adopted a one-size-fits-all solution with defined roles that are, by their very definitions, primarily focused on delivery — ignoring other crucial aspects like engagement, correctness, performance, and financial KPIs. Consequently, our organizational structures are often built around these roles, which is problematic. The official definitions of Scrum roles are insufficient for broader organizational purposes, often leaving individuals in these roles unsure of how to bridge the gaps in a Scrum-compatible way. Perhaps what’s important is not the Scrum roles themselves, but the activities for which they’re accountable.

## A cacophony of collaboration.
![A group of professionals working in mayhem in a disaster of an office](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*WHW-AYK90OOWF5MDk67bwQ.png)
Additionally, Scrum’s emphasis on self-organizing teams is often highlighted as a major advantage, suggesting that teams who have their decision making power more distributed will operate more effectively. However, the effectiveness of this approach is highly debatable. It can be argued that without the clarity and direction provided by traditional leadership roles (most of which still exist anyway, causing even more confusion), self-organizing teams can struggle. One experienced leader can make faster, better decisions than “decisioning by committee,” and such leaders are ready to go on-hire, having already gone through their learning curve. Most importantly, if I learned anything from my time in the military it’s that delegation is more efficient and effective than collaboration (and consciously valuing delegation does not preclude abundant collaboration). While collaboration gives people the warm fuzzies, it requires deliberation and buy-in. Delegation gets shit done.

Not to mention that, in practice, self-organization is so dramatically difficult an ideal to achieve that many teams tend to just iteratively fumble their commitments and/or the quality of their deliverables. Self-organization for a team requires a lot of a very particular level of knowledge, self-discipline, and the assertiveness necessary to hold each other accountable. Either that or an enormous amount of specially trained staff (Scrum Masters and Coaches) to train teams on and reinforce the virtues of self-organization.

## A strong tool might not be the best tool.
![A hammer and a screw](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*nYQwWP8sW2soQjPwk_Ya4g.png)
It has been more than three decades since Scrum was first introduced. Yet, despite the array of organizations and committees involved, its core definition has remained largely in the hands of the same select few. For an industry that openly lauds innovation, we can be absurdly dogmatic. Even the most successful and historically useful solution isn’t necessarily right for every team or project.

Scrum was a revolution. Should it now, itself, be overthrown? Of course not. It’s a heavy weight champ, and as of now there are still no real contenders. But perhaps now is the time to critically evaluate whether its once-revolutionary principles still merit their unchallenged standing, or if we are ready to develop new paradigms of productivity and leadership.