Scrum is like communism. It doesn’t work. Myth 4

One of the common myths in Scrum is that since we’re doing Agile, we don’t need no planning. Um, and 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, uh, 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.

Okay, 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?

And 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 upfront 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 and their business, um, 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, um, uh, uh, uh, 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? And that generates these big theme buckets of work that many hundreds of teams might work in, um, to actually, you know, make progress towards those big themes.

But you’re looking that far out, you’re planning that far out. You know, um, probably what your goal, your product goal, if they call it that. But whatever their theme for, uh, their primary theme for us each of the seasons, they probably know what they’re going to be 18 months out for the season that we’re in. You know, we’ve probably got 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 maybe have, you know, here’s some Sprint goals we might tackle, here’s some product goals we might look at, um, in that next seasonal bucket. And then the season after that, we don’t have any of those detailed just what’s the big theme.

And you can see how they did that. They did a, uh, one recently, uh, 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 kind of spawned 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’s the most people interact with the operating system through Office. So if you’re talking about, um, 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… 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, uh, 1024 at least, uh, 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 are happening. We just probably don’t store them in a Gantt chart. Thanks for watching the video. If you enjoyed it, please like, follow, and subscribe. I always reply to comments, and if you want to have a chat about this or anything else Agile, Scrum, or DevOps, then please book a coffee with me through Naked Agility.