CONWIP stands for constant work in progress which means that the overall number of work items in the system is limited, not just a single phase or column. For example, with a CONWIP of 6 we can have at most 6 work items between ‘todo’ and ‘done’. Like throughtput, takt time, and flow efficiency CONWIP comes from the car manufacturing world and it was designed for a system that produces the same kind of work item over and over. The idea is the following: it is hard to control throughtput (it is a lag measure: it provides a value that applies to a period in the past) while it is relative easy to control the overall number work items (real kanban cards and pulls) in the whole system. For example, our factory produces two kinds of product ‘A’ and ‘B’. At the moment the market needs more of ‘A’ and less of ‘B’, we simply reduce the CONWIP of ‘B’ and increase the CONWIP of ‘A’ (we do product leveling). This will change the throughput. When the demand changes we change the CONWIP values accordingly. Like the previously mentioned metrics, CONWIP cannot be used as such in software development, but after putting it into context it is very helpful.
Planning in general - not just in software development - is not an easy thing. We have to know what to do next and have an idea when it will be ready. Although the former is harder the latter seems to be more problematic. We also struggled with it with my old team at Digital Natives. We had frequent and long planning meetings, and had rarely finished everything we had planned. So, we decided it was enough, and it was time to try something new. After about two months, we were able to give very accurate hour based predictions on spent time and delivery (lead time) with a quarter of the effort of our previous planning meetings.
In my throughput post I was writing about a piled up inventory of work items which is created when the throughput (output) is lower than the demand (input). These work items are visible, they are on the Kanban board, and we call them aging work items. I’m not sure where the name comes from but I think it relates to the fact that these work items are staying longer in the flow (manufacturing of software process) than some others, they are usually stationary, and therefore they start aging. The aging work items are quite dangerous in terms of software development and also in terms of manufacturing.
At Lean Agile Scotland 2013 Chris Matts mentioned that “the WIP limits kill the options”. He didn’t really explain his statement in detail but I had been thinking about it and I dare to say that Chris was half right. He often talks about staff liquidity as well, which tells us how likely our staff will be able to work on a problem or a feature. In this context it means that “the more liquid our staff” the more work items we can work on in parallel, which means that we have more options. For example, we have four people in the team, two of them are expert testers, one of them is mediocre, and the last one has no idea about it. We can say that in this team three people can do testing. If this team has a WIP limit below 3, then this limit really kills options by preventing somebody who can do testing from actually doing it.
There are different reasons why limiting the work in progress (WIP limit) is a good thing, but now I would like to talk about one special case where WIP limits are helping move things forward. Let’s assume that you have a working pull system which means that the team members don’t push the work on others, but others can take the work if they are capable to handle them (I’m not using the word free on purpose because what if somebody can work on two things in parallel). Check out the following setup. How many pulls do the team have to do in order to get one work item done?