The End of Scrum
TL;DR: it’s impossible to point to the value of Scrum or the benefits of Scrum Masters being present in dev teams. The phenomenon should rather be considered in the context of belief and wishful thinking.
This is my first post in an anti-Scrum series. It is somewhat biased and full of generalizations, but my goal was to point out the sect-like nature of Scrum and the lack of translation of this methodology into measurable results.
Who is a Scrum Master?
Recently I witnessed a cosmic metamorphosis. A girl from accounting — a nice person, but with no experience in managing IT projects — became a Scrum Master in a highly technical team. Did she manage? Oh yes! To this day she remains in the position by sheer inertia, participating as a silent listener in cross-team meetings and appearing in CCs of project-related emails. Sometimes she says something, sometimes she updates a task status in Jira. And that’s it.
Maybe she’s outstanding and I’m just bitter about it. Or maybe — let’s just consider this for a moment — it’s simply the case that a Scrum Master doesn’t have any specific skills? Maybe it is — excuse the strong word — a profession that doesn’t really require anything beyond basic communication skills and using Scrum Guide-related words in specific situations.
“Retro, refi, sprint, review, planning, dependencies, daily, artifacts, blockers, capacity, velocity” etc. ad nauseam.
Ah, and also “empiricism”, stripped of its philosophical connotations.
The questionable value of Scrum
Scrum Masters have firmly embedded themselves in the structure of dev teams. They have put down roots so deeply that practically no one even wonders anymore whether the person who asks every day what you’re going to do today has any positive impact on your work. They simply exist — like a fern on grandma’s wall unit, like a representative of the party committee at a factory workers’ meeting.
This surprises me a bit, because businesses pay Scrum apostles quite a lot of money (after all, the salary of an SM could often fund an additional developer), while the results of their work are basically immeasurable. How, after all, should the work of a Scrum Master be evaluated? By the number of planning poker sessions? The degree of backlog organization? The number of ceremonies (incidentally — a term borrowed from religious terminology) per week? Knowing the 10 words of the Fibonacci sequence?
I’m probably not the only one who gets the impression that organizations practice some kind of cargo cult with Scrum. They want to conjure reality and believe that the mere presence of Scrum overseers will be enough for software to grow stronger and corporations to prosper. Because Netflix does it, because Amazon, because Google, etc…
Only the real Scrum
“Hold on!” — a hardline Scrum Master will say, applauded by a Scrum neophyte. “That’s not how it works — Scrum is about the approach, about the mindset (Polish Scrum is, after all, dripping with Anglicisms), and besides, your Scrum was surely implemented incorrectly.” The antidote? More Scrum — the dev team will survive. Maybe one more round of planning poker, maybe another therapy-couch-style retro, maybe another board with sticky notes. And let the one who has never stuck strawberries on an interactive board during a “retro” be the first to laugh.
Alright, to give credit where credit is due. The assumptions of Scrum are fine. They were written by programmers for other programmers to standardize their work and give it some structure.
A noble goal, but the consequence of introducing Scrum into organizations was that a horde of self-proclaimed SMs quickly entered the game after bootcamps and — with management support — spread themselves as full-fledged members of dev teams. It turned into a business that includes not only the Scrum phenomenon in the IT industry but also the training industry, conferences, consulting, etc. Organizations blindly followed the new trend. Today it’s hard to imagine an IT department without a pack of SMs, with zero understanding of technology and no clue about the work involved in developing and maintaining software.
Scrum proselytes will immediately protest that an SM doesn’t need to be technical — after all, they set up processes according to their little red Mao book (Scrum) and make sure Scrum’s principles remain strong within the team. It’s not for me to judge whether that’s a good approach. In my opinion, a team should have a technical person who supports managers or Product Owners in decision-making and — to put it bluntly — checks whether the dev team is pulling the wool over their eyes. I think I’ll return to this topic in another post.
What instead of Scrum?
We’ve grown attached to Scrum. It’s nice to meet for 15 minutes and talk about planned work, even if it has nothing to do with the real plans — especially in remote teams. Retrospectives? OK. Working in sprints? I have nothing against it.
But does sticking to this really require the presence of a dedicated person? Couldn’t this simply be done by a Project Manager / Product Owner / Project Lead / Team Lead / [insert equivalent role from your company here]?
Let’s try to answer that question honestly — it seems to be rhetorical after all.