Yesterday, I met Mary and Tom Poppendieck and over a nice beer we were talking about various topics but we spent most of our time talking about flow efficiency (ratio of the value added activities to waiting). When I was riding my bicycle home I was still thinking about our conversation and presented examples. Despite the fact that I think the current right move is to favour flow efficiency over resource efficiency, I think it only works in the simple domain of Dave Snowden’s cynefin framework, where the connection between cause and effect is obvious to all. Here, simple means that the process is clear to everybody who is involved even if it is a long process. If you think about car manufacturing from where the concept of flow efficiency originates, you can see that it’s in the simple domain: every detail of the process is well known to all workers involved. However, in knowledge work and in software development, that is not necessarily true.
According to Dave Snowden, most of the knowledge workers are in the complex (connection between cause and effect is clear only in retrospect) and complicated (connection between cause and effect requires expert knowledge) domains, and in these domains the flow is not as visible and controllable as in the simple domain. Without having the proper - and not expert - view on the flow it is extremely difficult to improve the flow efficiency. This is a minor thing compared to the fact that in the complex and complicated domains we don’t even know for sure the connection between cause and effect (that’s why Snowden suggests to probe and analyze) and we add flow efficiency changes on top of that.
For example, we see that there is a buffer between two teams (buffer means waiting time). One way to improve flow efficiency is to merge the two teams or at least make them interact more frequently. This looks like a good idea, however there is no guarantee that it is going to work. What if the teams simply cannot communicate more or they cannot work together which slows them down and the waiting time increases?
Nevertheless, improving the flow efficiency is a good idea but knowing in which domain of the cynefin framework we are in is crucial. I had improved the flow efficiency of various teams in the past but in retrospect they were in the simple domain. I failed with my last team because we were in the complex domain and despite the huge effort we put into flow efficiency improvement nothing has changed. We should have moved to the complicated domain first where the connection between cause and effect are clearer and do the flow efficiency improvement as an experiment that we can analyse. My point is: don’t start with the flow efficiency improvement until you understand your flow and you have control over it (having a value stream map is a good start but knowing is different from understanding).
comments powered by Disqus