Note: this is part one of a two part series. See part two 
here, which goes deeper on what to do instead.
Throughout my career, I have seen this process called quarterly planning become more and more popular across multiple companies for reasons I don’t understand. Let me summarize how it typically goes:
- The company comes to a complete halt for two weeks as everyone does their “quarterly planning” at the same time.
- Everyone then shares their quarterly plans for transparency for everyone.
- None of the quarterly plans come true unless you heavily sandbagged (an anti-pattern).
- Repeat.
Or click here for this hilarious Instagram Reel describing this process (thanks Christina Tennyson for sharing this with me).
Why don’t the plans come true? Lots of reasons! At a high level, quarterly planning could not be a better example of the now-antiquated waterfall methodology:
The waterfall model is a breakdown of project activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks
And what’s the issue with that? Well, keep reading:
In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction (“downwards” like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. The waterfall model is the earliest SDLC approach that was used in software development.
I don’t believe I need to harp on this topic further – the Agile Manifesto was created decades ago to help us break away from this Software Development Life Cycle (SDLC) approach, and it’s been written about ad nauseum (each word is a separate link). Rather, the issue is that in the same breath, companies will declare that they are “agile” as they are coming up with a quarterly plan that locks up 100% of their capacity for 90 days. And they do this in the first half of the last month of the quarter, meaning it’s more like 104 days. Say it with me: that is not agile.
OK, but that still doesn’t say why the plans don’t come true. Let’s walkthrough a not-so-hypothetical example. Imagine your company does the quarterly planning process. So for two weeks, every team asks every other team what they need. Imagine being responsible for your own team’s quarterly plan. Where do you start? Well, you might reach out to all of your downstream dependencies and ask for feature requests. But you also should work with your own engineering team to ensure that you aren’t ignoring operational excellence work, such as improving your team’s oncall situation. But now imagine all of your upstream dependencies coming to you at the same time for feature requests. And to make it even more fun, let’s imagine you’re a platform team with hundred of customers. That is unmanageable in a two-week planning period. You will ignore some customers, forget others, and be unaware of a feature request you have for an upstream dependency, being forced to wait another 90 days just to ask for it. To put it simply, this process does not scale.
But let’s continue with this example. Even if you do this process perfectly, let’s imagine that in three weeks (the first week of the new quarter) the quarter is now “locked” but your team discovers a significant bug in your platform. You swarm to fix it, but now your entire quarter’s plan is off by a week. What do you do? Well, you need to communicate what is getting cut – standard change management procedure. So not only was the original planning exercise wasted effort, but now you have to add on to that waste with this change management effort – all before the first sprint of the quarter is over.
So you do the change management, and two more weeks go by. Then, another team comes to you with an urgent priority for a top project at the company. If you won’t support their use case, they will escalate to C-suite for a decision. Now what do you do? This is a standard reprioritization situation that I won’t go into detail here, but let’s say you do some analysis and realize that this work will provide more value than your original plan. So, you reprioritize to support this new use case. But wait, there’s more! You need to again go through the change management process to change your plan 😔.
This sounds like a contrived example, Straker. Au contraire, my dear reader! As this is a true (but generalized) story I have lived more than once as a TPM for platform teams. When you have hundreds of clients, you inevitably miss reaching out to some (or their leads are on vacation during the two-week window). Even more likely, they don’t all think of everything they need from your team, as they’re focused on their own plan!
Well, there’s a simple trick, Straker – don’t reserve 100% of your capacity. Instead, reserve 50%. Yes, this is a good trick if you truly cannot break away from this waterfall-in-disguise-practice. My only advice here is not to hide that you’re doing this (which could be interpreted as sandbagging), but to instead be upfront about this. Explain why you do this, and when you do reviews of your quarterly plan – which yes, is another part of this process that should exist – share the value of this practice.
So what should be done instead? Typically, quarterly planning is done because someone in the management chain wants transparency into what teams are working on. While I believe in this transparency, a plan is not what a team is working on; it’s what a team plans to work on. Instead, focus on what the team is working on. This means focusing more on the output than the input.
For example, if you do sprint demos, focus on these rather than the plan at the start of the sprint. Focus on what’s been accomplished, and like any standard sprint standup, share if there are any blocking issues that need to be raised. You can give a lightweight what’s next?, but it is not meant to be a waterfall-level plan. A simple plug for expected topics in the next session will suffice, or if you leverage OKRs, you can mention the objectives (which is different than the plan). Put another way, you should leverage regular reviews for the desired transparency, not the plan.
And what cadence should this be done at? That depends on your audience (and how expensive they are 🤑). You can do this fortnightly if desired, but that can be too much detail for C-suite attendees in larger companies. I argue monthly is a good cadence – if you aren’t delivering value worth sharing on a monthly basis, you have some other problems to figure out. You could go as long as 6 weeks, but I wouldn’t go longer; quarterly is simply too long, and is more useful for things like metrics reviews (which need time to be impacted via changes).
3 Comments
Leave your reply.