What to do when your team is the blocker of everything

I wrote this up a while ago to share with someone experiencing similar challenges. It doesn’t represent a view of beautifully optimised flow, it doesn’t address the deeper issues that caused the situation, but as a coping mechanism, I hope it might be helpful to someone.

Photo credit: Ada Gonzalez on Flickr

Years ago, I looked after an internal configuration management product, and sat within the part of the organisation that owned all the infrastructure in scope for being configured and managed by the product. We’d worked through various challenges around agile working, communicating with our users, prioritising our work, and over time one thing became clear: there were more demands from us in a given period than we could deliver. And because we had multiple teams blocked on their objectives waiting for us, any prioritisation call I could make was effectively deciding who would be blocked and who wouldn’t. Trying to please everyone meant we made only tiny amounts of progress on multiple things, and failed to meet anyone’s needs.

It was clear that prioritising our product backlog wasn’t about our product, it was prioritisation for the whole portfolio of products that relied on it. I scheduled a prioritisation meeting and somehow persuaded one or two managers at the level who could make tie-breaking decisions across the portfolio to attend. Once they agreed, their peers kind of had to otherwise the prioritisation would happen without them being there. I didn’t plan it that way, but whatever works…

Before the meeting I shared a list of the things we’d been asked to do over the next quarter(ish), and gave people the opportunity to add any I was missing. I’d made a first attempt at grouping them into high/medium/low priority.

The meeting was an hour and I knew there was no way we’d get through everything so I structured the meeting like this. (This probably didn’t happen the first meeting — we ran this exercise three times over three quarters and iterated a bit, but this is the version I remember.)

• First, skim the high/medium/low groups and flag anything we think might be in the wrong group (e.g. this item in the Medium group is more important than that item in the High group). Rather than try to resolve them, I think we moved them to in-between groups to come back to.
• Agree what should be in the High priority group, then try to rank them. Usually we’d have two or three MUST DO items and often there were two tied for top place. As long as we had capacity for both of them, I wasn’t too bothered about separating them. Picking my battles was key to getting anything done here.
• The dev team leader was on the call, and had worked on the product forever. She was great at finger-in-the-air estimates about what might be feasible. If, after going through the High priority items, we had more than a quarter’s work, there was no point in ranking any more. I’d do one quick confirmation that there was nothing lower down the list we should have included. If we ever got into the medium priority items (rare) I’d ask for suggestions as to what might be the next highest priority, etc. until we were more than ‘full’ for the quarter.
• Often the first three or four things in the list were BIG and we weren’t sure we could do all of all of them. This was, I think, the bit where I was able to add most value. I’d try to break the items down into only the highest priority parts — so e.g. if we were being asked for a feature to support some compliance deadline, sometimes only part of the feature was really required for the most urgent compliance point, there might be a manual workaround we could use for part of it, etc. We’d split the item, keep the highest priority bit near the top of our list and relegate the rest of it to its proper place.
• Sometimes we had things we thought might happen, or we knew would happen but had no idea yet of the size of the work for the team. Then we’d have a ‘priority placeholder’, so e.g. this thing will be third in the list if we need to do it, but right now there’s no work associated. If it becomes a piece of work for the team, everything from 4th place downwards is at risk.
• We’d agree the list, including placeholders, and end the meeting. Anything which didn’t make the cut, the managers on the call could tell their people (which was a huge relief for the product teams asking us for all this stuff we couldn’t deliver — their managers were telling them the bad news rather than the other way around). We’d also make it very clear at this stage that we hadn’t committed to anything, we still had to do another round of estimating.
• The team would do some more considered estimating over the next couple of days, and we’d come back to the senior management team with a short-term roadmap of what we expected to work on.
• If anything changed during the quarter, e.g. a new priority came up, in theory we’d get the group together again. In practice, the couple of times it happened it was pretty obvious where the new thing sat in the prioritised list, I emailed a proposal of the new prioritisation and which things would drop off the bottom of the list and not get done that quarter, and left it open for people to challenge me by email or convene a meeting if it needed discussion. Maybe people just hated my meeting so much, but nobody ever challenged. Again, whatever works…

We did this for three quarters before I left that role — it was daft really with hindsight, that we allowed so many things to be blocked by the capacity of one team. (“Any optimisation not at the constraint is an illusion” — Theory of Constraints/Goldratt.) In an ideal world you work towards having fewer dependencies, so teams can deliver value with reasonable autonomy and without the horse trading, and situations like this cease to be a problem. But sometimes dependencies are unavoidable (or at least, haven’t been removed yet) so I hope sharing what workd for us can help someone navigate similar situations in the short term. In our case it helped take the heat off the teams depending on us, and made it less painful for our team who until then felt like they’d been letting everyone down. And if it also highlighted what the cost of not focusing some energy on improving things for the team at the bottleneck, to people in a position to do something about that, then it can’t have hurt.