Ok, after all that, how do we actually plan at Bonial?
The heart of our planning activities is the Quarterly Planning which is loosely modeled on Program Implement (PI) Planning from SAFe. During quarterly planning / PI planning, everyone in the product development organization – developers, designers, architects, testers, product managers, operations specialists, designers, etc. – get together for a couple of days to map out their next phase. We do our planning during the previous quarter’s HIP (Hardening Innovation and Planning) sprint, which is sprint 6 of each quarter.
Before I dive into the actual planning days, I should point out that the preparations start several weeks before when the product teams actively work with stakeholders, customer facing teams and the executive team to validates the backlogs against the current company priorities and business realities. The prep phase looks something like this:
- The senior management team and product strategy board review the overall strategy and primary business goals to assess if any change in focus is needed.
- Next we make sure that product and delivery management has the same level of clarity. We get the delivery leads and product owners together and communicate the company goals for the upcoming quarter to them, taking the time to answer questions about strategy, challenges, current market trends etc. Our goal here is to make sure that all our leaders are able to bring clarity to their teams so that local decisions are made with the right context.
- 3-4 weeks before the planning event, the product management team starts curating the backlogs for the different product and system streams. They create a “long list” of major features and work items and meet with stakeholders, customers and Bonial management to validate priorities.
- A week before planning the “long lists” are reduced to “short lists” of the highest priority items. This is probably the hardest part of the process and it requires saying “no” to things… we find that our stakeholders and customers all agree that discipline is needed so long as it mostly impacts other stakeholders and customers. Over the years we’ve tried various formal mechanisms to prioritization – Weighted Short Job First, Feature Bucks, etc. – but in the end we find that different tools are needed for different situations and that, with experience, people often people intuitively know the order.
- Over the next week the product team spends time working through open questions and details while architects and engineers do the same on the technical side. There’s also generally some intense discussions about “bubble” items – features that are right on the cusp of making the list – as well as hot items that didn’t make the list.
I wish I could say that this process was easy. The truth is that a great deal changes in three months – new opportunities and challenges, unexpected curveballs – so we’re constantly challenged to re-assess our priorities with each planning cycle. On top of that there’s a lot we want to do, so we find ourselves often having hard discussions up until the planning day, especially around the “bubble items”. It’s not clear to me that there’s a much easier way – we’re in a fast industry and a complex business – but we try to get better each quarter.
So the primary inputs to planning are a short, discreet, prioritized set of epic-sized initiatives for each team. Most of these are functional but there are usually some architectural or operational topics as well. That brings us now to the actual planning days (typically a Th/F):
- On planning day 1, we start with a team breakfast at 0900 and then a kickoff presentation at 0930. The kickoff presentation covers the big picture goals for the quarter and a quick review of each team’s focus and top items so everyone has context. We also cover logistics – where they can find flip-charts and stickies, who’s in which rooms, etc.
- Following the kickoff (and the kitchen cleanup), the teams go to their planning spaces and get started. Basically, they start with the top priority item, plan it through to completion, and then repeat with the next item. Once they get to the allocated capacity they stop planning. The remaining items simply don’t get done.
- “Full capacity” is an interesting and oft debated question. We have a loose agreement that teams should reserve ~20% for bugs and team discretion and should reserve another ~20% for refactoring and architecture work.
- As the teams are planning they’re also working with other teams on inbound and outbound dependencies. We’ve organized the teams to minimize dependencies but they’re still a fact of life. The teams negotiate how to support each other based on overall priorities and goal (ref. the “context” from the breakfast). Any un-resolved conflicts are escalated or raised at the review meeting (below).
- At 4PM on the first day the scrum masters and other delivery managers get together to share their current plans with the group. We use a web-based collaboration tool that allows each team to put virtual stickies on their assigned row with different colors illustrating milestones, spikes, tasks, releases, etc. Dependencies are made visible by connecting two stickies with a line.
- Putting everything together allows us to visualize the major streams, see what made the cut and what didn’t, and address any dependency challenges or conflicts. Generally there are several to-dos coming out of the review, primarily around working through dependencies or going to business stakeholders for clarification.
- The morning of day 2 is primarily for making adjustments from the previous day, collaborating with other teams where combined efforts are needed and tying up loose ends. Most teams wrap this up pretty early and then get back to their HIP sprint, others need most or all of the day.
- At 4PM on day two we grab a beer and get back together in front of the stickies board to review any changes from the previous day and discuss any unresolved conflicts. This exercise typically goes much faster than the day 1 review. At the end we check confidence and then head home for a much needed break.
Here’s the final plan from last quarter.
It looks complex and it is complex. Without developing our process, our teams and ourselves over the last couple of years we’d be hard pressed to effectively manage this complexity.
Following the planning we package up the plan and communicate a high level, consumable version for to the business and stakeholders. We emphasize that these are our current targets and best estimates – this isn’t a contract. We’ll do everything we can to stick to it but we may be surprised or, in good agile fashion, we may decide to make changes as the situation evolves.
So that brings us full nearly full circle. I started this series during our last planning days and expected it to be a quick post. As I pulled the thread, however, I realized how much work had gone into our evolution in this area. I could also see that a high-level flyover would leave huge gaps in the journey, so I decided to fly lower.
You can see by now that undertaking a journey like this takes a fair amount of time, experience and honest self-evaluation, regardless of the specific methodology you choose. That said, the investment is worth it, and a great deal of value can be realized even early in the process.
In Bonial’s case, we had a few advantages as we set off on the journey. First, everyone was open to change, even when the change made them nervous. The importance of this can’t be overstated. I’ve lost count of the organizations I’ve worked with in which the teams had no motivation to improve (though paradoxically most of them complained constantly about the status quo). In the end the team has to want or at least be willing give it shot. Which brings us to point two…
Second, we had good people and a healthy culture. Where we lacked in experience and skills, we more than compensated by having a team of smart, energetic professionals. With good people, you can generally solve any problem.
Last, but not least, we have a skilled, SAFe-trained Release Train Manager to drive the process (though her role has evolved). Even the finest orchestras of the world don’t play on they own- they have a conductor. In our case the conductor/RTE ensures:
- The stage is set. Everybody knows the timing, their roles and the rules of the game and All the needed supplies are in place and easily accessible to everybody.
- Short (really short!) list of candidates for planning is finalized before we start. The RTE ensure we’re observing Work in Progress (WIP) constraints, which are critical to maximizing throughput. As she often says, “Let’s stop starting things and start finishing things instead.”
- People know who to go to regarding priorities and impediments during planning.
- The planning is properly wrapped up, all roadmaps and agreements put together, and outcomes are properly communicated to all key stakeholders.
- Solid retrospectives are done both on the quarter itself as well as the planning process so we can continue improving.
Whew! That was a lot of writing for me and reading for you. Kudos if you made it this far – I hope it was worth it. So now you know how we do it – feel free to share your own stories about how you and your teams plan. Best of luck in your own journey!
(Special thanks to Irina Zhovtobrukh (the mysterious RTE) for her contributions to this post as well as teaching us how to “conduct” better planning evolutions.)