At my current client, we have split our teams into five smaller (8 people) teams. I wrote about that process before, if you want to read about that. One of the big concerns that people have had after the split is how we make sure that we don’t miss stuff that “falls between the chairs” for these teams. I think that’s an overstated problem, but we sat down together and, as always with great people that care, a good solution came out. This post shows our findings, and I’ll try to unfold my thinking on why I thought the problem is overstated as well. Since we’re now brushing on business-critical strategies, I need to keep this post fairly general. I’ll try my best to make it understandable.
The Problem
My client now has five different teams that have separate backlogs and work towards realizing strategically important initiatives for the company. The teams are working on main features of the site, such as Search, User Management, and Product.
But sometimes things pop up that don’t fit the backlog of any team. These things could be suggestions for improvements, urgent bugs, or ideas for the future. Examples of these could be: “Add a product page that is mobile-friendly,” “User X123 cannot log in,” or “Fix the registration process to run smoother.” High and low - some of these are quick and simple, while some take a while. And most are simply not known; it could take a lot of time. We have to investigate to know more.
The problem up to now is that the people who come up with these suggestions don’t know where to turn to and hence go directly to the team that they think is most suited (or where they know people). On the other hand, the teams feel an urge to just pick stuff that comes in and start to work on it, which in turn makes the progress of the initiative slow down.
We stand the risk of ending up in a place where we are only doing “miscellaneous” stuff, and the teams are at risk of jumping from task to task. This defeats the purpose of the teams, which were created to be able to work on big chunks from their backlog without being disturbed by minor items. Still, people out there need help…
The Solution
First, we visualized the things that fall “between the chairs” on our common board (I’ll write a separate post on that). It’s just a big square that anyone can post new topics in.
We then settled on some policies for the work items that are posted in the square:
- We clear the square at each morning meeting. Nothing should be left when the meeting is over.
- If you have posted an item on the board, you have to come to the next morning meeting.
- For every item we post, we ask the teams if it belongs to any team backlog. It doesn’t have to be high priority, but if it’s part of what they are working on or intend to work on. “We’ll take it and put it in place 65 in our backlog” is a perfectly acceptable answer.
- If no team takes the item, we decide on someone to take it back to the reporter and kindly inform them about the item not fitting in any team backlog right now.
This might seem harsh, but first, there’s no reason to be rude just because you say “No!” It’s a word that any product owner should use a lot. Secondly, the teams were created for a reason: to promote working on the suggested initiatives. If we continue working on everything that comes up, we shred our concentration and focus on the backlog for our initiative.
The Thoughts
This relatively simple problem caused us to dig into some quite advanced topics around prioritization and backlog management. Here’s the thing: the five teams were created to put extra focus on certain strategic initiatives. When we do that, we cannot also “continue to do everything else” or we risk just doing the small, quick stuff that pops up.
For many people, prioritization seems to mean “ordering” when it in reality means “not doing some stuff.” This has to do with the fact that there’s always more to do than we have capacity for. You remember the donkey, right? This poor donkey, if he could talk, would tell you “Stop” when you put on the last two bags. “I’ve got just the right amount of bags on my cart right now, thank you very much. If you add those extra two, I will go up in the air and we get nowhere. No bags will be delivered.”
If the teams try to continue working on their backlog (that is prioritized) and at the same time take on new work that doesn’t fit in their backlogs, we are just overloading the carts of the teams. And it’s often the team that does the loading themselves.
“But this one is important. Right?”
“But, but … that item really needs to get done. It’s important,” I heard someone protest. The simple answer is “No - it’s not. Per definition. And we should throw it away.”
This seems hard to understand but is actually quite natural:
- The item didn’t belong to any team backlog (they all declined).
- We have put together these teams to work on strategically important initiatives.
Hence - the item is, per definition, not important. We could still work on it, but that means that we stop work on other things. That’s perfectly fine to do - but we should at least reflect on it and make a conscious decision.
This is also quite natural if the item is urgent enough. If someone finds an important bug (“The search field allows for SQL injection attacks,” for example), we would gladly stop our work in our tracks and just fix that as fast as possible.
But when something isn’t that important (“This 4-year-old bug is still out there”), we don’t stop our work but rather should throw it away. It’s been there long. It hasn’t caused any problems to date. If it starts to be troublesome (or more important, or more asked for, or [fill in a convincing argument here]), we will hear about it. I promise!
Conclusion
The “Between the Chairs” square was, in reality, a way to visualize a systemic failure. We kept (and keep on) doing stuff that we haven’t prioritized. We keep doing that since we at least want to respect the fact that these things keep popping up.
If a lot of items come up in the same kind of category, we might actually have found a missing team. Or at least an area that one of the teams should be doing that they are not doing right now.