Epiphanies for Everybody
Big Room Planning is an Organisational Smell
Big Room Planning is an Organisational Smell
Just like code has smells that tell you something is wrong, so do organisations. Big Room Planning (BRP) is one of the most obvious smells.
I posted something similar on LinkedIn the other day, which while pithy, is also true:
My friend replied:
And he’s right. The problem is that most enterprises (and scaled agile frameworks) take the wrong message from Big Room Planning. Let’s take a step back and look at why:
Agile is about getting working software in front of customers quickly, because they’re the best arbiters of what they’ll use
Most traditional enterprises have lots of hidden complexity that slows delivery down
Lots of BRP proponents take a look at these two things and conclude that the best thing to do here is to expose and manage the hidden complexity. And they’re half right. It is absolutely critical to expose the hidden complexity in your system.
There’s an entire cottage industry that springs up in enterprises to manage complexity — enterprise architects keep track of the systems and become gatekeepers; planning events are held to talk about complexity; meetings are then held to manage the results of planning; and other meetings are held to work around the complexity that wasn’t found during the initial meetings; progress meetings are held by leaders to see how close to plan things are; follow up meetings spin out of those meetings to get things back on track, which only pushes things further out… it goes on, and on, and on. The waste is enormous. It’s not surprising to find that 70% of time spent in enterprises can be categorised as waste. Big Room Planning is often just another meeting to thrown on the pile.
A couple more things:
Practitioners have found that the most effective teams are independent, self-managing, and between 4–12 people (people argue over the exact numbers, so I’m providing a wide range in the interest of being inclusive).
BRP calls for groups of 50–150 people who are involved in the delivery of software to work together to manage dependencies, and plan work.
Looking at this, it should be obvious what needs to happen. If you need 50+ people to manage your flow of value, it’s going to make you slower than if you had 12 people people doing it. Any company that can do, with 12 people, what it takes you 50+ people to do, will outcompete you. They’ll cost you time, money, and marketshare. So simply managing complexity will never be enough.
If you’re part of an enterprise, and you’ve got huge monolithic systems with lots of hidden complexity where things run late, underdeliver, cost too much, are low quality, and generally don’t work the way you think they should, BRP is a fantastic first step. It gets your complexity out in the open. If you ever want to be successful, however, it can’t be your last step.
The second step in the BRP journey is to remove complexity from the system. I know it’s hard, but stop focusing on short-term delivery. If you have a set of dependencies that you are tempted to manage, you should know you’ll get far more benefit by removing them. Removing dependencies will require new skills, new approaches to how you think about your work, new architectural practices, development practices, and what your organisation focuses on. (How you do this is beyond the scope of this article, but I may talk about it in another article. Many others have written great things about removing dependencies and complexity.)
It’s a higher initial investment, but by removing dependencies, you rapidly reduce the number of people that have to be involved in planning, and dramatically increase your speed of delivery. And let’s face it, you’re already spending millions on things which don’t work, and in fact, can never work. Fixing them will be far cheaper in the medium term. In addition, you’ll start to resolve your issues around quality, cost, and speed, which will be good for morale, retention, and the bottom line.
“The ability to learn faster than your competitors may be only sustainable competitive advantage.” -Arie de Geus
If you don’t take the time to reduce your dependencies, you’ll never learn as quickly as you can. And if you can’t learn quickly, you can’t respond quickly to market changes, customer changes, demographic changes, or your competition. And maybe those things don’t matter to you. Maybe you’re just killing time until you can move to your next gig. If so, I’ve just wasted your time. But if you want things to be better, you’ll have to put in the effort.
(NB: the most popular scaled agile framework SAFe, accepts that managing complexity is inevitable. That’s why it every version of it has PI planning as a core practice. This leads to the belief that once BRP is being done, things are as good as they can get. Don’t you believe it.)