Kanban, Writing Code is Like Building a Car

The first step in improving your environment and taking steps to become more agile is understanding what is going on in your pipeline. Many shops today have no concept of where all their various changes are, what state they are in, and when they can expect to get stuff out the door. Dev churns out code as fast as they can and then they lob it over the wall to QA. QA is almost always understaffed and can’t keep up with the mass of code that keeps being flung at them from the developers. When you throw in architecture and user acceptance testing, you can end up with a real logistics issue. The question is, how do you fix it?

Back in the 1940’s Toyota had similar issue with their manufacturing plants. They had inefficiencies all throughout their pipeline but had real trouble sorting them out. They found a solution in an unlikely place, Supermarkets. They began to study the way the supermarket pipeline worked. First, a customer buys items off the shelf, then the items are restocked from the back, then that inventory is ordered from the vendor. It would seem ridiculous for the stock guy to randomly deliver more cans of beans to the front of the store. He only delivers enough to replenish what had been sold.

Toyota applied that same concept to cars. When a certain amount of doors had been put onto cars, a request is put in to build more doors. Those doors are delivered just in time to be used on the next group of cars. This is referred to as “Pulling the demand.” Starting at the end of the process, each step pulls what they need from the process upstream.

All too often in software development, we “Push” instead of pull. We get stuff done as fast as we can and push it up to the next level with no concept of what that means downstream. Our developer stockers keep wheeling out cans of beans to the front of the store, even though there is no room on the shelf for it to sit. We do this, mostly because we don’t understand where our limits are and how to streamline.

This is where the Kanban board comes in. The Kanban board is a way to track all the moving parts in your pipeline. Take a big piece of paper and mark 5 columns on it. Label the columns something like “Architecture”, “Development”, “QA”, “UAT”, and “Deploy”. Take that board and publish it in a public place. Now write down everything that is currently in process. Put each item on a card and stick it up on the board in the proper sections. That exercise alone can be eye opening. In many shops, you will have 4 items in “Development” and 27 items in “QA” or past. In this case, Dev is pushing out code as fast as they can, but nothing is getting done because it gets stuck downstream.

That is the simple beauty of the Kanban board. It gives you a very visual indication of what is going on in your process. It is very simple to see where the bottle necks are and gives you some tools to start fixing that problem.

Now, what do you do with that information? It really depends on where your issues are. Do you stop development and have you developers start automating test plans? That could work. Maybe help out UAT by sitting down with the business partner and doing working sessions. Fix defects proactively instead of waiting for QA to find them. All are reasonable options, but whatever you do, don’t perpetuate the problem. Once you see an area over worked, stop adding to it.

Leave a Reply

Your email address will not be published. Required fields are marked *