Geeks With Blogs
Jonathan Mills' Blog Agile isn't something you do, it's something you are...

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.


Posted on Monday, November 15, 2010 4:23 PM Kanban | Back to top

Related Posts on Geeks With Blogs Matching Categories

Comments on this post: Kanban, Writing Code is Like Building a Car

# re: Kanban, Writing Code is Like Building a Car
Requesting Gravatar...
This is exactly right, and from a QA perspective, once the code starts piling up, the ability to figure out 1) how any one bug got introduced and 2) where you even are in the process gets totally mangled.
Left by Evelyn on Mar 22, 2011 9:55 AM

# re: Kanban, Writing Code is Like Building a Car
Requesting Gravatar...
interesting and impressive work and great article. thanks.

OBDII scanner
Left by roman balick on Sep 18, 2011 6:18 AM

# re: Kanban, Writing Code is Like Building a Car
Requesting Gravatar...
Great post Jon. It's eerie how you've exactly described our shop: QA is often the bottleneck. This is at least partially due to a need for further automation, though I also believe we're letting too many tasks pile up before they test so their workload is too inconsistent. It's feast or famine.

I've been struggling with how to layout my team's Kanban board and like your idea of tracking QA as a discrete step. We currently have separate "boards" for each user story with "To Do", "In progress" and "Done" steps. We just have a single task in each story for QA. This doesn't shine a light as brightly on the bottlenecks nor does it clearly display which tasks in a user story are QA complete. I think I'll give the 5 column approach a shot!
Left by Cory House on Jun 12, 2012 8:50 PM

Your comment:
 (will show your gravatar)

Copyright © Jonathan Mills | Powered by: