Why everything tends to be so slow?
If I were a superstitious guy, I would say the universe was sort of conspiring in my favor when it led me to see an interesting post and discussion on LinkedIn the other day. That’s because I was thinking of writing about some work I’ve been doing on signals for batch-size, which I believe can enable conversations around getting sharper on priority and flow.
The overarching theme being yet another case for right-sizing, for which I shared some practical guidance before here, but this time taking another angle.
See, I’m not necessarily a superstitious guy, and I don’t have to, because the above described behavior is just like our human brains work – the post called my attention because it had patterns I could match to stuff I’m currently thinking about. Now I have a better framing to the conversation I wanted to brought up by asking the question:
Why everything tends to be so slow?
Short answer: it’s rarely about the capacity of teams to deliver, could they be truly just focusing on a specific thing at a time (or at least not too many). Slightly more elaborated answer: it’s complicated… and John Cutler, one of my main influences in related matters, has thrown a insightful drawing in the comments of the referred post that helps to illustrate that:
By John Cutler
Once we understand it’s not a simple matter of team speed of delivery, and that there are many, some of them arguably even good reasons, for teams to not be able to fully focus on one thing at a time, perhaps we can reframe the conversation to a more insightful question:
What’s holding us back to be more responsive and deliver at expected speed? And what can we do about it?
And here we get to the core of my take on this post, with one practical example of a tool I’m currently using to help and "nudge" some conversation. That hopefully can lead us to get sharper at prioritization, ensure faster flow, as ultimately a means to be able to respond faster should context change or we just want to make sure to adapt to evolving situations in general.
Another angle of right-sizing: how big is the batch of ongoing tracks of work?
I believe it was John Cutler himself that once shared a note which I thought was quite insightful. I unfortunately can’t find it back, so I can only paraphrase from memory, and it was something like…
If you (as a team) would only focus on finishing work already started, how much time it would take until you feel like there’s nothing more to do?
What he was getting to, ultimately, was to a notion of batch-size: how much work it has been pilled up in a given team. I really liked it – to the extent I started practically using the question.
But what if we could make of it something more robust than what the teams believe it would take?
I eventually got my head around that, and after connecting a couple of dots, I came up with a little something which, IMHO, brings about a bit of data-driven take for dealing with that insightful probing question… This how it conceptually works:
You define what ‘tracks of work’ WIP means in our context (e.g., maybe in your organization you work with Epics or Features as the bigger chunks of “team portfolio”
items that well-represent that concept of what it gets further broken down into the actual work to be done).
You then use some statistically sound throughput indicator* to forecast with some confidence level how much time worth of work it has been batched in the team (if we assume all the current track of works and their remaining backlogs will be fully done).
The below graph illustrates how one can track the signals as a trend.
Once we have that, we can start meaningful conversations around what we observe… e.g.,
Is that a healthy amount of batching? What does that tell us in terms of both the ability to fiishg the work that has been started (thus committed) in a reasonable time frame as well as of our ability to adapt to evolving circumstances?
Because this is what it boils down, on a very practical level, and the reason why I also tend to associate this with, ultimately, a matter of prioritization:
The more stuff you have already committed (or started working on), and the bigger the batch of work yet to finished, the more difficult the conversation on re-prioritizing…
So picture it from the perspective of leadership or stakeholders – which don’t quite understand why can’t you just switch gears and go for this new thing with a sense or urgency!? Do they understand how many options it has to conflict with already ongoing things?!
Put in other words, ultimately right-sizing a team’s batch of ongoing work tracks and the cumulative size of their respective backlogs helps with ensuring a good balance between: (a) giving insight and perspective on what we are working towards in near future; (b) while also ensuring we have enough space to make adjustment less of burden in terms of re-prioritizing and shuffling things around.
To finalize by directly answering the question in the title: chances are, and based on my experience that is quite common, that batching up too much work in teams is a reasonable hypothesis what’s holding us back to allow to cater for that higher adaption to changes. It’s not trivial, thanks to too much conflicting priorities, to have the discussion of what has to stop so that the new thing gets started and finished promptly. Not to mention the potential inertia of just continuing what’s currently going on when it’s not that easy to just shuffle things around.
Holding a mirror, as a feedback mechanism, like using some sound forecasting to get a sense of how big that ongoing bach is, which is just expanded angle of right-sizing work really, is a practical way and guidance to hopefully triggers the right conversation. It has been my experience it actually is the case (but as they say these days, YMMV).
* I am personally using Monte Carlo simulation based on daily throughput that gets rolled up as weekly throughput ran by 1,000 times and then use percentiles for confidence level (with a conservative approach: at least that or more weekly throughput). I’m happy to share notes and even a template I created for anyone interested.
ByRodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.