When I first encountered Scrum, I liked the idea. I had a teammate fully dedicated to unblocking the politically unsavy engineers such as myself. To aggregating documentation. To finding the answers to problems that caused so many of my day-to-day context switches. Finally! A management style that prioritizes developers.
But as any developer knows, that is far from the reality of Scrum. We weren’t optimizing our operations around work, we were optimizing it around… Scrum! I started to notice Scrum Masters acting 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 existence. Leadership, viewing the endeavour through higher level KPI boards, had no use for the Scrum philosophy beyond treating sprints as delivery deadlines. Over time the Scrum Master’s job became enforcing sprint-based metrics. Stories were split between sprints, work was over-estimated, and developers were micromanaged. It’s easier to chop up a Jira board than explain the reality of development to management.
Keep in mind that despite Agile’s ubiquity, it’s never been feasible from a business perspective. 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 planThese sound great from the developers perspective, but planning, documentation, processes, and contract negotiation are vital to 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.
And it’s taken a decade, but I’ve finally distilled what Agile really is. Agile is the business methodology born of low interest rates. Deadlines, concrete processes, and contracts don’t matter, because nothing is truly at stake. To me, Agile epitomizes the 2010s San Francisco startup mindset. In its purest form, it exists for companies whose revenue is guaranteed long before Agile is implemented. It’s a sign of a company’s financial success, not the cause of it. An operations methodology with no relation to time is a perfect match to a business with no relation to money. Google may use Agile now, but Agile had nothing to do with Google’s success.
And mark my words: as interest rates increase and development overhead becomes scrutinized, Agile be the first to go - replaced by “just doing work”.
But many Agile practicioners know this. So 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 and story points, and of course loses the plot of Agile along the way. It forgets the trueisms of Agile, and doesn’t solve real delivery problems either.
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, something like the Scaled Agile Framework comes into play, tethering Scrum to fiscal quarters.
Tasks with uncertainty are dependent on external factors. That’s what uncertainty means. If a task without dependencies has uncertainty, it needs to be understood further. There are few exceptions. 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.
When a team’s release schedule is revenue-critical for the company, sprints and story points are thrown out the window. This has happened at least once on every Scrum team I’ve been on.
The classic scenario: business needs a feature ready at a certain date. In order to create an actual roadmap, story points are expressed as developer days. Enter developer velocity: a full circle omission that no measure of effort matters except Father Time. But this isn’t the end. The feature has to be ready in 4 weeks, but the story-point-days indicate there’s 6 weeks of work. One of two things usually happens: stories are repointed and crammed into sprints anyway, or the stories are left as-is, and sprints are functionally abandoned.
The greatest irony about Scrum is that it dulls any competitive advantage its practitioners might have had. Companies spend millions on managers and analysts with formal training in creating business processes. This is the key component of management. But instead of letting them do their job, they tie their process to the lowest common denominator of all other Scrum practitioners. So now your $400k manager is using the same process as Acme Corp’s $50k manager.
Once upon a time operational processes were even considered trade secrets. When did it become okay to replace them with open source methodologies? And if project management is so ubiquitous that it can be understood through Scrum, why have managers or analysts at all?