Kanban in a kitchen? A friend of mine used to be a chef, but he became a software developer. At the time he had just started on my team, and as an agile tester I used to help coach developers on testing. The idea being this was a team activity and everyone can test. The team where using WIP limits and BDD techniques to test first, and make sure all bugs found where fixed minutes later.
Now usually explaining the value in this takes some time to either new starts or to folks who are usually used to just firing work at testers and moving on. But this guy picked it right up, and LOVED the system. I had never seen someone take to the process so quickly. A lot of folks (myself included) tend to get stuck in their old ways of working. Learning is hard.
I was talking to him about it and he made me realise something. Kanban is EXACTLY how kitchens work. The goal of a kitchen is to get high quality food to the customer. Each team member whether chef or wait staff work together in a none silo’d environment to enable this to happen. This is exactly what we are trying to do as a software team.
An order comes in from the waiter, and the kitchen gets to work. They have systems in place to deal with each area. Eventually the food goes out to the customer. A wonderful example of this is in the film “The Founder”. The film focuses on how McDonalds become what it is today. A great watch, which I recommend. (Although you may end up hating the main character).
There is a scene in the film, where the owners of McDonalds explain their speedy delivery system. What they did was genius. They drew each area of the restaurant on the ground with chalk. Then got their staff to pretend to work on the various areas. By doing this they saw which area should be next to which, and how stream lining each section would best work. Cook the meat, prepare the bun, add the sauce etc etc. This is kanban in action. Visualise the process, test it to find waste, and make small changes to improve the process.
For coaches doing this is super important. Working with the team to visualise everything in your process is key, then you can start tweaking it to make it work. But also make sure nothing you try is permanent. In the McDonalds example they used chalk, as they knew they would need to make changes. It is important to be able to test your process. Make it part of your regular retro, run experiments by adding/removing lanes. Find what works for you.
So next time you are having a problem. Maybe your team is constantly fire fighting bugs, or maybe there is no way to prove value in your work. Try and think more like a restaurant. How can you work more like a chef? How can you improve your process? Give visualisation a go.
About the Author
Darryn Downey has worked as part of many agile teams, and is passionate about delivering bug free on time software using lean and agile methodologies. He has a passion for learning and enjoys sharing his findings with others. He has gone through a testing journey starting with automation and leading to coaching. You can read his testing and agile views here.
This is a syndicated blog post as part of our Deep Dive Week – Agile Edition. Thank you to Darryn for contributing this agile blog from Thoughts on Test.
Check out our schedule of live talks on EuroSTARHuddle.com or check out our on-demand section for a wide range of software testing talks.
