You don’t need scrum
Something I’ve never really been able to mesh with a lot of people in my industry is that I just don’t get Scrum. It’s existence stands out as a weird anomaly in a field full of anomalies. As a part of our industry, in my opinion it’s the only standard that exists because we collectively have decided that against all evidence otherwise, it works.
Scrum is one of those strange things where you can find plenty of people talking about how nice it is. Lots of conferences about it and youtube videos waxing eloquent not just about it, but about hyper specific implementations and nuances about it. Strangely enough, however, no one’s ever bothered to ask if it actually works. It feels as though everyone just woke up one day and decided that this was it. People are quick to attach things to Scrum, but never really seem to be able to prove it’s benefits on it’s own merits. Much like the “Spotify Model”, something that Spotify used for about just long enough to create a god awful video talking about how great it was, before dropping it like a pile of hot rocks.
If you read anything about scrum, scrum proponents are almost constantly, whether on purpose of not, using complex linguistic tricks to pretend that anything good that has ever happened in software was because of scrum.
Agile is good, and Scrum says it’s agile, ergo scrum is good. Lots of high performance teams use standups, and scrum uses standups, ergo high performance teams use scrum. On and on and on, it seems like despite very few high performance teams seeming to even acknowledge scrum exists - let alone going to scrum conferences or talking about scrum or singing it’s praises to anyone who’ll listen.
So then why does basically everyone use scrum? I mean, besides inept technical leadership, because really scrum can’t be blamed for that. That’s unfortunately a much bigger and much more common problem. I’ve always been perplexed at how scrum can so constantly be a part of discussions around “high performing teams” when the actually high performing teams at places like Google, Facebook, and Netflix, don’t use scrum at all.
That’s not to say that I don’t believe there’s a few things that Scrum does have going for it. The great benefit of scrum I think, is that it is the great equaliser. Executed correctly, it can take any team of developers and make them all slightly worse than average. Maybe even average if you’re lucky. Forcing developers to actually think about the work they’re doing, making them think about what their next week or two is going to look like and how they can actually achieve something in that time, and then looking back on what they’ve done, can be pretty powerful.
If you’re working with low performers
I mean, basically. Scrum’s whole deal is really great for taking people who are bad at their jobs - juniors or otherwise really poor engineers - and turning them into people who could meet basic bare minimums. It seems like whenever I see scrum success stories (where that success could actually be attributed to scrum), the common thread seems to be that the teams just weren’t that good in the first place. Which, sure, scrum will help with that. But honestly is that what you want? A team of people who have to be forced via strict processes to take a very basic level of ownership and responsibility over their work?
And what’s the cost of all of this? It’s that any developer that’s more than “just okay”, will also inevitably fall to that level. The key to good development work is fundamentally uninterrupted time to focus on the problem at hand. As Paul Graham once wrote: “[Programmers] generally prefer to use time in units of half a day at least”. Scrum of course, instead takes the approach that if a developer is having difficulty solving a problem, then surely the problem is that they haven’t had enough meetings. The problem just isn’t defined well enough, so maybe a refinement session will help. Then after that refinement session maybe they could have a three amigos meeting to really clarify the problem. Of course they’ll still have the daily standup to go to, along with a review session.
It never ceases to amaze me that whenever I see scrum proponents talking about these very specific concerns from developers, they seem to be completely unable to conceptualise that their very solution is the problem. For any good developer, basically the only justifiable meeting is the daily standup and that’s about it. Virtually every other meeting is something that at best is net neutral and in most cases something that actively hurts what they’re trying to achieve.
Your stakeholders can be low performers too
The one other thing that scrum has going for it is that the scheduled nature works really well with non technical stakeholders. When people can’t understand exactly why estimating technical tasks can be so inaccurate, forcing them into the same schedule the developers are using can have some really strong benefits. It doesn’t necessarily make the relationship perfect - everyone has worked on a project where the stakeholders changed everything mid sprint and then complained when goals weren’t met - but it does improve it.
There is, unfortunately a double edged sword in this faustian bargain. Inevitably when work is expressed in strict units of time, people begin to play politics with it. Technical debt almost always takes a backseat to feature work, often placed into the catchall bucket called “if we have time this sprint”. It’s also hard to argue with stakeholders why they should wait at least another two weeks for the feature they think will increase revenue by 10% while the team works on some complex technical issue that they can’t explain and has no direct monetary benefits. I think it’s no surprise that the single most common approach recommended to paying down any technical debt is to simply lie about how long something will actually take and then use that buffer to patch the holes.
This isn’t to say that without scrum stakeholders become technologists, approving any and all technical debt work developers request. But I think that there’s something to be said about the nature of longer timelines causing a lower tolerance to delays, particularly how it relates to viewing timing as a budget that should be spent. In my experience, leaving technical debt to “if we have time” results in solutions that are much worse and representative of the time available for the solution. If a team closes out all of it’s work a day earlier, yes, they (may) have a day now to work on technical debt. But rather than create a solution that solves the problem long term, developers are incentivised to instead create a solution within that day. In almost all cases, this merely kicks the can down the road, creating more technical debt that developers simply hope they’ll be able to justify spending a proper amount of time on in six months time.
So what’s the solution then?
In short - Hire better engineers.
Look it’s 2025. It’s not the 90s anymore when something like scrum was revolutionary. The idea of a developer saying they “just write code” and don’t need to think about what that code is actually doing for stakeholders, whether that’s generating new revenue or saving costs, is becoming exceedingly rare. Developers are taking more responsibility for what we write and most people will need to have an appreciation for the context even if they don’t think they have to. A developer is no longer just a developer but someone who has at least surface level knowledge of topics like QA and infrastructure. They don’t need to be reminded every two weeks that they’re updating a function because it’s not performant and smashing the database. Hell chances are that they’re the ones who pushed to change the function because they’re tired of being woken up at 3am when a random spike in traffic causes the database to keel over one too many times.