Lean with Kanban is Not One Size Fits All
I have to say that I am very excited about all the lean software development process talks that have been buzzing around in the community lately. This is generating lots of good first hand experience that is being shared with the community which I think is excellent. I would like to talk about two main points tonight, a pet peeve of mine that I just need to rant about for a few lines and second I would like to point out some of the other great stuff that is out there and discuss it a little.
Lean is the Process, Kanban the Tool
I personally think that a lot of people equate Kanban as being
the methodology or even worse an equivalent replacement to Agile or Scrum. This is absolutely not the case, KanBan is not even a methodology like the others. This is a very important point that is often overlooked, especially when new people are trying to learn and apply Lean practices in their software process. Kanban is a Japanese word meaning literally “Signal Card” or “Signal Board”. A Kanban board is just a visual tool used to signal flow and show limits of the process and to create the signal for the pull flow of the system. Derick Bailey has a great easy to understand example of a Kanban in the shape of a grocery store over on his blog. I work for a Lean Manufacturer and we don’t use a “Kanban” in the traditional sense per say because we do not pass cards around the manufacturing floor, we do however use signaling and that is what KanBan is really all about. We refer to our signaling system as our “Supermarkets”, what these supermarkets are actually physical spaces in the production area that are designated for certain types and variations of product. When a supermarket has an empty space, somebody up the process builds the product to refill that supermarket. To the right is a picture of one of our actual supermarkets, this is a bed supermarket.
Whether you are using cards, boards or supermarket’s the most important thing is that it is creating a signal in the pull system, and this enables flow. The two other really important pieces that Derick does a good job explaining are Order Points and Limits with his grocery store example so I won’t go to far in depth on this. These are two very basic items that every inventory management system has or should have at least. You obviously wouldn’t waste money shipping one box of cereal from General Mills every time a custom took one off the shelf. These just provide a way for the store or the development team to manage the amount of inventory they carry.
I kind of got carried away on what a Kanban was so let me get back on topic. A KanBan could be useful for various methodologies I think but it really shines if you are doing Lean Software Engineering. Lean is the methodology and I think there is a fear rising up within the software community that a lot of teams are just going to “Cargo Cult” this stuff and it really doesn’t work that way. Lean is a way of thinking, just like many of the Alt.Net principles. There are no hard and fast guidelines to implement Lean in 14 days, it is a process and takes time. Even then if you are practicing lean you will never stop implementing lean. I will get off my soap box but I just want people to know the difference between the tools and the methodologies.
Lean comes in Different Sizes
This is what I am really excited about right now. I know of 3 people currently implementing (or hoping to) Lean in their teams right now. The best part of this is that we are sharing the processes that we are following to make this as open as possible for other teams to follow along with. This is great because we are all in different teams, sizes, makeup, skill level, etc… So we should see some very different yet exciting results come out of all this. I committed to documenting my implementation at KaizenConf and have started with a few posts on what I have done so far. Louis Salin also has a series of great articles on his blog that are a recap of several sessions from KaizenConf combined with his own thoughts on this implementation and guess what, It isn’t that much different from the rest of us, only it is his way, which is awsome!
Louis Salin – The bag and the Kanban:
Louis has got some great ideas here, especially the bag idea. This is something very similar to what I have been thinking of / calling my “To-do” list. I will expand on this topic in a few days, we are currently re-working the way we deal with items before they make it on the backlog.
Derick Bailey – Adventures in Lean
Derick Bailey has just started his series, “Adventures in Lean”, and I think this will be very interesting to follow as well. Derick’s team is a larger team that I have for sure, and I think larger that Louis’ team too.
Ryan Kelley – Lean in Small Teams
I am documenting the Lean implementation in our team as we go along. I will continue to write about this, good things and bad so hopefully other people can learn from what we are doing. That said, we are a very small team, in fact if we were any smaller we wouldn’t be a team. Some may think that for a 2 – 4 person team you don’t need to do Lean but I say that is Bull****. One of the main reasons we are “Going Lean” is to bring some formality into a process that hasn’t ever had any before. We are probably the most disciplined department in the company with regards to how we work, so we need to share the discipline around a little and off-load more responsibility to the customer.
Until next time, I hope this as whet your appetite for more Lean / Kanban discussions.