The world has changed a lot in the nearly 30 years since Scrum was created, and by far the biggest change has been to the ways in which we communicate with one another. It’s ludicrous to believe that a framework designed without the advantage of these tools could possibly continue to be relevant today, no matter how brilliant it was in its time. The Gameboy was brilliant in 1993. Nobody is using it today.
We need to talk about Scrum is an hilarious and at times savage take down of Scrum, and the near religious following that is has built within the world of software development. If you've ever looked at your team and had the feeling that they're somehow managing to be less than the sum of their parts, this book is for you.
A few years ago, a Software Developer showed me a side project he had been working on. It was a surprisingly advanced app, which he’d made partly because he actually wanted to use it, but also as a way of teaching himself a new tech stack. It worked across multiple devices, it integrated with other apps he used, and all things considered it looked pretty good. It was by no means the finished article, but if I’d bought it, I don’t think I’d have felt ripped off. I asked him how long it had taken him to build, and he told me it had only been a few weeks.
This bothered me.
At that time, the company we worked for employed around 50 Software Developers, plus a bunch of Product Owners, Scrum Masters, QA Engineers, Agile Coaches and Delivery Managers. Not to mention the functional managers, the departmental directors, and all the various support staff. But I knew without a doubt that there was no way in hell that all of us working together could have made that app in just a few weeks. If we’d been asked to make that app, a few weeks later all we’d have to show for it would be a bunch of post-it notes all over a meeting room wall, a mountain of Jira tickets, and several new unresolved conflicts.
I didn’t know many of the people on the software delivery side of the business at that time as I worked in another area, but they all seemed like intelligent and hardworking people. I didn’t for one moment believe that they wouldn’t be capable of making that app in a few weeks. But I was still in no doubt that it wouldn’t happen. It really did seem that a single Software Developer working on his own could achieve more in his spare time than our entire software delivery team could achieve over months of fulltime collaboration.
I found this bewildering, but I decided that I must have been missing something. There would be a reason for it, I just couldn’t see it due to my lack of expertise. As my role in the business was completely separate, there wasn’t anything I could do about it anyway. It would just have to be a question that would go unanswered. I went back to my actual job and tried not to give the paradox any more thought. Every now and then though, I’d look across our huge open plan office at the hundreds of people employed with the singular purpose of delivering software, and I’d think to myself: “what are all those people doing?”.
A few years later, I found myself leading 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, but having never run a software team before, I was reluctant to make sweeping changes. When taking on any new leadership role, it’s crucial to take time to fully understand your new team before trying to impose your own will on it. Even if you’re certain that you can see something that’s glaringly wrong, you must be patient and observe how it plays out in practice. You have to appreciate that your team have a far better understanding of the problems and intricacies of their work than you do, and just take the first few weeks to absorb and learn, rather than to challenge and impose change. Nobody appreciates a manager who comes in and immediately starts throwing their weight around. So for the first few weeks, you ask questions, you watch, you learn, and you change absolutely nothing.
This is how I came to learn about Scrum.
Pretty much the only thing the team could all agree on was that they should continue to use Scrum. I’d heard of it before, but I didn’t know how it worked. I must confess, 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. I was completely sold on it.
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 it hit me.
“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 immortal 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 make a big horrible mess. It’s a fantastic project management framework that has only one flaw: it hardly ever works.
Finally, after years of sitting on the outside wondering how so many talented people were producing so little end product, that niggling paradox at the back of my mind was solved. Why was a single Software Developer working in his spare time able to achieve more than a team of nearly 100 people collaborating fulltime? Because that one guy wasn’t continually dragged into meeting rooms and forced to 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 write problems from several days ago on post-it notes. Because nobody diluted his work to a series of contextless tasks that were totally disconnected from any real purpose.
Because he was just left alone to work.
Shortly after taking over this software team, I asked one of the developers what his biggest challenge at work was. His answer was “finding the time to do any work”. That’s the world Scrum had created for him.
I know this is an experience shared by many people, yet despite this, Scrum has managed to retain an almost religious following. The believers believe in spite of the evidence, and any dissenting opinions are shouted down quickly and brutally. When I first broached the idea of ditching Scrum, I was met with open hostility and disdain. The cognitive dissonance was remarkable. Everyone was simultaneously certain of two completely conflicting facts:
I seemed to be the only one who recognised that these things were mutually exclusive. If the framework we were using to keep us engaged and deliver software was brilliant, we would surely be engaged and delivering software. But we weren’t. In the end, I managed to get enough buy-in from the team that they agreed we could try one week of working a different way. Two days after we started, nobody ever wanted to go back to Scrum. We immediately became more agile, had more time for the real work, spent less time arguing, and had far clearer focus. In the first month of not using Scrum, we shipped more software than the team had shipped in the previous 12 months combined.
Since then, I have repeatedly faced the same situation with clients desperate to improve their productivity, but who at the same time are insistent on retaining the framework that was failing to make them more productive. My hope for this book is that it might go some way to deprogramming people enough that they’ll be open to giving alternatives a try. I should clarify that I’m using the term Scrum as a kind of catchall for everything that falls under it, whether it’s exclusive to Scrum or not. I’m aware some of the things I talk about were not created as part of Scrum, but they are all an intrinsic part of the Scrum experience. I make a point to say this because I’ve lost count of the number of times I’ve pointed out something stupid about Scrum, only for a nauseating Scrum fanboy to puff his chest out and say something like “well, actually, that’s a generic agile concept and wasn’t created as part of the Scrum framework”. I don’t care if the things Scrum uses are specific to Scrum - stupid is stupid, wherever it comes from. So, I’m calling the entire collection of stupidity Scrum for the sake of ease, and because Scrum is the way this nonsense most often manifests.
Finally, before we get going, I have consistently found that offering alternatives to Scrum has proven to be a largely pointless endeavour unless the indoctrination is addressed beforehand. The dedicated Scrum disciples don’t see the problems that are staring them right in the face, so they have no interest in hearing about other approaches. When someone believes in it, they seem to believe in it based on what it’s supposed to do, and they ignore what it is actually doing. With that in mind, rather than the emphasis of this book being on providing a specific alternative to Scrum, its primary aim is to deprogram its cult-like following. I do briefly explain the approach I use instead, but I’m not here to sell a new cult; only to expose the existing one.
I truly believe that if you simply step back and look at Scrum for what it’s actually doing for us, you’ll realise that almost any other approach you could think of would be a better option.
Whether you manage a team, a department, or an entire company, The Management Delusion is a must read for every modern manager.
Funny and insightful, The Management Delusion will change the way you think about management forever and leave you wondering why we ever made the job so complicated in the first place.
The Management Delusion lays out the failures of conventional management, and provides shockingly simple approaches to every day management activities that anyone can implement. Whether it's goal setting, performance reviews, delegating, career development, recurring meetings or pay reviews, you will find new ways to work that will make your life easier and your employees more productive and engaged.
I was in a meeting when it hit me for the first time. It was one of those meetings that nobody seems to want, that nobody seems to benefit from, but that for some reason everybody keeps getting dragged into. I looked around the faces of my colleagues - people who I knew to be dedicated, driven and intelligent - and I saw nothing but boredom. I listened to what was being said, and I thought about how little difference any of it would make to anything we were trying to achieve. Then it hit me with complete and total certainty.
Management is broken.
I have managed and trained managers at all levels, from the bottom of the org chart to the top. And after nearly two decades of doing this, I have come to realise that the way we approach this job is preposterous. This is a stupid way to get things done.
Bill Gates famously once said, “I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it”.
Well, we’ve been doing the opposite of that. We keep promoting hard workers, and hard workers tend to try to solve problems with hard work. Over the past few decades the demands placed on a manager have swollen to the point that doing everything we’re required to do to the standard we’re required to do it has become an incredibly rare thing. Most of us have had far more bad managers than good ones. That’s a disaster. The role is too important for that kind of failure rate. Imagine if we’d had more bad pilots than good ones.
It wasn’t supposed to be like this.
The working world the manager was created for was a far simpler place than the one it functions in today. At first, a manager pretty much only needed to be scary. There was no employee engagement, no career development, no servant leadership or performance coaching. It was just a scary guy screaming the dreams out of a group of people with low expectations and nowhere else to go. That scary guy didn’t have to do anything particularly difficult to get people to do the work he wanted them to do. He just pointed them to their spot on the factory floor and said, “stand there and do this as many times as you can before you die”. That was being a manager.
That isn’t the job now. We can’t just be scary. In fact, modern managers must be all things to all people. We must be inspirational, authoritative and organised. We must be inventive, emotionally intelligent, patient and calm. We must be bold, but cautious. We must drive change, but maintain order. We must be selfless, but demanding. And we must be all of these things consistently, because the moment we make a mistake pretty much everyone hates us and loads of stuff goes wrong.
Take a moment to think about the personality traits and skills necessary to consistently be all of those things. I don’t know anyone who is this person. I’m pretty sure nobody is this person. In fact, I believe that if you were to ever meet this person you would know immediately, because they would physically glow. Captain America is this person. Nobody else. But in most organisations today, roughly one in seven employees perform management duties. One in seven. We are organising ourselves in such a way that success depends on one in seven people being better than the best person we’ve ever met, and then we’re surprised when everything is horrible. An entire career of working with and training managers at every level has proved to me beyond doubt that far fewer than one in seven people are capable of doing this job. It’s not even close to that. Have you met people? Most of them are dreadful.
The failure of this approach has been obvious for a long time. Employee engagement studies consistently paint a horrible picture of a workforce who are disinterested in their jobs and distrustful of their managers, and this has been the case for several years with barely any sign of improvement. Almost universally, our attempts to address this problem have centred around spending more and more time and money on trying to improve the managers. We keep trying to make the managers better so they can meet the new demands we place on them. But we keep failing, and the demands keep increasing. What if we’re going about it all wrong? What if instead of trying to make the managers better, we try to make management easier?
I created my company, DoThings (dothings.io), for exactly that purpose. It’s also why I’m writing this book. A few years ago I stepped back from my near religious belief in management and instead of asking myself how I could be better at it, I asked myself how I could make it easier, or simply not do it at all. The result was what I have come to call Minimum Effective Management. This is the absolute minimum amount of management I need to carry out in order to generate the outcomes I want. Working this way has allowed me to create workplaces that everybody can thrive in without the need for superhuman managers whose decisions determine the working lives of everyone else. It’s a way of working that any manager can adopt without needing to learn a single new skill.
I believe management is important. What we do affects the lives of other people in real and significant ways, both in and out of work. And we are failing those people far too often. But it’s not our fault, the job is just too hard now. Unless it’s made significantly simpler, this will always be the case. The approach of trying to improve the managers has failed, because the standard required is unrealistic. What I’ve discovered is that almost anyone can be a great manager, as long as they don’t try to take on the ridiculous level of responsibility we have come to believe the role demands. We’ve been adding new structures to the old foundations of management for decades, when what we really need to do is rip it down and rebuild it from scratch based on the requirements and capabilities of today’s working world.
So that’s what I did. I’ve tried to avoid making this book an instruction manual. I hope that I explain the approach and how I implement it in a way that’s digestible, but it’s not a step by step guide. I’m not trying to tell anyone what they should or shouldn’t be doing - just what I do, and perhaps more importantly, what I don’t do.
This is how I achieve everything traditional management claims it will deliver but consistently fails to. This is the approach I use to be successful without ever feeling pressured, working crazy hours, or dealing with the hassle and stress that managers routinely face.
This is the easy way to do a hard job.
Managing people, projects or teams doesn't need to difficult. DoThings makes management simple.
Ensures everyone always knows what they’re trying to achieve, and gives managers a clear view of how each goal is progressing. DoThings gathers weekly updates from goal representatives and allows all Projects to be aligned to specific goals.
Matches tasks to be carried out to people with the skills needed to perform them. The DoThings dashboard shows who is unavailable, who isn’t working, and the task estimate trends that let you identify who might need your support.
Provides everyone with relevant and useful performance feedback from the people they actually work with. Work centric feedback is gathered from everyone involved in completed projects, freeing everyone from ineffectual performance reviews.