A case for faster flow and right-sizing
Early this week (Wednesday, June 26th, 2024), I finally did my session for the Online Scrum Master Summit. In hindsight, I should have prepared less content to increase engagement. There were still some, and I was quite happy to see some of the questions that emerged throughout, despite having to speed up things close to the end to ensure some time for Q&A (a trade-off I gladly took).
There was an interesting insight that came out, which inspired me to write this piece. I unfortunately didn't keep the guy's full name, but his first name was Stevan. He made an observation linked to one of the tactics I presented on how to create focus (which I recovered here from memory, so it's probably not literally what he said):
In enabling heuristics, you mentioned the longest in WIP goes first (as an example), but what if the item is no longer valuable?
Such a great observation! My answer was precisely stating that an assumption was made that everything in WIP is still valuable. And that it's good to develop some kind of triage mechanism to check whether everything WIP is still valuable regularly; asking yourselves that question periodically is always a healthy thing to do.
That kept my brain going in the background for a while afterward. And there's a couple of fundamental things that are to have in mind here (in my opinion):
To be deliberate about discarding work is a signal of moving towards higher maturity: when you become much more obsessed about being fit for purpose.
The challenge of discarding work after started developing: trying to avoid the sunk cost fallacy while being conscious of how costly it is to stop working on something that is already underway (maybe quite close to finishing sometimes).
Really what I am alluding to here is how we find that balance, and what can help do so. And that points out, in my view, essentially two key largely intertwined concepts:
Faster flow not only helps us to increase our chances of getting product development right but also tends to reduce the chances of having to discard something after started (by simple logic, you have just less time/opportunity to make that decision).
Right-sizing can be used to further help accelerate flow by reducing batch sizes to an optimized balance between value and speed of delivery.
Finally, to get even more practical, with a kind of "playbook", this is how I would see it bringing it all together:
Be deliberate about reassessing the value of currently ongoing (WIP) work and learn when to stop (not incurring sunk cost); create visibility (on the cost) of discarding work.
Figure out what are the current bottlenecks in the (delivery) system that when dealt with will lead to faster flow (they can be from all kinds of nature, it's a socio-technical thing).
Consider reducing the size of batches and right-sizing items which will then further help in ensuring faster flow as well as reducing the innate risk of stopping WIP work (the smaller the item, the easier can be just to agree to bring it a closure before starting something else).
It's ultimately, and circling back to where I started, in the context of the conditions of maturity just referred that enabling heuristics will be quite powerful (a point I alluded to in the talk as well, by reflecting that enabling heuristics probably requires some maturity) in bringing clarity across teams, part of organizations, etc., on how to deal with the dependencies at scale and elegantly, without the traditional scaffolding and overhead.
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.