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?
I often think about the purpose of Agile. It is definitely not to replace the Waterfall development process, or make the life of middle managers even more difficult. I believe it is not about testing more or using new technology either. I see similarities between the purpose of Agile software development and police work. A long time ago, a British police captain said in an interview that “the purpose of the police work is preventing crime and not fighting crime”. Unfortunately, they spend too much time fighting it, because according him they didn’t care much about prevention (limited resources, less knowledge etc). “Preventing crime versus fighting crime”. For example, if the police knows that there is a certain area that may attract thieves, they can put up warning signs for those who don’t live there, and by patrolling they can actually discourage thieves to operate in the area. It is cheaper and more effective than to chase thieves and try to find the stolen merchandise. I’m simplifying the situation, but I think you get the idea. As usual, the metaphor cannot be applied in software development as it is, but if we take the crime out of the previous statement we get “preventing vs fighting” and that can be applied in software development.