Planning Agile Part III: Planning for Product People

As Product Owners we have the opportunity to align our teams on a destination, and to achieve better plans with our Big Room Planning process. Consider the impact strong product direction and alignment have on our teams. It increases buy-in and focus, and enables more autonomous decisions that are aligned with the plan.

In this post, I will dive deeper into the role of the product team during Big Room Planning (BRP) and during the execution of work. We will take a look at what it means to know the role, trust the team, and to steer as the work is being implemented.

In case you missed it, in my previous posts i discussed Big Room Planning: The Planning Calendar, what the process looks like leading up to the Big Room planning event; and Planning Agile: Big Room Planning, a deep dive into the event itself.

Know Your Role

The most important thing the product team does is represent the customer in the form of defining and prioritizing the problem spaces for the teams. But that is easier said than done as other things get in the way like:

• conflicting priorities,
• requests from higher up,
• maintenance work,
• tech debt, etc.

We also know that different product people on the same team may be hearing and prioritizing different things depending on which customers they talk to, who they work with in Sales and marketing etc. So the bigger challenge is how to align on fewer pieces, and how to bring those pieces into the room as customer problems rather than pre-defined solutions.

We have all caught ourselves writing features that are solutions rather than problem spaces. Then we are shocked at the effort needed, or what monstrosity resulted in the execution of that feature. Don’t be that PO!

Here are a few steps to staying focused on the problem space:

• What are we researching? what don’t we know? what don’t we understand?
• Focus research on figuring out what the most important problems to solve are, or to dig deeper into desired outcomes and potential solutions that will work for customers
• Include the whole team in this! Where possible, let them hear what the customer has to say, they will see and hear things you don’t!
• When you have solution ideas, keep a few in mind, and talk through technical feasibility with the team before you get emotionally attached to one solution. This sounds obvious, but we have all made this mistake whether we want to admit it or not.

Once you have your problem spaces, do the hard work to focus as a team by:

• Know what you are going to say NO to, and the goal of what you are trying to accomplish with what you have chosen to focus on based on the customer research and other constraints.
• Have the difficult conversations that lead to being a product team with one voice. This is the only path to buy in and understanding at all levels.
• Get the message from the product team to be consistent, no matter who is delivering it
• Include what we do and don’t want to support as part of that vision.
• As Warren Buffet famously suggests, write down your top 25 priorities, then rank them, focus on the top 5 and AVOID THE NEXT 20 AT ALL COSTS!
• What MVP functionality and outcomes are we shooting for (not necessarily MVP features, but what problems are most important to solve).
• A great tool for achieving some of the above is Weighted Shorted Job First or WSJF.

Trust Your Teams

Not to harp on this, but first you have to share problem spaces with your team instead of solutions. Developers are knowledge workers, it is their job to know the technology better than you and how to best implement new functionality that achieves defined objectives. Let them do their jobs.

Defining desired outcomes and how you will know you achieved them is a much better use of your time than defining solutions. Outcomes are easier to rally around. Outcomes inspire innovative solutions from teams. Pre defined solutions are handed to us, and inspire us to meet the bare minimum requirements as defined for us.

“YOU ARE THE BOSS. YOU ARE NOT RUNNING A CHARITY. YOUR MOTTO IS SHAPE UP OR SHIP OUT. WELL, LET ME SORT YOU OUT. IF YOUR EMPLOYEES TAKE NO JOY FROM THEIR WORK AND THEIR WORKPLACE AND ARE NOT GROWING DAILY, YOU ARE AN INCOMPETENT SHIT. THINK ABOUT IT!” — Tom Peters

Create space for dynamic teaming. With fewer problem spaces and shared objectives across multiple teams, we saw them experimenting with shared problem space backlogs. We saw pairing across teams to share knowledge with those they may not have interacted with before. We saw UX and QA sitting with teams, attending planning sessions and other ceremonies to give each other real time feedback and input.

Steer

We all know the basic principles of agile that tell us the importance of team autonomy — if they understand where we are all going, they can make decisions on their own to get there. But we found that when we did not offer the right boundaries for autonomy to work in, we had disparate work happening. Sure, it was related to what we were hearing from customers, but it was not focused enough to deliver them real value. So, we lost trust in our teams and started offering solutions again.

What we learned was obvious, WIP limits apply at every level of the organization. Setting train/product level goals related to no more than three organizational priorities or problem spaces, and working as POs to create team level goals that are directly tied to those, is essential. We all have 50 things we can do, it is the product team’s job to have the hard conversations to make sure the top one get through the system before we start on the next.

THIS IS HARD WORK. It is much easier to say “but we have so many teams, we have so many things that HAVE to get done”, but you all know as well as I do that little’s law, will kick you in the ass and not much progress will be made.

Beyond the prioritization work suggested above, we found these things helped us keep that in check:

• Alignment meeting with POs, PMs, SMs, Architects and UX weekly to create a space for those hard conversations, and hold each other accountable to having them.
• Scrum of Scrums twice a week, all SMs and others with key pieces that cannot wait for the alignment meeting or are more tactical.
• Moving from individual team demos, to problem space demos for all teams working in that space. Each problem space then demos at system demo.
• Working groups — anyone interested joins to solve the architectural or UX questions
• Cross team planning with shared prioritization
• Shared backlog any team can pull from

When we implemented this we got feedback people felt they were getting “Cross-problem space collaboration and knowledge-sharing that works toward a larger business value” and “improved awareness of what’s happening in problem space you’re not part of” that allowed them to make better decisions.

I don’t want to sugar coat it, these create heightened levels of communication, and it is CHALLENGING, but once you work through it, it leads to success.

In our experience we tried keeping problem spaces co-located in each of our three offices, but we did not find that necessary to success.

Bring it home

As Product Owners we have the opportunity to do better for our teams. If we stay focused on three things — knowing our role, trusting our team, and doing the hard work to steer, we will create alignment and focus like never before.

What is one thing you read here that you can implement in your upcoming planning meeting to create a better plan and deliver focused value to your customers faster?