A marine once told me how the maintenance and repair shop for helicopters worked during his deployment in Iraq. All of the birds in need of maintenance, repair, or inspection sat in a large tent with a giant whiteboard near one wall. Whenever a shift would start, everyone would gather around the board and discuss what needed to be done on each aircraft. The board had a list of choppers on the left followed by several columns representing the state of work. Cards were created for each task and added next to the name of the associated bird. As the task progressed from ‘Todo’ to ‘In Progress’, and eventually to ‘Done ‘the card was moved to the corresponding column. Once the team talked over what they were doing that day and updated the cards, they would all get to work, occasionally returning to the white board to move a card horizontally across the board. Whenever a senior officer called to ask for a status update on a bird, the team would simply look at the board and immediately know the current state of all work on that specific chopper.
This team was using an Agile Project Management framework called Kanban. The framework is based around breaking work down, making it visible, then improving the process to increase flow. Flow refers to how smoothly and quickly work moves from todo, to done. The goal of Kanban is to visualize work to bring to light anything that is slowing down the process. This is how it works:
The kanban board is an array of columns drawn on a board. Each column represents a state of work. A simple Kanban board will only have three columns: Todo, Doing, Done. a more complex board will be expanded to include more details around each step. An example from a software development team may include the following columns: Todo, Research, Design, Proof of Concept, Approval, Build, Test, Deploy, Done. The point is to get granular enough to visually show the state of all work inside a team or a process.
These boards are also used in manufacturing processes to show where specific orders are at as they flow through the system. In the example of software, each task or feature would be represented by a card. For manufacturing, each order may be represented by a card. The cards are created and added to the ‘Todo’ Column when the work is released into the system. This may come from a project controls person releasing work into a process, it could come from customers entering in help desk tickets, or it could come from a team agreeing to take on certain tasks during a specific period of time like a sprint if the team is using Scrum. Once the card is added to the todo column the team members responsible for the next column can pull cards into their column when the work begins. The cards get pulled into the next column as the work item progresses through the process.
One of the most powerful concepts of Kanban is that it shifts the traditional concept of pushing work down the line and replaces it with the idea of pulling work when the workcenter or team is ready. This simple nuance is rooted in Lean Manufacturings Just-In-Time philosophy. Essentially it teaches that the customer should be the driving force of demand rather than the supplier. Not only does this concept work with an outside customer and supplier, but it also works with the concept of internal suppliers being the previous step in a process, and the internal customer being the next step in the process. For example:
Say you have a software development process where Product Management defines the requirements for features before handing it off to Design. Then once Design is done it goes to the engineering team to build. (I am not advocating for this type of Waterfall approach by the way. See my article on Agile for a better way.) In this scenario, Design is an internal supplier of Product Management, and an internal customer of Engineering.
With the traditional push method, Product Management feels that they have achieved success if they stack up a pile of work for Design to do. This generally leads to Design spreading their resources out as thin as possible with everyone working on multiple things trying to keep up with the ‘demand’ for their services. In this scenario it’s not the demand, driving the frenzy though, it’s an over zealous supplier trying to achieve their own goals. The consequences of this are dire as it slows the organization down significantly due to the phenomenon known as the switching cost theory. It also creates a queue of work between the Product Management group and Design meaning that any new feature will now take exponentially longer to get through the system.
Contrast that with the concept of pulling work when the customer is ready. In this scenario, Engineering would be the internal customer. If Engineering could pull work directly from Design rather than from a Queue, Design would be left with capacity. This would intern be filled by Design pulling the next project from Product Management. With this concept you can keep queue lengths short or eliminate them completely so that projects moved through the process faster. You would also keep people focused on fewer projects at a time, freeing them up to move faster based on their ability to focus. This puts the customer as the one who sets demand, or speed of production, which intuitively makes more sense.
This concept is hard for many people to grasp and even harder for people to be willing to adopt. We all fall into the trap of suboptimizing our own step in a process so that our numbers look good, and so we can point the finger at others when the boss asks why we are not moving faster. To cure you of this I will point to the principal of suboptimization.
“Optimizing each subsystem independently will not in general lead to a system optimum, or more strongly, improvement of a particular subsystem may actually worsen the overall system.” – Robert Machol, 1965, pp. l-8
Now that you understand the importance of pulling work based on the demand generated by the customer, the question becomes: how do we keep work from stacking up in large systems when one step in the process is faster than the other steps? The answer is that we establish WIP limits on each step, then we allow the organization to self adjust. Let me explain.
WIP, stands for Work In Process. It is the count of batches of work at any given phase in a process. On a Kanban board, each column represents a phase, so by counting the number of items (generally represented by cards) in a column, you will have the current WIP volume for that phase. When you establish WIP limits you are saying that a given step is not permitted to exceed X number of items in that column. This creates a forcing function for the system to self balance. If one step is moving too slow the entire system is able to see it because all other steps slow down. This creates time and focus for everyone to help improve the slow steps speed so that the speed of the entire system is increased. This forcing function eliminates flaws in the process and forces the system to get into a synchronized rhythm that can be sped up as the customer demand increases.
The above are tactics to accomplish the goal of building fast and efficient systems and processes, but they do not achieve the goal in and of themselves without continual reflection and refinement. Kaizen is the Japaneese term for “improvement”. It is used in Lean Manufacturing and Kanban to describe the feedback loop that must drive continual improvement in order for the concepts to achieve maximum effect. A Kaizen ceremony or workshop is often held on a recurring schedule to get feedback on the process and to make iterative changes to improve the flow of work.
So let’s review.
- With a Kanban board you can map out any process to make the flow of work visible.
- By shifting your mindset to pull work from column to column instead of pushing work down the line, you speed up your organization and decrease total lead time.
- When you establish WIP limits you create a forcing function that helps a process self balance.
- You must make time for recurring Kaizen events to reflect on the process and improve it.