One of the most pervasive myths I encounter in the world of Scrum is the notion that Agile means we can forgo planning altogether. This idea is not just misguided; it’s downright detrimental to the success of any Agile team. Let me clarify: Scrum is fundamentally about planning.
The Importance of Planning in Scrum
In Scrum, we have several key events that revolve around planning:
- Sprint Planning: This is where we define what we aim to achieve in the upcoming sprint.
- Refinement: Often overlooked, this is a crucial type of planning where we prepare our backlog items for future sprints.
- Daily Scrum: This daily meeting is all about planning our next 24 hours and ensuring we’re aligned.
- Sprint Review: Here, we assess what we accomplished based on our initial plan and adapt our strategy moving forward.
So, when someone says we don’t need planning in Agile, I can’t help but shake my head. It’s not about eliminating planning; it’s about planning effectively and efficiently.
Just Enough Planning
You may have heard the phrase “just enough planning.” This concept is often misinterpreted. The goal is not to eliminate planning but to find the right balance. If we over-plan and end up with items that are removed from the backlog, we’ve wasted time and resources. However, sometimes that planning is necessary to uncover insights that lead to better decisions down the line.
Conversely, if you’re part of a large team—say, working on a product like Windows with thousands of engineers—you’ll need a robust planning strategy. Coordination across numerous teams is essential for maintaining direction and strategy.
Planning in Large Teams
In such expansive environments, communication becomes paramount. Here’s how it typically works:
- Vision and Product Goals: These guide the entire team and ensure everyone is aligned.
- Roadmaps: Even in large teams, having a roadmap for the next six months is crucial. This helps in visualising the direction and objectives.
For instance, Microsoft employs a season-based model for their product teams, where they plan for three seasons ahead—roughly 18 months out. This long-term view allows them to identify major themes and investment opportunities, which is vital for staying competitive.
The Role of Themes in Planning
When looking at the future, especially 18 months out, the specifics can be vague. Instead of detailed tasks, teams often focus on broader themes. For example, during the Creators Update, Microsoft communicated a clear organisational theme aimed at enhancing products for creators. This theme not only influenced Windows but also had implications for Office and hardware like the Surface.
This kind of strategic planning requires collaboration across various teams and disciplines. It’s about understanding what’s needed to achieve overarching goals and ensuring that everyone is on the same page.
Conclusion
In summary, planning is not the enemy of Agile; it’s a vital component of it. The key is to strike a balance—plan enough to provide direction without getting bogged down in unnecessary details.
If you found this discussion helpful, I encourage you to engage with me. I always welcome comments and questions, and if you’d like to delve deeper into Agile, Scrum, or DevOps, feel free to book a coffee chat with me through Naked Agility. Let’s keep the conversation going!
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.
