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.
First, it is obvious but I have to mention that a very high CONWIP won’t cause very high throughput. There is an upper limitation of every system and if you go above this limit the overall lead time will increase and the throughput will decrease because the high CONWIP will allow aging work items in the system. Second, CONWIP has really nothing to do with the WIP that is applies to the columns (or phases) on a Kanban board, except that the CONWIP cannot be lower than the highest WIP. For example, if you have a WIP limit of 5 for testing and your CONWIP is 4, you’ll never have more than 4 items in testing, so why have a WIP of 5 and/or a CONWIP of 4? And third, the sum of WIPs won’t provide the ideal CONWIP. CONWIP is in connection with a desired throughput or capability.
Let’s say you have 5 developers, you have one ‘ongoing’ and one ‘review column’, and in order to move things forward you have a WIP limit of 2 for ‘review’ and 5 for ‘ongoing’. The sum of these WIPs is 7 but the actual capacity is 5. If you set the CONWIP to 6 or 7 you’ll have at least one developer who is working on multiple things. Moreover, the team slows down because ‘review’ will be emptied when ‘ongoing’ reaches its WIP limit. If you go below 5 you’ll have a developer who is idle. So the best CONWIP for this team under the given circumstances is 5. If you change the WIP limits to 4 and 1 ((for ‘ongoing’ and ‘review’ respectively) because you want your lead developer to do only review you can do it without changing the CONWIP. Unfortunately, it will be the same as the sum of WIPs but as I showed you before it is not a working use case.
As I mentioned in the first chapter the CONWIP serves as a controlling function in car manufacturing and it can be used in the same way in software development. The team which owns the board below can do more and more week by week (increase in throughput), but never enough to match the demand:
So, it decides to maximize the amount of work items it can have at the same time. With this approach the team can have some time and stabilize they are in. So the team takes control over the demand (input) and throughput (output) by using CONWIP.
comments powered by Disqus