Big Room Planning and Looking at Dependencies Differently
Photo by Tallis Photography
“We’re going to invite people from 40 product teams to meet for 2 days. Our goal is to map dependencies between the teams for our enterprise initiatives and determine how we might need to shift priorities for feature delivery across teams.”
It was a big ask. Roughly 200 people in a large room. Mapping out future work and dependencies on the walls, tables, and out into the hallway. It can be overwhelming to have so many people in a working session together. The goal was to create smoother delivery plans across so many teams. In my experience, big collaborative work sessions benefit from a very small amount of pre-work by attendees. The session is for work to happen. When people come in and have done a lot of pre-planning, we lose some benefits of the event:
The session becomes more of a read-out than collaborative event. Engagement decreases, and potential discoveries go overlooked
The fidelity of information changes, and people are more averse to modifying plans in the room because of the effort already invested in it
There’s potential frustration if the pre-work ended up being a wasteful activity
Interesting discoveries often happen in events like Big Room Planning. Folks recognize which products/teams are potential bottlenecks. A few teams realize they are expected to deliver something they had not planned for. Connections of names and faces are made between teams. At least one person is surprised to see just how many dependencies exist in the organization.
My colleagues and I knew the challenges teams would continue to face after this event. They could be struggling to deliver overly complex solutions, losing sight of the intended business results, and waiting on other teams for days or even weeks at a time. Dependencies run the world.
What if we could disrupt the current thinking around dependencies?
Dependencies indicate that multiple products and teams are needed to deliver a solution that will (hopefully) create business value. The more teams involved in delivery, the harder it can be to coordinate efforts and integrate. That typically elongates schedules and delays deployment to production where we learn how customers respond to the new functionality. It’s easy to get caught up in delivering a particular solution rather than trying to move the needle for business outcomes. In any case, we need to define how business results will be measured and then ensure the proper metrics are captured. How did the thing we delivered help or not?
Going back to our Big Room Planning event, how could we use the time with 200 people differently when it came to dependencies? Instead of coming up with a plan for managing them, let’s reveal the dependencies and see how we can break them. Say 8 products show dependencies between them for a given effort--what’s the business result being pursued? Could those 8 product teams imagine a smaller experiment that would allow them to remove or avoid some of the dependencies? Maybe not all 8 teams need to be involved in the first deliverable that we can learn from. Create something simpler that can be deployed more quickly and measure customer behaviors. Validate if we’re on the right track to solving customers’ problems or not and enable the product to evolve from there based on customer usage. We allotted time for group breakouts to discuss the objective and outcomes.
People were excited to attend Big Room Planning. I’m still surprised at the buzz that was in the room those 2 days. Discoveries and connections were made. One team abandoned the plan they’d had and pivoted direction to focus on something more valuable. Conversations are continuing about how to “start smaller” so every product team can get measurable customer feedback from production every 6 weeks or less. Two days of Big Room Planning, and the group did not formulate a plan. It jumpstarted more planning, which is what is needed to ruthlessly break down dependencies and focus on delivering business outcomes.
