LEAN -Software Development in Small Teams - Part 1 – Value Stream Mapping
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:
- Customer Request comes in, usually via phone or email
- Request enters To-Do List
- Feature undergoes Design and Analysis
- Feature enters Backlog
- Development/Testing is done
- Feature waits on customer approval
- Dev/Test any fixes
- Demo the feature with Customer
- Release feature
- Done Done
IT Request VSM
This is the VSM for an IT Request in our company and it flows like this:
- Customer request comes in, usually via phone or email
- Request then undergoes a quick Severity Check to determine how critical it is
- 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.
- Request enters To-Do list
- Request is analyzed
- Request gets worked on (WIP)
- 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.