Debunking the Top 5 Myths About Scrum: Unlocking Agile Success in Your Organisation

Scrum is like communism; it doesn’t work. This is a phrase I hear often from folks who have been unable to adapt their systems of work to incorporate the core philosophies, theories, and practices of Scrum. They sit and look at the signals coming from Scrum that things are broken and don’t work like they’re supposed to work and do nothing but say, “Scrum is like communism; it doesn’t work.”

Hi, I’m Martin Henwood, owner and principal consultant at Naked Agility. I’m a professional Scrum trainer with Scrum.org, a professional Kanban trainer with Pro Kanban, and I’ve been a Microsoft MVP in GitHub and Azure DevOps for 15 years.

In this video, we’ll explore five myths from Scrum that inhibit its adoption. From language definition inflation to cognitive bias, here are the top five myths that result in the idea that Scrum is like communism.

There’s a myth in Scrum that you spend more time talking than doing. I see this quite a lot; people talking. Usually, people are using old school terminology. When you hear them talking about that, you hear them talking about ceremonies rather than events. One of the main reasons why Scrum doesn’t call the activities ceremonies is because it’s ceremonies. We get together and nothing happens; it’s a ceremony. It’s something we do that’s perhaps the same every time, and there’s no actual outcome to a ceremony apart from maybe people have some jollies and they feel good.

The reason Scrum calls them events and also not meetings is that something’s supposed to happen there. Every single one of the Scrum events serves empiricism; that’s their purpose. You’re going to inspect something and adapt something. If you’re not adapting, there’s no point in being there, there’s no point in having it, there’s no point in doing it. Their purpose is to adapt.

For example, at your Sprint planning, you’re inspecting your product backlog and your product goal, and you’re adapting your Sprint backlog and your Sprint goal. That emerges through that conversation. But at the end of your Sprint planning, you should have a Sprint goal, you should have selected backlog items, and you should have some kind of a starter plan to complete them. If those three things don’t exist at the end of Sprint planning, there was no point in having it. That’s what it’s there for, so that we understand what it is we’re going to take into the next Sprint.

So that we can communicate that perhaps with other people. What’s our goal for this Sprint? What are we trying to achieve? How do you get the stakeholders to actually turn up for the Sprint review? Well, you have to give them something that they’re interested in coming in providing feedback on; that’s your Sprint goal. And that’s just one of the events in Scrum.

Every single daily Scrum is only 15 minutes. How does that add up to a boatload of meetings? At most, 15 minutes per day where the team gets together and plans the next 24 hours; that’s its purpose. You’re inspecting your existing Sprint backlog and you’re adapting that Sprint backlog based on what you learned in the last 24 hours. You might have learned some stuff from actually working on the product, what can and cannot be done. You might have gained more information and insight from other stakeholders and collaborating with the business and doing analysis on what it is you’re going to work on. That means that something you’ve got in the Sprint needs to be taken out because it’s no longer viable, or something else needs to be brought in because it becomes part of that story of what it is you’re trying to achieve that Sprint.

That’s your daily Scrum. It’s not an elaborate status event; it’s not a time that you’re wasting. It’s where you’re maintaining the transparency that is required to be able to inspect and adapt. You’re serving empiricism, and all of the Scrum events serve empiricism.

One of the common myths in Scrum is kind of a proxy myth. This proxy myth is, “Why do we spend so much time working on story points?” When story points measure complexity and not time, and then we have to figure out how many story points fit in a Sprint. I 100% agree with that; that part is not a myth. The bit that’s a myth is that story points are even a Scrum thing in the first place. They’re not. Story points have nothing to do with Scrum; it never has, apart from as a practice, potentially a complimentary practice that teams choose to take on in order to get to an outcome.

When you find complimentary practices are not adding value, you should be stopping doing them, not continuing with them. So if you’re in that position where you find that story points are not adding value, great, stop doing them and choose something else. The guy that invented story points, or that is generally accredited with inventing story points, has a public apology online for creating them in the first place because of how they tend to be used within organisations as a pseudo proxy for time to beat developers around the head with. They were originally invented as a reasonable way for developers to sit and have a conversation and figure out what they don’t know. That’s the purpose of story points.

We can all get together; we maybe use another complimentary practice called planning poker. All that really is, is we keep our cards to ourselves. We’re not going to tell each other what story point we’re going to pick, how complex, t-shirt sizes, right? Whatever you pick, how complex this thing is. You’ve got one developer that says this is a small or a one, right? You’ve got four developers that say that this is a five or a medium, and then you’ve got one developer that says this is an extra large or a 21. The idea is, what do they know that we don’t, or what do we know that they don’t? That’s the purpose of story points and complexity conversation.

It should be used almost solely during refinement in order to enable teams to right-size their backlog items and decide, do they fit in a Sprint? Do we understand them, or do we not? After that, delete the numbers; they’re useless. Don’t use them anymore. That’s their purpose for that one context; don’t bring them into the wider context.

One of the common myths in Scrum is that it is really a forum for micromanagement. There’s a core test for this in your team. It is a myth, right? But it’s a reality for many teams. So is it a myth or is it not a myth? That is a matter of perspective. However, I would point out that it’s not Scrum. So it’s a myth in the context of Scrum, but it’s not a myth in the context of how lots of organisations and teams approach Scrum.

Most organisations approach something like Scrum from their traditional top-down steering-based perspective, and they want to tell teams what they’re going to deliver in a Sprint. So you walk into Sprint planning, and the product owner or the tech lead or the project manager, or whoever, the Scrum Master—the worst one—but the Scrum Master says, “Here’s a list of things we need you as a team to do this Sprint.” As soon as that happens, not Scrum. We’ve gone out of the bounds of the Scrum guide. Who decides what we work on this Sprint? The developers. Who decides how we work on it? The developers. It’s not anybody else because the developers—that’s the core reason why they dislike that approach. It’s the developers that understand the nuance and intricacies of the technical challenges of actually delivering on the work inside of the Sprint. Nobody else can understand that nuance because they’re living it, right? They’ve got skills that I don’t have as a manager or as a product owner. They’ve got an understanding of the product and the technologies that we’re using to deliver that product, the tools and techniques that we’re using. They’re best placed to make that decision.

Now, can the product owner say, “Oh my goodness me, we’re in a difficult place because we’re not working through the work that we need to deliver as fast as we would like?” Yeah, absolutely, they can have that conversation. And they can have a conversation with the developers about how the developers might choose to cut corners in order to accelerate work. But it must be done with their assent. If the developers say no, then we can’t work any faster because we might be taking on too much technical debt. For most businesses, all technical debt is a risk to the business, and most businesses don’t understand the context of technical debt enough to make an informed decision on whether they should accrue it and how they should pay it back. That’s why we have hired these technical experts in order to deliver our product, and we should trust their understanding and view of the product in order to do that.

So I would say that it is a myth that anybody should be telling the developers what to work on and when to work on it. But I do understand that lots of organisations don’t understand how to let go of that control and are not yet ready for Agile.

One of the common myths in Scrum is that since we’re doing Agile, we don’t need planning. That is just utter garbage. Scrum, for example, is all about planning. We have Sprint planning, we have refinement, which is a type of planning, we have daily Scrum, which is about planning the next 24 hours, we have a review where we review what happened based on the plan and adapt the plan going forward into the future. It’s all about planning; it’s all about getting things right. It’s not about planning upfront; it’s not about spending too much time upfront planning.

But there’s a phrase which is often misinterpreted, which is we should do just enough planning. We should do just enough, right? If we do too much planning and we plan a bunch of stuff that we end up not doing because it gets taken out of the backlog, then that was waste. Maybe that was okay waste; maybe we needed to do that planning in order to find out other stuff and have that thing removed. Or maybe that was a little bit too much. Is there a way that we could have learned the same thing that we learned doing that planning, doing something a little bit less?

The converse of that is if you are building—I’m trying to think what you could be building that needs lots of—let’s say you’re working on Windows and you’re one of two and a half thousand software engineers. How many teams is that? Metric assloads of teams, right? If you’re that many teams working on one product, then you’re going to need to plan, right? You’re going to need to understand what’s happening going out into the future. You’re going to need to coordinate across hundreds of teams on direction and strategy. I mean, most of that in Scrum is done through communication, right? Vision, product goal, Sprint goal, right? You’ve got that communication chain. How do we all get behind the same thing?

But we’re trying to have as light a plan up front as possible within our context. So even if I was working on the Windows team, I would probably have a roadmap. I’m probably going to have a roadmap for my current six months. If you’re not familiar with how Microsoft product teams have created their own scaling framework around what they need in their business, it’s often called the season-based model because they talk about the spring update and the fall update for their really big products. Many of their products do continuous delivery, but they’re talking about a long-term view of what it is they’re trying to achieve, and that’s about six months. They look three seasons ahead, so they’re looking 18 months out. They have an 18-month plan, and I’m using air quotes because it’s probably pretty vague, right? If you’re looking at that third season out, things are really big, right? You might have themes rather than individual things you’re going to deliver. You might be looking at what are the investment opportunities, what’s happening in the market, where do we need to get ahead of the competition going over the next 18 months? That generates these big themes, buckets of work that many hundreds of teams might work in to actually make progress towards those big themes.

But you’re looking that far out; you’re planning that far out. You probably know what your goal, your product goal—if they call it that, but whatever their theme for each of the seasons is. They probably know what they’re going to be 18 months out for the season that we’re in. We’re probably going to have backlog items and actual things we’re going to tactically deliver for the next three, four, maybe five Sprints. Maybe, and then in the next bucket, we might have, you know, here’s some Sprint goals we might tackle, here’s some product goals we might look at in that next seasonal bucket. And then the season after that, we don’t have any of those details, just what’s the big theme. You can see how they did that. They did one recently—I’m saying recently in the last five years, right? Recently—that was called the Creators Update. So when they were talking to us, the general public about the products, they talked about the Creators Update. We’re going to invest in opportunities to make our systems and products and services better for creators. That was an organisation-wide theme that can spawn out of the Windows team. But think of all the things that impact. Not only does that impact on Windows, the operating system, right? But what about Office? It impacts most people who interact with the operating system through Office. So if you’re talking about pen support, right? You’ve got the actual pen touching the screen on the Surface and the number of levels of capability that it has in that world. You’ve got, so that’s hardware; that’s the Surface hardware and perhaps third-party vendor hardware collaborating with. Then you’ve got the application that you’re actually using that is interpreting those signals. So that could be Microsoft’s applications; it could be Office; it could be third-party software. And then you’ve got the underlying operating system, which is providing support for, I think it used to be 256 levels of pressure, and now it’s 1024 at least levels of pressure that you can put on the pen in order to get that, you know, I’m drawing on the page type of feel. And that requires collaboration, looking forward into the future. What do we need? What are we trying to achieve? All of those strategic things happening, we just probably don’t store them in a Gantt chart.

One of the myths in Scrum is that we have no governance. This kind of leads on to the bigger myth that just because it’s not in the Scrum guide doesn’t mean you’re not supposed to do it. Scrum does absolutely have governance; it has small amounts of governance baked in. But in general, you need governance to build your product. So it’s kind of correct to say Scrum doesn’t have a lot of governance. There’s a very small amount of governance built in, but if you want to be successful at building products—if you’re, for example, building products within the healthcare space—then you’re going to have to worry about your ability to support HIPAA, to support the regulatory compliance that comes from the outside. That’s governance imposed on your organisation from the outside that you have no control of. You’re going to have things that your organisation does internally. Perhaps your organisation has usability guidelines; perhaps they have UX guidelines for how all our products’ UX is going to function so that anybody interacting with our software already knows how it’s going to work because it follows the same rules. Then that’s internal governance that has been applied to your product.

You maybe have business rules; that’s another form of governance. You might have particular ways in which you interact with the market as a business. That’s one of your unique selling points, your unique engagement points with the market, and those ways of working have to be implemented in your systems in that way. That’s internal governance. Just because Scrum talks about minimising that governance doesn’t mean it’s not there. You just have just enough governance to support the business need. It’s when you have way too much governance that you start running into a problem. That’s why in very large organisations, for example, banks, they really struggle to move towards Scrum and Agile practices because they’re encumbered by the baggage that they can’t put down. Royal Bank of Scotland in the UK was, I think, the first bank in the world; it’s currently the fifth biggest bank in the world, and they’ve been going for over 200 years. Can you imagine the procedural and compliance baggage that organisation has? Many of it around for no other reason than nobody’s revisited it in a long time. Nobody’s challenged it in a really long time. How many policies and procedures do you have in your organisation that nobody knows where they came from or what they’re for or who owns that policy or procedure or why, right? It’s just the way we do things here. Those are the things that we want to challenge. We want to challenge anything that gets in the way of inhibiting our ability to deliver value. Those are the things we want to prevent. Those are the policies, practices, and procedures, the governance that we want to reduce to the absolute minimum.