let's talk about scrum. as commonly defined, a collection of processes and policies. more specifically, it's a set of roles, where each role has a set of tasks, and defined interactions with other roles.

ask a scrum consultant and they'll tell you that it can make any team effective, instantly speeding up development, reducing errors, and generally whipping bad teams into goodness.

ask someone who's worked under scrum enough places and they'll tell you different: a dysfunctional team doesn't magically become functional, it just becomes differently dysfunctional. the same people still play the social game to look productive without producing, or steal credit for work other people did, or set unreasonable deadlines and ignore feedback.

the reason for this is because scrum is, very literally, a technology. it's not a computer, but it's a set of defined systems interacting in defined ways. it's tech. and that means that it's inherently limited.

your boss isn't going to magically stop prioritizing the sales team just because scrum calls him a "product owner" now. your asshole coworker isn't going to stop scoffing at "dumb users" and going his own way, writing reams of code you have to tear out two weeks later, just because he's looking at a list of user stories. upper management won't care about sprint velocity or burndown charts, just that the new metrics show up as green as the old ones on their dashboard.

and that's why so many people have horror stories about scrum failing: your team has social problems. you can't just do a technology at it.

scrum itself is mediocre at worst; it's a niche tool which works well in that niche. but there's a danger inherent to tech like it, things with a lot of moving parts in poorly-understood fields. i call it the "clarke effect": sufficiently advanced technology looks like magic, so surely it must be!

this manifests with scrum as the insistence that scrum can't fail, you can only fail to do scrum, it is the children who are wrong. you don't get it, scrum is great, you just need to do it better. you just need to enforce it harder and, the consultant promises, the technology can fix the team. conveniently, they'll collect their check and bounce before your team is expected to deliver.

it doesn't stop there. the clarke effect is also why the current "artificial intelligence" boom is happening, and why even a brief moment of honest explanation is enough to break the spell. "it searches through ten thousand documents to find your answer" is the handwaved, clarkean explanation that invites you to think of it as magic, smart enough to write your legal briefs or find hackers in your logs. "it guesses the next most probable word based on the billion documents it was trained on, including the ten thousand with some words in common with your prompt" is simple enough for my grandpa to understand why it hallucinates.

but the clarke effect is also behind judges blindly trusting racist sentencing algorithms, people falling asleep behind the wheel of their "full self driving" tesla, total faith in the reliability and uptime of "the cloud", leaps into the phantom arms of big data, wild promises of wealth with web 2.0 and the dot-coms – the tech is so advanced! how could it fail?

and the same exact effect afflicts processes and policies. scrum, kanban, waterfall, robert's rules, court procedure – these are all seen as silver bullets, when they're just as imperfect as any other technology, and need to be questioned, criticized, and improved.

if you want a dev team to be successful, "doing scrum right" is neither necessary nor sufficient. what is necessary is support from the rest of the organization, getting people to see things from others' perspectives, envisioning how tech can help people and how it can be built.

and sure, scrum can help with that. it provides a pretty clear interface to the rest of the organization and some nice ways to communicate "i can't implement everything without delaying something" while being able to blame it on the process, thus using the clarke effect to your advantage. it formalizes the crucial step of listening to feedback, which is easy for devs to skip, by accident or on purpose. it lets you plan complex pieces far enough ahead to work smoothly, while discouraging overplanning that could get you stuck in a rut.

but that doesn't make scrum perfect. treat it like any other tech! evaluate whether it's working, and if it isn't, debug why not. and keep this in mind with other processes – they're technology, too, and will need tweaking and optimization over time.

this post is long enough as-is, but i want to leave you with a couple other places where this trap can be especially painful:

1. moderation: you want to write a set of rules so perfect that they completely describe "good behavior". you can't – you'll inevitably fail, and being too rigid with your own rules can break a community in half.
2. governance: perhaps the most classic iteration of this problem. obviously real-life politics is an example, but so are a lot of open-source projects. there is no system which prevents all harm – it will always require human intervention.

i don't have solutions for either of those, just thoughts, and a desire for you to think about them too.