As a follow-up to 
Please, Stop Quarterly Planning: It’s Just Waterfall in Disguise, I want to share what to do instead. I touch on this at the end of that post, but it felt worthy of its own, more detailed post. For details about why I don’t like quarterly planning, see that first post. But if you want solutions to replace it with, well, this post is for you.
So, what should we do instead? Two things:
- Embrace a more flexible planning process, such as Kanban (just-in-time), and
- Drive accountability through recurring business reviews every 2-6 weeks.
With these two things, you transparently cover the desired feedback cycle that quarterly planning provides while remaining truly agile. In other words, you create a simple, sustainable two-step flywheel. Let’s break these two components down.
Flexible Planning
Planning process is an industry challenge right now, as waterfall-style planning processes of one quarter+ are rampant despite being fundamentally anti-agile. “But we’re already agile!” you might scream, to which I will reply with this Martin Fowler quote from 2018:
In the old days when we talked about doing agile, there was always this pushback right from the beginning from a client, and that would bring out some important conversations that we would have. Now, they say, ‘Oh, yeah, we’re doing agile already’, but you go in there and you suddenly find there’s some very big differences to what we expect to be doing.
The State of Agile Software in 2018
It’s sad, but in my experience, this statement has only gotten more and more true in the past five years. And before any agile coaches think “but we can train this!” I will say – go read the Agile Manifesto. Go on, I’ll wait. Now that you’re back in less than 30 seconds (as that’s how long it takes to read), you have all of the training you need to be agile. Yes, it’s that simple. Really. Yes, I touched on this in my last post, so apologies for the repetition – it’s just that important.
OK, but what does this have to do with planning? Well, if our planning isn’t agile, then our software development can’t be either. And this is where I see the two butting heads – but rarely addressed – in the industry today. If you are in this situation, then I encourage you to speak up and address your planning process that forces you into a waterfall development model; I am not going to discuss how to make your development model fit your waterfall planning process 🙃.
A flexible planning process, sometimes called “continuous planning,” means you aren’t trying to set perfect dates for every project on a recurring basis (often quarterly). When you do this, you are setting yourself up for more work with required change management every time the plan changes (and it will change if it’s a quarter+ long plan). Flexible planning means you aren’t trying to estimate everything you’re working on perfectly, either – if you’re making a Gantt chart, you’re not doing flexible planning.
Instead, with flexible planning, you focus on prioritization rather than filling every bit of capacity over a set period of time. What are you going to work on right now? Everything else is in your backlog. Your engineering team can then follow standard agile procedures, such as breaking up priorities into bite-sized chunks.
So projects don’t have dates? Dates and estimations are two different things. Sometimes, dates are real things. Like Black Friday, Cyber Monday, Christmas, New Year’s Eve, or the Super Bowl. These are all dates that aren’t changing, that perhaps you need to account for, such as scaling to handle demand during these peak days.1 In these cases, the dates are important. However, such dates do not exist for most software projects, and arbitrary dates should be avoided when possible. Again, focus on the priorities.
Estimations can still exist with flexible planning, but they can be done differently than having a fixed date for every chunk in a priority (Gantt-chart style). After all, such estimation may impact your prioritization! But you can now avoid wasting too much time chasing your own tail to make estimations accurate – something I have found to simply not be worth the effort. For example, you can compute an expected date range of completion, perhaps using a Monte Carlo simulation on past data of how long it takes to complete chunks. Or you could add a confidence score with estimations, increasing the confidence as you get closer to the project complete date. The point is, once you break away from trying to allocate all capacity in a fixed time, you have options on how to still communicate what you’re working on. Admittedly, this is a very Kanban-like mindset over a SCRUM mindset; for information on how Kanban can be an improvement over SCRUM, see this short case study.
But how do you coordinate with dependent teams then? When coordinating with other teams, you should still be as flexible as possible – after all, they have the same challenges that you do with planning and estimations! This can be as simple as “Hey marketing partner, here’s our upcoming priorities that we’re working on. I think the one highlighted may want a formal press release and perhaps be a part of an advertising campaign in the future. What do you think?” You can share your estimate when asked for, which can be as lightweight as “we expect to launch v1 in the upcoming quarter.” If you don’t have an unmovable fixed date, such communication does not violate flexible planning.
But what if you keep changing priorities and nothing ever launches? This thought is catastrophizing; even if you have a Waterfall plan, making it immutable is a sure-fire way to lose. While I’ve worked in environments where you plan out the next quarter or more, I’ve also seen them frequently change within the first month, and they always change by the end of the fixed period (which in my experience has been 1-2 quarters). And this is OK. I’m saying such change is healthy for business survival, so we should stop wasting our time with plans that will never come to fruition.
In summary, with flexible planning, you need to have a well-groomed backlog; you should always know what the high priority upcoming items are for the team to work on. However, when you get a new request, or a new technology is made available – cough ChatGPT cough – it is acceptable for such new items to be at the top of the queue, rather than the back. When the team has the bandwidth to start working on a new item, the prioritization decision of what to work on among high-priority items can be made at that time; not before.
Recurring Business Reviews
So, what’s a recurring business review? They’ve become ubiquitous in the tech industry, with acronyms like WBR (Weekly Business Review), MBR (Monthly Business Review), and QBR (Quarterly Business Review) all existing out in the wild.
Are QBRs the same thing as quarterly planning? No; they focus on driving accountability through what’s been accomplished rather than what’s coming. Sure, you could have a section on what’s coming, but that would be an add-on, not the primary focus; this distinction is important, and is why recurring business reviews are separated from planning.
And what frequency should I have my recurring business reviews? In Please, Stop Quarterly Planning: It’s Just Waterfall in Disguise, I mentioned that quarterly cycles were too long for any reasonable agile cadence. I instead recommend a single cadence somewhere in the 2-6 week timeframe.
So, what should I include in my recurring business review? Well, first things first: thanks to Will Larson for already providing us with a public template. I think this mostly gets things right. Recurring business reviews should share out metrics and any goals or budgets that you are working backwards from. And as with all meetings or documents you produce, you should communicate to your audience to avoid the following situation:
So, what do you want your audience to hear? The pain points/big rocks you’re dealing with are important. Is a dependent team giving you trouble? This is your time to talk about that. Like blameless postmortems, this doesn’t mean this is your time to personally insult them. However, the issue with the dependency is worth highlighting; perhaps senior leaders of the respective organizations can resolve the issue. Lessons learned that you want to share with the company are another important area to cover – this is your time to help advance the company, not just your team!
And what is the typical audience? It is important to note that such reviews are a share-out, perhaps to your senior leadership, stakeholders from other organizations, or both. I’ve seen it all, so it is important to find what works well at your company. Additionally, you should be reviewing things like key metrics with a smaller audience internal to the team on a more regular basis (1-2 weeks); you don’t want your own team members surprised by what is shared in the larger, externally-facing business review! I’ve seen teams connect this smaller, internal review with their demos (usually every two weeks). By aligning these reviews, you create a great opportunity to comingle functional organizations, such as engineering and product, and do lightweight attribution behind metric movement (for example, seeing a clear metric improvement correlated with the launch of a new feature that you then demo or demoed previously). By doing this more frequent internal review, you setup your larger, externally-facing business review; take the pieces that you want to share with a broader audience.
Back to the template document: notice what isn’t in it. The template is not a status update of all of your projects. It has a recommended 3-page maximum (excluding images). While those that know me know my general sentiment around page limits – ha. ha. ha. – I do think such recommended guidelines are useful. Your audience doesn’t have the boots-on-ground context that you have, and the business review is not the time to try and give them that. It is a review of a summary; nothing more. The nice thing about Will Larson’s template is that it covers all of this. The only thing I’ll add is this is but a template; as with all templates, you should adapt for your own organization’s needs. The example I gave earlier about having a section on “what’s coming?” would be such an adaptation.
Putting the Two Together
When you combine flexible planning with recurring business reviews, you get a beautiful flywheel. What you deliver and learn from said delivery is reported on in your recurring business review, enabling others such as dependent teams and your leadership team to give feedback. Since your plan is flexible, you are able to take this feedback into account for the next step in your plan. Then rinse and repeat; the flywheel can spin indefinitely.
Appendix: Good External Resources
These are other relevant articles I found after writing this post. I will update this in the future as I find more, so you may notice this change:
- The Beautiful Mess 2-6-4-1: another post with an alternative to quarterly planning.
- Continuous Product Delivery: Why It’s Critical to Release Frequently – while quarterly planning doesn’t mean release quarterly, it often turns into large releases rushed at the end of the quarter. If you start by embracing a continuous delivery mindset, continuous planning will make more sense as you can then react to lessons learned from more frequent releases quickly.
Footnotes
- Amazon.com had to scale for most of these, and Facebook Messenger and WhatsApp had large peaks on New Years Eve to handle as well. ↩︎
2 Comments
Leave your reply.