At my current client we have split our teams into five smaller (8 people) team. I wrote about that process before, if you want 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 “fall between the chairs” for this 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 that 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.
My client now has five different teams that have separate backlogs and works towards realizing strategical important initiatives for the company. The teams are working of main features of the site, such as Search, User management and Product.
But sometimes things pop up that doesn’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 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 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 that come up with these suggestions don’t know where to turn to and hence go directly to the team that they think are most suited (or where they know people). In the other end the teams feel an urge to just pick stuff that comes in up and start to work from it. Which in turn make the progress of the initiative to slow down.
We stand the risk of ending up in a place when we only are doing “miscellaneous” stuff and the teams are standing the risk jumping from task to task. This defeats the purpose of the teams that was created to be able to work of big chunks from their backlog, without being disturbed with minor items. Still people out there need help…
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 for some policies for the work items that are posted in the square:
- We clear the square on 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 and
- For every item we post we ask the teams if it belongs to any team backlog. It doesn’t have to be high prioritized but if it’s part of what they are working, or intended to work on. “We’ll take it and put it on place 65 in our backlog” is a perfectly acceptable answer
- If no team takes the item we decided on someone that takes it back to the reporter and kindly informs 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 with the suggested initiatives. If we continue working on everything that comes up we shred our concentration and focus on the backlog for our initiative.
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 was created to put extra focus on certain strategic initiatives. When we do that we cannot also “continue to do everything else” or we stand the risk to just do the small, quick stuff that pops up.
| | |:————————————————————————————————————-:| | | | From http://woldfitness.com/ |
For many people prioritization seems to mean “ordering” when it in reality means “not doing some stuff”. This has to do with that there’s always more to do than we have capacity to. 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 are 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 need 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 to be hard to understand but is actually quite naturally:
- the item didn’t belong to any team backlog (they all declined)
- we have put together these teams to work on strategical important initiatives
Hence - the item is per definition 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 over it and make a conscious decision.
This is also quite natural if the item is urgent enough. If someone find an important bug (“The search field allows for SQL inject 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 trouble some (or more important, or more asked for, or [fill in convincing argument here]) we will hear about it. I promise!
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 comes up in the same kind of category we might actually have found a missing team. Or at least an area that one of the team should be doing that they are not doing right now.