A few years ago, a software developer I worked with showed me a side project he had been working on. It was a surprisingly complex app, which he’d made partly because he wanted to use it, and partly to learn a new tech stack. It worked across multiple devices, it integrated with other apps he used, it looked great, and it had some really cool functionality. If I’d bought the thing from the app store, I wouldn’t have felt ripped off. I asked him how long it had taken him to build, and he told me that it was only a couple of weeks.
This bothered me. A lot.
At that time, the place we worked employed around 50 software developers and a bunch of Product Owners. And I knew without a doubt that there was no way in hell we could have made that app in a couple of weeks.
If we’d been asked to make that app, two weeks later we’d just have a bunch of post-it notes all over a meeting room wall. I didn’t know many of the software developers or product owners well at that time as I worked in another part of the business, but they all seemed like intelligent and hardworking people. If they’d been asked to build an app that fulfilled the same requirements, I didn’t for one moment think that they wouldn’t be capable of achieving it. But I was still in no doubt that they wouldn’t. One software developer working on his own in his spare time would achieve more than they would, I was sure of it.
It really, really bothered me.
A few years later, I found myself running a software team of my own for the first time. I hadn’t taken over in the best of circumstances - things hadn’t been going well since a major company restructure a year or so before - but having never run a software team, I was reluctant to make sweeping changes. This is when I first learned about scrum.
Pretty much the only thing everyone in the team agreed on was that they should continue to use scrum. I’d heard of it before, but I hadn’t used it. I have to say, the moment I learned about it, I loved it. It just made so much sense. It was an elegant self-improving process that sang love songs to my inner geek. I talked to all the scrum masters I knew and I bought into all the evangelising.
One thing did seem a bit weird to me though: if the team were already using scrum, how come they were struggling so much? They must just not be doing it right I concluded. Yeah, that’s what it would be.
Sure enough, they weren’t doing it right. The stand-ups were half-hearted, they’d stopped doing retrospectives entirely and each ceremony was unstructured and confrontational. “This is going to be so easy” I thought “once I get them doing scrum properly”.
Flash forward a few months and once again I’m hearing the phrase “let’s talk about it in the retrospective” as if planning to talk about a problem another time is somehow a solution to it. Everyone is still frustrated, the sprint goal is just a mirage that moves further away the closer we get to it, the backlog is about as likely to be delivered as an orphan’s christmas list, and if I have to break up one more argument about what a story point actually is then I’m going to expend a lot of effort murdering someone in an extremely complex way. WTF scrum!? This wasn’t supposed to happen. You lied!
So I called one of the scrum masters I knew. “WTF scrum master” I said “this wasn’t supposed to happen. You lied!”. To which he replied “Nah, you’re just doing it wrong”.
That’s when I worked it out.
“Hang on” I asked “how often do people do it right?”. I didn’t need him to answer, I already knew what he was going to say.
In the words of Michael Bluth: “There it is”.
Scrum - like Communism or having a picnic - only makes sense in theory. If you did it perfectly it would do exactly what it promised, but you almost certainly won’t do it perfectly, and then it’s going to do more harm than good. I am yet to meet a single person who has seen it work anywhere near as often as they’ve seen it fail. The entire framework is simply too subjective, and the countless different takes on what each term means leads to constant misunderstandings, either communicated or not.
Ironically, it’s that very subjectivity that has allowed it to thrive despite all the failures. It escapes the harsh judgement it deserves due to the ‘no true scotsman’ logical fallacy. If you implement scrum and you succeed, you were using scrum, and scrum will stand smugly in front of you taking all the credit. But if you fail, then you obviously weren’t really doing scrum, so scrum steps back pointing at you accusingly yelling “look at what YOU did!”. To a dedicated scrum disciple, scrum has never failed, because if you’d actually used scrum then you would have succeeded.
At the time of trying scrum, I had led teams for over a decade and had never had the kind of communication breakdowns we were experiencing. I’d never consistently missed goals before, never had a team of people who weren’t connected to what we were trying to achieve before, never had such conflict before, and not once had I ever felt like I couldn’t influence the outcomes before. I’d failed before, sure, but I’d never felt like I had no control. With scrum, I felt like we were all completely beholden to this entity that didn’t let us do things when they needed to be done. When I took a step back, I realised that scrum was actively blocking all the behaviours that typically made my teams successful.
The most basic problem is that the ceremonies that scrum prescribes to ensure certain conversations happen in fact just provide excuses for those conversations not to happen at the point they actually need to. Blocked at 3pm? - talk about it in the stand-up the next day. Problem on day 4 of the sprint? - talk about it in the retrospective (not that you’ll remember to). Each wait for the next ceremony chips away at the time that could be used productively, and the result is bloated group meetings and slow progress towards the goals. Everyone waits for the specific ceremony to talk about the specific thing. Communication is ring-fenced and no longer fluid and open. A great team will just deal with things when they need to be dealt with, but by drawing so many lines around when conversations should happen, scrum blocks this behaviour emerging.
When you examine the process, you see immediately that it was created by engineers. It assumes people behave like machines, but they don’t. Scrum assumes every person is the same and asks everyone to communicate in the same way. That’s lovely in theory, but in practise it’s just not effective. Having big group sessions where everyone is asked to communicate in exactly the same way means that only the people who are comfortable with that way of communicating are heard. My guess is that if you’re using scrum, your ceremonies are just like most other recurring meetings - they’re dominated by the same few people every time, and the rest of the team largely just sits there in silence listening to those people talk. For the people who aren’t comfortable actively engaging in these ceremonies, all they do is burn time.
And finally we have story points. Oh dear god, story points. I hate story points with an immeasurable fury. I say immeasurable, but I really mean 13. Or 8, or Elephant or Chair or whatever other arbitrary value you want to use to obfuscate what I actually mean. What makes me hate them so much - aside from how utterly and completely pointless they are - is that whenever I tell scrum fans that I hate them, they will invariably start scrum-splaining the theory to me like I just don’t get it. When people do this I want to have them towed out to sea and sunk by naval gunfire.
I know what they’re supposed to do - I don’t need to hear the theory. My issue is that they don’t ever seem to actually do it. Not once have I seen a scrum team that is able to predict what’s going to come out of a sprint. Not once. And when it comes to the conversations people have in the scoring process, all I ever see is pointless arguments about which totally arbitrary number they’re going to assign to the work they’ll never get a chance to do because they’re all too busy scoring it. Nobody can even agree on what a story point means.
I am sure that right now some of you are desperate to explain story points to me. To make you feel better, I’m going to confirm that I understand that a story point is supposed to take into account the amount of work, risk, complexity, time and effort of a task (I’m using all the different factors that people have patronisingly explained to me over the years, which by the way, is NEVER the same from person to person). But here’s the thing they all completely missed…
If you just ask someone “how long do you reckon that will take?” they will instinctively consider all of those factors. Then they’ll come back with an estimate, and that estimate might be right or wrong, and over time you could use their track record of being right or wrong as a way to predict how much work can actually get done in a given time frame. It’s exactly the same! Story points are just obfuscating the only thing that actually matters, which is when the thing might actually get done. At DoThings we just check-in on the task owner each day and ask them how many more days work they think they have to do. If the days are going down - great, if they’re going up - not so great. If it makes you feel better to call those estimates points instead of what they actually are, go for it, but please stop using story points because they are preposterous.
When I finally worked all this out, that niggling riddle at the back of my mind was finally solved. Why was one software developer able to achieve more in his spare time than a team of 50 working full time? Because nobody dragged that one guy into a meeting room to make him assign random numbers to task lists. Because he didn’t spend more time arguing about that random number than he would have spent just doing the task. Because nobody made him stand around and listen to a bunch of other people talk about what they did yesterday. Because nobody made him sit in a room full of people and talk about things they could do better next time before going on to behave exactly the same way anyway. Because nobody diluted his work to a series of mundane tasks that were totally disconnected from any real purpose.
Because he was just left alone to work.
I once asked a software developer what his biggest challenge at work was. His answer was “finding the time to do any work”. That’s the world scrum created for him.
Now, if you’re a scrum master reading this thinking ‘this guy is an idiot, he’s just doing it wrong. I don’t get any of these problems’ then I have some news for you. If you’re not getting these problems, it’s not because of scrum, it’s because you are a gifted manager. Scrum isn’t brilliant, you are. If you are making scrum work, you could be successful with any team management framework. You’re not a scrum master, you’re an exceptional manager. Scrum is just getting all the credit.
But when things start going wrong, who do you think will get the blame?
Management isn't doing what it's supposed to do.
Buy the book on Amazon today.
If you liked these words, please share them.