When I first encountered Scrum, I liked the idea. A teammate fully dedicated to unblocking engineers, to aggregating documentation, to finding the answers to problems that caused so many of my day-to-day context switches — finally!
But as any developer knows, that is far from the reality of Scrum. Scrum Masters would utilize me, like subtle micromanagers, wanting to know if I’d be done with a story before the end of the sprint. Or if I could split my story in two, so that it’d fit nicely into their model.
It’s not their fault. Scrum Masters present sprint-based metrics to leadership to justify their job. As such, their main job is to enforce adherence to sprint-based metrics. It’s much easier to chop up a Jira board than fix organizational processes.
It’s taken a decade, but I’ve finally distilled what Scrum really is. Scrum is the business methodology born of capital-rich, easy-living companies.
Agile and its children were birthed from traditional businesses inability to build digital products. It mitigated the once-massive leverage that software engineering units held over their employers. By the 90s, companies were entirely reliant on these software units, but lacked both the cultural and technical acumen to utilize them effectively. Engineers were expensive, hard-to-find, and often had personalities incongruent with typical corporate culture. In this sense, Agile was the beginning of an interface between the extroverted, deadline focused businessperson and the autist-savant energy emanating from the engineering floor.
“Fine. You can have a soda machine, avoid business casual, and we won’t bully you for deadlines. But please, do some work.”
But Agile wasn’t really feasible from a business perspective, at least in its raw form. All of the tenants of Agile (below) sacrifice some business value to deliver better software:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
These sound great from the developers perspective, but planning, documentation, processes, and contract negotiation are necessary elements of a business. You can’t say “we prefer dynamic collaboration over static contracts” and then be surprised when your client is upset because the budget isn’t aligned with their initial expectations.
Enter Scrum — perhaps the oldest of the business-consultant rebranding of Agile. Trying to bring business value to Agile’s intentional vagueness, Scrum posits to break things down into sprints, estimate work.
Planning methodologies are the result of financial success, not the cause of it. To me, Scrum epitomizes the 2010s San Francisco startup mindset. In its purest form, it exists for companies whose revenue is guaranteed long before Scrum is implemented. It is the methodology of low interest rates — a sign of a company’s financial success, not the cause of it. Google may use Scrum now, but Scrum had nothing to do with Google’s success today.
In companies where funding is insecure, these methodologies are quickly discarded in exchange for “doing whatever it takes to keep the company afloat”. There’s no place for a Scrum Master at a company with 8 employees. But like a bad relative, they come knocking on the door when the money appears. The VC affords well-paid developers, beers at lunch on Friday, and a variant of Agile — usually Scrum. Scrum has spread like wildfire in certain leadership circles, partially due to the fear of leaders getting caught without the solutions Scrum purports to provide. Managers don’t seem to want to defend their own operational processes against the might of Scrum.
Ultimately an operations methodology with no relation to time is a perfect match to a business with no relation to money. So Scrum is especially prized at companies where the developers are ancillary to the company’s success — especially large enterprises who can afford the overhead, and who’s expectations for efficiency are already low.
Let’s look at story points. Story points intentionally keep development estimations in a nebulous state. Developers love this, and Scrum enthusiasts laud this fact: story points measure complexity and uncertainty, not time.
But businesses need timelines. They need measurements. And of course, Scrum does this terribly. Story points avoid granularity through Fibonacci, and sprints are arbitrary units of time decoupled from business deadlines (And for the unlucky companies, SAFe comes into play, tethering Scrum to fiscal quarters.)
But tasks with uncertainty are dependent on external factors. That’s what uncertainty means. If a task without dependencies has uncertainty, it just needs to be broken down further. There are exceptions, of course, but not as many as people think. If a developer is uncertain about learning a new tool or working through a process, this should be reflected by developer velocity, not the story sizing.
And when a team’s release schedule is revenue-critical for the company, sprints and story points are thrown out the window. I’ve seen this scenario in every Scrum team I’ve been part of. The classic situation: business wants a product ready at a certain date. In order to create an estimation, story points are measured as developer days. Enter developer velocity: a stupid, full circle omission that no measure of effort matters except Father Time.
But this isn’t the end. The product has to be ready in 5 weeks, but developer velocity indicates there is 7 weeks work. One of two things happens: stories are repointed to be crammed into sprints, or the stories are left as-is, and sprints are functionally abandoned.
But the greatest irony about Scrum is that it dulls any competitive advantage its practitioners might have otherwise had.
Companies spend millions on managers and analysts with formal training in creating business processes. But instead of letting them loose, they tie their business processes to the common denominator of all other Scrum practitioners.
When did it become okay to replace operational processes, once considered trade secrets, with open source methodologies? And if engineering processes are so ubiquitous that they can be formalized with Scrum, what are you paying managers and analysts for?