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:

1. The bag and the Kanban, part 1
2. The bag and the Kanban, part 2
3. Activity Modeling and the bag

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.

In the first part of this journey I posted about two value stream maps we created. The next step after doing Value Stream Maps of our two primary processes was setting up our KanBan board. I would first like to explain some of the thought we put into setting up our KanBan board. During our discussion on KanBan in Small Teams Dave said to not over complicate your KanBan board, and I agree. Especially for smaller teams there is no need to have a 15 state KanBan board. So what Hiren and I cam up with is shown below:

What we have is 3 states for a task to be in: Backlog, Work In Process (WIP) and Done. I think there are several important parts to our KanBan board:

1. Limits– Notice there are limits on the first two columns (Done is a feel good state, no limit), this is to create blocks when necessary and to prevent a state from filling up with a pile of inventory as is possible with other methodologies. The limits are in place to effectively block processes up stream from piling up. When a state is blocked no other work can be performed in that state.
2. WIP has two tracks – We are a small company so we are developers and IT guys both so we decided we should leave a spot open in WIP for an IT task. I am thinking about making it so that if a Red IT task is in the slot then that “Stops the Line”, a Red task would be an emergency or super high priority that was really preventing any other work from being done.
   1. I decided to keep the WIP limit at 2 thinking that we won’t have an item in IT very often and if we do someone is probably not working on a Dev item anyway.
3. Standard word definitions / Constraints – Below the bottom horizontal line is where we list the standard work definition or other constraints that are associated with each state.

So this board is setup and we were just about ready to start using it when I started watching the video from the open spaces session Chad uploaded on viddler, see KaizenConf Article. When I got to the point we were talking about laying out boards I realized I had forgotten a column. So we will call the board above v1 and the one below v2.

In version 2 we have added a column between WIP and Done called Deploy. My thought behind this was that we don’t do release per feature, yet, and we also don’t have a set release schedule but what I want to do is release features in batches of about 3. So the standard work definition for deploy is if there are 3 or more tasks/features in this state then we should schedule a release. I don’t have it in the picture but I am going to have a limit of 5 or 6 on this state.

We are going to run with this KanBan board for a week or two and see if we need to make further improvements on it in that time. If we do I will post them up here, if not then I might make the lines a bit more permanent so they are straight.

Next up I am going to discuss the layout of our KanBan cards.

I know this is a little late and somewhat out of order but I really feel compelled to write a public thank you note to all of the facilitators and attendees at the pre-conference workshops and the KaizenConf open spaces conference. I have made a boat load of new friends in the ALT.Net community that I know will be long lasting and very fruitful. The 4 day conference was by far the best conference I have ever been to. I came with so many questions got some answers and left with even more questions. It was very humbling to be surrounded by a lot of smart people, at the same time it is also very encouraging because these people are all very nice, friendly and real.

Workshops

The workshops that were put on were outstanding. I personally attended the Advanced NHibernate talk which was very helpful, you can see my notes here. I also went to the DDD Chalk Talk on Thursday afternoon, this was a very good talk about different aspects of Domain Driven Development. Friday started off with Jeremy and Chad’s Opinionated ASP.Net session and followed up with Dave’s Pull Don’t Push - Lean Systems and KanBan. All of these sessions were great. I have linked to what information is available now, and will link more as I find it.

Open Spaces

Friday night we “Opened” the space and one of the topics I suggested is Lean software engineering / KanBan with a small team. I didn’t know if anybody would vote for my topic or not but low and behold they did. So at my first open spaces event, I was also the convener of a space. This was a little bit intimidating at first but I handled it very similar to the way I do my college classes, we just all talked. Special thanks to Dave Laribee, Chad Myers, Chris Bilson and others that I don’t know your names, for being so involved and speaking during this session.

I spent time in some other very good sessions such as KanBan Applications, and Concurrent Set Based Software Engineering. There were so many good topics that I can’t even remember what all they were,  but there is a full list on the wiki.

As an action item on Sunday with KanBan in Small Teams I committed to documenting my teams implementation of the Lean Methodology with a KanBan task board.

In conclusion, Thank You again to all the great people in the Alt.Net community that came together in Austin to make this a very memorable event.

Tags: alt.net, KaizenConf, Lean

As promised at KaizenConf in Austin I am going to document our implementation of Lean Software Development as we go through the process of eliminating waste and creating a flow or pipeline process. We are in a unique situation as the rest of the organization is already following a LEAN approach for the most part due to the fact we are a Lean Manufacturer. So upon our return today we have gotten some guidance from internal “Lean Experts” and have started the process. The very first thing we did is two Value Stream Maps (VSM), this has helped us identify a couple of things already in the short amount of time it took to create them.

Value Stream Maps

I am going to first show the VSM’s and explain them a bit, then I will share some lessons learned already. Since we are a small company the IT department and Software Development department are one in the same, as in we do both. This means I need to have some value stream maps for both areas of concern. The VSM’s we created today are based on an average for each area. As we start and complete work in these areas I will create more VSM’s so that I have a better understanding of just where our waste and value times are and what happens in each. The way I like to create my value stream maps is that a box represents Value Add and a line represents no value add. Each box or line is then given an amount of time that a request/feature stays in that area.

Software Feature VSM

This is the VSM for a feature request in our company and it flows like this:

1. Customer Request comes in, usually via phone or email
2. Request enters To-Do List
3. Feature undergoes Design and Analysis
4. Feature enters Backlog
5. Development/Testing is done
6. Feature waits on customer approval
7. Dev/Test any fixes
8. Demo the feature with Customer
9. Release feature
10. Done Done

IT Request VSM

This is the VSM for an IT Request in our company and it flows like this:

1. Customer request comes in, usually via phone or email
2. Request then undergoes a quick Severity Check to determine how critical it is
   1. This gets a little interesting now as the path splits into two different paths, one for low or regular priority and one for high priority. The only thin different is the amount of time spent in each area.
3. Request enters To-Do list
4. Request is analyzed
5. Request gets worked on (WIP)
6. Request is complete.

Just creating these two value stream maps has identified a few errors that need to be worked on. The first area is Customer request, we need to create a standard way to handle requests. This should also put more responsibility on the customer than just accepting, “I need you guys to make X”. Second thing is that the VSM for a software feature is really just a guesstimated average right now. We have to work very hard to create like sized items to go on the KanBan board, which I will post about in a bit.

Tags: KaizenConf, KanBan, Lean, Value Stream Map