While I was flying back to Brazil after attending another great Kanban Retreat event in Mayrhofen, I had the opportunity to read the last book published by David Anderson: Lessons in Agile Management - On the Road to Kanban, which is really great by the way and deserves a specific post about it. One of the topics particularly got my attention. I'm refering to the one that talks about the use of the "Inventory Lean Manufacturing" metaphor in the software development context (pages 291-294). In four pages, David Anderson really got me thinking when he tries to clarify the topic by explaining how tricky is to map concepts in such different contexts like manufacturing and knowledge work. He talks about the differences between an abstraction, an analogy and a metaphor and how this is relevant when we are mapping concepts and establishing language: "Lean is an abstraction rather than a metaphor".
Lean is an abstraction and inventory regulation concerns are part of a concrete implementation of Lean in the manufacturing context. That was my insight from his text. In that context, inventory is something that should be reduced as much as possible in order to smooth flow, reduce cost and eliminate waste.
Inventory is an accounting term. It represents the entire stock of a business, including materials, components, work in process, and finished products. In a systemic perspective, is something that you are accumulating or bufferizing in a system in order to guarantee supply for a downstream part of your value chain.
It is key for any continuous work process don't let its operators starving of work because of lack of raw material. So, to avoid that, it is common to produce more and keep it for later use, so downstream operators always have what they need to work.
Besides the fact that costs are much higher when you have to deal with a large quantity of material in the factory floor, what I think is so important as it, is the economics perspective. In the manufacturing context, as the raw materials are being transformed and as they are flowing through the system they become work in process, which can be a real source of inconvenience. Work in process usually has intrinsic value in this situation. As there are already money committed to the work in process, it becomes urgent to finish it, even if it becomes not necessary anymore or its value diminishes in comparison to other work items.
Even when this work in process becames finished goods you are not free from these types of problems unless you sell them immediately. Do you want to have a high quantity of items ready to be sold but with no customers to buy? Think about the simple economic law of demand and supply. So, maybe now you know why sometimes we have these huge marketing promotions selling by a price much lower than the usual. It is just excess of items with no customers to buy.
So, it turns out that, for manufacturing processes, inventory in excess is something bad. This over production causes a lot of harm and systemic dysfunctional issues. It makes the process less efficient and costs to increase once requires a lot of effort to manage it. Therefore, reducing inventory is key for Lean Manufacturing.
What about knowledge work?
It doesn't work like that in knowledge work. The model is quite different. The raw material for knowledge workers is information, not documentation, requirements, designs, neither any other artifact or discrete material, just information in its abstract form. Don't confuse information with the media that it comes with. Work in process is generated when one starts applying knowledge and experience to produce value given the information provided regardless in what format it is provided.
The money commited to it comes usually in the form of work hours invested by a knowledgeable person. As there is no intrinsic value whatsoever in partially done work, and as this type of work perishes really quickly, the economic pressure to finish it will depend much more of a perception of value, than of its intrisic value. So, it can be much more easily discarded, despite the whole psychological distress that this provokes. Raise your hand if you never have been involved in an abandoned expensive project with no real value or economic results delivered at the end.
Finished goods ready to be consumed but not consumed yet, in knowledge work, are just a different manifestation of work in process. If you write a non published book, this doesn't affect its intrinsic value. It is still can value millions or nothing depending on someone else's perception of value. In knowledge work, the value of partial work is not intrisic to the good, as it is in manufacturing.
So the economics of work in process is different in knowledge work. We are dealing with a really different set of concepts. We need to assume a different perspective on this.
The Lean abstraction doesn't require inventory as a concept to be applied in different contexts than manufacturing. Inventory control is more a Lean Manufacturing implementation aspect. However, we still have the same root problem. Dysfunctional issues regarding systemic buffers growing as time goes on that jeopardize the effectiveness and efficiency of the environment. We need to take care of this in our knowledge work systems, as people do in manufacturing systems when they regulate their inventories.
Let's focus on the root problem then: what type of accumulation, despites being necessary, can be really harmfull if it is not controlled over time in knowledge work environments?
One can say: work items. We can't let work items in progress start to accumulate in the system. That's why we use kanban to limit then and to not allow new work to be started before old work has been released. Definitely true! But enough?
Work items in progress are just a manifestation of something much broader and more impactant in knowledge work environments: Assumptions.
Knowledge work requires assumptions
We need to assume a lot of things, during the whole time to accomplish our goals in this type of work. It is fine to move forward with partial information, because when there is no information, we replace that with some kind of assumption to map the terrain. Our brain does that all the time.
When you start to work in a given item, a lot of assumptions start to take place in your system. It is really what the customer needs? It is going to take the time that you expect to finish it? It is not going to generate more rework? Who is taking care of it really knows what to do? and so on... Uncertainty rules here! And, to deal with that, we *assume*.
It turns out that the solution for the uncertainty is not to cheat the system by trying to create certainty upfront. Uncertainty lies in the knowledge work reality. What we need to do is to continously transform the assumptions that we created at the beginning to deal with the uncertainty in facts, and learn by doing that, once this learning is going to be useful on the formation of the following assumptions that will come up later on.
Real problems start to emerge when we don't care about the continuous replacement of assumptions by facts. When the environment is full of assumptions, we make blind decisions. We support ourselves on our perception of the reality, not on the reality itself.
We kill one assumption and replace it for facts when we evaluate it. This evaluation creates a fact. A discovered fact is just a manifestation of learning and the generation of learning is probably the most important aspect of a knowledge work process.
Few examples of assumptions and related practices that start some feedback cycles:
We are going to produce 32 points in this next iteration. (estimation)
The code in this method is doing what it should do (unit tests)
This part of the code is designed according our agreements, standards and style (code standards and collective ownership)
We are doing what should be done to achieve our next short term goal (iteration planning)
Few examples of facts and related practices that ends the feedback cycle:
We have produced 26 points in this iteration. (iteration review)
The code in this method was tested and it is doing what should do (unit tests executed on continuous integration)
This part of the code was checked and it is according our standards and style (code review, pair programming)
We have just shared what we have being doing and we know that now we are in the right direction (day after stand up meeting)
This list can be endless as closer you look to the environment with that perspective.
Think about what lies between assumptions and facts: Time!!!
Shorter feedback cycles is what Lean offers
As this time increases, it also increases the probability of jeopardizing the effort and decisions that are being made, conscioulsy or unconsciously, based on those. It increases risk! So, for a knowledge work environment, I propose that we should focus in identify and differentiate what is an assumption from what is a fact, and then, look for ways to evaluate those assumptions as quick as possible in order to transform them in facts.
The theory related to this concept is fully explained on this post: Cycles of Assumptions Evaluation
Interesting as we already have a really good tool to optimize this process of assumption evaluation. We just need to design short feedback cycles in our systems or make the current ones shorter. That's what Lean Systems for Knowledge work are about when we are talking about a system design perspective: make feedback cycles shorter.
Assumptions are not the new "Inventory" for knowledge work. This is not a good metaphor, actually. We are not just counting assumptions and measuring its accumulation. We are not limiting them. However, they can fill a theoretical gap that we have in our Lean implementations for knowledge work systems that can open a whole field of study and opportunities to find leverage points in such systems. It has the same role as "inventory reduction" has in manufacturing systems, because, in the end, the root problem they address is really close to be the same.