How product development benefits from flow - Part 1
If obsession can be a positive thing, then obviously I’m obsessed with one idea…
That we can only improve how we deliver value through products by looking at it as a “system” (a complex adaptive one, to be more precise).
And as a good product person, I use my “spider sense” (built by both theory and practice) to figure out the best way to influence and focus on that. I’m currently convinced that the simplest and often overlooked is the idea of flow as an enabler.
That’s why I keep coming back to that…
In this two-part series, I would like to further explore that from two angles:
Part 1: the matter of foundation, the pragmatic and effective way to ensure respect to flow – focus of this part.
Part 2: the matter of leverage, how that tends to increase the likelihood of achieving the things that matter most (the outcomes that drive impact) – in an upcoming second part.
As I have stated before, limiting WIP is possibly the simplest most underrated advice. But it's also a means to an end. What we are truly after is ways to create focus. If you have good alternatives to that, to ensure getting further on fewer things, feel free to use something else.
But I (must) insist in WIP limits (at all relevant levels) as being quite likely just the most pragmatic way to get there. With the constraint itself often helping to lead to different, better conversations.
At the most basic level, it is even a matter of respect. To people’s and team’s capacities and abilities to deal sustainably with things they need to go deep on.
That alone, if you ask me, is reason enough.
But it gets better (and this even isn't a exhaustive list)…
It creates a constraint that leads into more focus on finishing as opposed to starting work, potentially nurturing more collaboration in the process as well.
It helps to surface bottlenecks and where and when things get stuck, so you can do something about it.
It doesn’t allow pulling new work as a sort of excuse to not keeping pushing for some blockage to be sorted.
And by the way, quite literally people and teams will be better off being sometimes idle, i.e. having slack (like when being blocked).
I know the last one may sound counterintuitive the most, but yes, I mean it.
It may serve them well in fact. It can bread creative solutions to get unblocked. Or you can use the time to work on that bit of incremental improvement to a process that is always left behind. Anything that won’t really harm progress where matters if you can leave it back for a little longer should you be finally unblocked.
As I have been wrestling with those things on a daily basis, I eventually came up with which I believe to be a simple sort of ludic way to effectively land that message. I thought of sharing it here as a kind of "beta testing". So, feel free to give feedback, even if that means "shooting" the idea out as ridiculous or something like that.
Before we get to that though, let me make sure to articulate the underlying principle (in a simple way) that brings it all together:
The matter of foundation:
Any system to deliver products, to improve, can benefit of both having a constrained load of work and that leads to shorter feedback loops (i.e., faster learning).
Let's play: designing a WIP simulation game
Imagine we could simulate different scenarios of how many items to make progress in parallel, like part of the development of a product. What could that game look like?
We first could agree on what are the dynamics to be simulated. For example:
Progress made varies across iterations.
Progress can be distributed across different deliverables (depending on the scenario and situation simulated), but there can be constraints on how many (by intention or not).
Items may be blocked in certain iterations.
We could make some sensible assumptions for the sake of simplification:
Deliverables are prioritized, so the distribution of progress is top to bottom and evenly (for items WIP and not blocked).
WIP for a given scenario is kept stable across the iterations.
If a deliverable reaches +100%, then the remainder is added down to the next in order.
If a deliverable is blocked, the progress to be made in that item is either lost for the iteration or distributed (equally) to the other items WIP.
Should there be more WIP in a scenario than in a given iteration, still the progress is divided as if the WIP was stable (assumption being that in real world the system would have started new work in parallel, we are just not worried about simulating those).
Then, we could come up with the actual conditions to be designed in the game:
Scenarios: how many systems and with how many WIP to be simulated for each.
Decisions: there are essentially 3 things that need to decided upon randomly(e.g., with dice) at each iteration:
How much progress to be made;
How many items to divide progress against;
Whether any top-most item(s) are to be considered blocked;
And we could finally play the game:
Resources: a way to random draw numbers (e.g., dice); a way to register the progress (e.g., paper and pen, or a spreadsheet in a laptop)
How many scenarios to simulate? And with how much WIP per scenario?
How will decisions be made?
On progress to be made?
On how to distribute progress against WIP items?
Whether any item(s) are blocked to be considered blocked? What to do with the capacity for items blocked (in case there are other WP in the same scenario)?
An example of setup might come handy:
Resources: a pair of dice, paper & pen.
Scenarios: (A) 4 deliverables WIP in parallel; (B) 1 deliverable WIP at a time.
Decisions:
How much progress to be made:
How many items to divide progress against
Simplified: progress is always divided equally across all (non-blocked) items WIP
Whether any item(s) are to be considered blocked
Option 1: 1 out 6 chance for Scenario B being idle
Option 2: 2 out 6 chance for Scenario B being idle
Maybe it's about my bit of obsession for the theme, but I have found myself playing this, with different setups, and I found it quite playful… And thanks to that (although some, clearly, are easily derived from logics or seminal literature like Don Reinertsen's: The Principles of Product Development Flow, but it's always nice seeing something concrete that proves it…), I can make some empirical observations on typical patterns :
Only a Scenario of 1 WIP at a time (sequencing work) will tend to ensure that top-most priorities still pending are finished earlier than another priority
Only a Scenario of 1 WIP at a time (sequencing work) will tend to ensure a more regular flow of work getting finished (i.e., more incremental). The higher the WIP, the more should there be a concentration of all work finishing closer to the late iterations.
Even if we only allow waste of capacity (i.e., being idle) in case of a blocked item in the Scenario of 1 WIP at a time (sequencing work), it will often still ensure earlier delivery than other scenarios with higher WIP (unless conditions are too favorable for progressing in parallel).
Consider trying it out for yourself. I would love to hear some feedback. Would you see this working well in a kind of workshop to run in a team or any kind of group, and use that to better land the key concepts around flow and the consequences of fundamental choices you make there (such as WIP limit)?
By Rodrigo 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.