Kanban originates in Lean Manufacturing at Toyota, as a way to reduce waste and manage flow. So what does this have to do with me or software development?

I have been using Kanban to visualize workflow and coordinate team work at the office for more than 3 years now, and it has become my favorite agile and lean software development practice. So much so, that I cannot imagine leading a project or developing a feature without one. The main reasons I love Kanban is that it fosters communication, empowers team members and encourages evolutionary change and continuous improvement.

By merely visualizing the day to day workflow (not what you would like your workflow to be, but what you are currently doing), the team starts having timely and targeted discussions about what is needed to complete high priority work. Communication increases and an always elusive shared vision starts to emerge.

Another practice of the Kanban method is limiting work in progress. WIP limits allow the team to focus on just the top priority work and nudges the team towards pairing and swarming, thus increasing collaboration and cross-pollination.

There are 4 other practices that are part of the Kanban method, including managing flow and making transition policies explicit. I will write more about them soon, but for now you can go to the Wikipedia article for more information.

Personal Kanban

I have a very fulfilling full-time job, 2 very active toddlers and no family around to help take care of them. So about 2 years ago, I started using personal Kanban to try to put some order into my life outside of the office. You can think of it as a to-do list on steroids. It forces you to constantly prioritize and identify which task is more important for you to work on next, allowing you to focus on one thing at a time, and it ensures you are committed to finishing it before you take on a new task. Yes, you should try it too!

Getting started

If this is something you are interested in bringing to your work or life, below are some resources that should help you get started:

“Kanban is based on a very simple idea. Work-in-progress should be limited and something new should be started only when an existing piece of work is delivered or pulled by a downstream function. The kanban (or signal card) implies that a visual signal is produced to indicate that new work can be pulled because current work does not equal the agreed limit.”– David Anderson

Kanban vs Scrum

29. February 2012 by ariadna
Categories: Agile, Kanban | 1 comment