The rise and rise of Quarterfall

During the year of 2017 I broke five bones (3 ribs, my collarbone and my wrist) all on separate occasions. I ride mountain bikes often (or at least I did until I recently had twins) and I love riding the steep, technical and rooty trails that Wellington NZ has in abundance.

My first crash wasn’t hugely noteworthy. My front wheel slipped on a wet root, I fell and hit my sternum on my brake lever. It wasn’t disastrous, I kept on riding and apart from some pain anytime I sneezed over the next 6 weeks I was physically fine.

It did, however, slightly shift how I rode. I was less confident when riding the more difficult sections of trail I used to love. As I came up to one of these sections, I tensed up and became a bit more conservative. I started planning out what I’d do for the whole section step-by-step.

“I’ll put my front wheel there, unweight over these wet off-camber roots there, get off the brakes for this wet rock here and miss that rut with my front wheel at the end”

I knew what I had to do for the upcoming section of trail, movement by movement.

This approach didn’t work out well. My next accident followed soon after. This pattern continued and by the end of the year I’d had two more serious crashes - one of which involved surgery and a longer period of rehab.

I’d accidentally introduced an inflexibility that increased my risk in how I ride. I’d begun to overplan how I’d behave in certain situations which made me react badly when things inevitably would go wrong. My tire mightn’t behave how I expected it to when I crossed a root, a rock might give way and move slightly and my plan quickly became irrelevant. But because I’d committed to it I’d try to stick to my plan despite my changing circumstances.

By focusing too much on risk I’d lost my ability to react in the moment and make the necessary steps when conditions inevitably changed and my plan was no longer valid. The comfort of my well constructed plans stopped me from being in the moment and fixing problems as they arose. That resulted in more trips to A&E.

Lately I’ve seen more organisations adopt larger and increasingly involved planning practices. Multi-week quarterly planning and massive thousand-person Big Room Planning events are commonplace and perceived as "best practice". Often these arise as a response to something going wrong. A few releases running late and missing important dates... New functionality not being communicated to sales or customer support and confusion being caused...
A natural response to these things happening is “if we’d planned our quarter properly, this would never have happened”.

Over time, these larger planning events rarely get smaller and lighter. Larger and larger event spaces are being booked to host these events, and more and more balls of string are being required to manage dependencies between the teams filling these halls. More goal frameworks and metrics get added. The process grows.

These are recreating yesterday's fragile and rigid organisations with modern window dressing. Safe^😉 to say, these are nothing but quarter-long waterfalls.

The silver(ish) lining

There IS a thin sliver of value in these complex big batch planning events however. People DO learn about what’s important to do for the next 3 or 6 months. People DO learn about the problems other teams are going to be working on. BUT the cost of this is rigid, overcommitted plans that offer comfort but remove the ability for teams to solve problems in real time(more about this below).

Don’t misinterpret this post as saying “all planning is bad” or “all quarterly planning is wasteful”. Agile falls to bits without good planning. But it’s important to tread very carefully in the resolution you expect those plans to have and what you expect to happen to those plans once you leave the room..

Doing something about it

If you have a habit of Quarterly Planning or Big Room planning in your organisation I suggest introducing a frequent retrospective as part of the process to check in on how it’s going. Build this in so that you have an opportunity to actually keep your process minimal and support good outcomes in your teams. Of course, every organisation is different and a 'right-sized' planning process won't look the same for everyone. You'll need to learn what works and what you can trade off. I've found it useful to discuss the follow topics:

🧘‍♂️Flexibility and Effort

In an agile organisation teams can react to the changing environment around them and to what they learn about customer problems as they try to solve them. The more effort you put into creating a plan, the more likelihood there is that you’ll blindly follow that plan regardless of what you learn (see above for where that can get you). Are the plans you’re creating light enough to allow you to throw them away when you learn that they’re not the right path 2 months from now? If not, your planning is compromising your business agility and effectiveness.

🤝Commitment and Reality

You know the least about doing something new right before you start. Because of that it’s impossible to know how difficult something is going to be, especially when it’s a few months away and you don’t know what is going to happen in the meantime. Avoid making any commitments as a result of your big planning process. You might have a good idea of what you’re going to do next week, but if you think all teams can commit to what they’re going to do upfront for a quarter you’re setting them and yourself up for failure.
Create the space for teams to be able to change their plans as they learn. I've seen teams ignore signals and feedback and build what they've committed to, rather than what their customers need.

📚Learning and appropriate detail

Planning IS doing. When you dive into the detail of planning how to do something that IS the work. When you ask a team to plan out how they’ll solve a problem or build a product they’ll need to model, learn, prototype and ideate together to figure out how to do it. This is time consuming and also that information is very temporary. Those tasks and shared learning quickly go out of date. For that reason, don’t expect your teams to plan out in detail anything that they might do in 3 months time. That quick list of tasks for some feature they might never build is expensive and irrelevant when they come around to working on it.

🌊 Managing dependencies and creating flow

Many quarterly planning processes have some sort of dependency management built into them. Repeated dependencies between teams are signs of tensions or problems in your structure and are barriers to flow. Some (few) of those tensions may be deliberate, temporary and useful, most are chronic siloes in ownership and team composition that are stopping your teams from getting things done. Creating an illusion of managing dependencies with red knitting wool is patching over these problems and doing nothing to create lasting flow. Look to remove dependencies permanently by correcting structure, team ownership or composition over managing expensive, wasteful handoffs between teams

Good luck, and remember that more planning doesn’t always equal good planning! Stay out of A&E if you can!