Kanban: The Board
In my previous article Kanban: The Journey Begins I discussed the problems we faced in our team and how Kanban might be able to solve them. Now lets make the board…
The journey continues
The most important tool in Kanban is, without any doubt, the big whiteboard. It is the core feature for visualization and forces communication and collaboration.
But to benefit from all these features we need the actual hardware setup.
To the toy store!
To start this Kanban stuff for our team we got the following:
- 1 Big magnetic whiteboard
- 30 Big magnets (each member on the team has 1 set of 10 magnets in their preferred color)
- 20 Small white magnets
- 10 Medium red magnets
- 3 different colored markers (to write on the whiteboard)
- “a truckload” Post-its (in 3 or 4 different colors)
To know how to structure the board I analysed past projects and tried to figure out the stages that all projects within our team have in common.
In an attempt to identify and name these steps I looked at a lot of different Kanban boards.
Finlay I came up with this first draft for our Kanban-structure:
- Backlog: The To-Do-List
- Preparation: Research, cost-benefit analysis, and gathering all tools to start the project
- On Deck: Work in progress
- Release: Implementing the project into the production environment
- Completion: documentation, cleanup, and evaluation
At any stage there is also the possibility that a project gets put “On Hold“, mostly because our team has to wait for another team to complete a part of our project.
Every step in the project flow is a column. Projects start out in Backlog and work their way to Completion.
If a project goes “On Hold” for any reason during any phase of the flow it gets moved to the “On Hold” swimming lane but still in the same column.
One of the features of Kanban is workload limit control. This is putting limitations on the amount of tasks that can be in a certain phase/column at the same time. I put limitations on two columns, “On Deck” and “Release”.
The workload limit on the “On Deck” column is set so that everyone on the team can have only one project they are actively working on (we got a team of two system engineers). The “Release” workload limit is one because for troubleshooting purposes it is not recommended to be releasing two projects at the same time.
Because of these workload limits I got another problem. If, in our example, a project is finished in the “On Deck” phase but the “Release” phase is still working on another project, then it is not possible to move the project to the “Release” phase nor is it possible to indicate that the project has actually finished the “On Deck” Phase. That is why I split up every phase into two columns, “P” for pending and “D” for done. The workload limits only apply to the “Pending” column, giving the opportunity to queue up projects before moving them to a workload limited phase.
Many bigger projects get split up in several smaller projects. I wanted a system to see what projects are connected. I decided to create a “Work In Progress” column in the Backlog. This column would hold a card for each big project that has any part in any phase other than the Backlog. With a simple number on every card that is part of the same bigger project it is easy to see what projects are connected.
Now that all projects are ready to flow I still need a means to visualize “who is doing what?“. Each team member get his own set of colored magnets to indicate what they are working on. In system engineering it is not uncommon for a team member to be working on several projects at the same time because of the “waiting” factor so every member has several magnets to indicate all the projects they are working on.
I also need a means to indicate an “Alarm” on a project. I decided to use some red magnets to be able to indicate that a project has a problem or requires special attention. These red magnets are a good trigger for collaboration if you are not using the “daily stand-up” principal. If a team member notices a red magnet he will automatically know to ask what is going on.
The “Trash” is simply so we can go back on a decision to discard a project and to have a means to see what we have already completed.
Because many projects require and upgrade of a current system or an expansion of the current infrastructure we often have project chains. The problem with these chains is that you often lose track of the reason why you started the project in the first place. To keep track of the “Reason” we started any project I decided to stack chain projects on top of each other. So when one project is completed you take the post-it off the stack and the next project in the chain becomes visible.
I have a Kanban board that is completely adjusted to the structure and the needs of my organisation and team.
We can finally start Kanban!
See how our Kanban board evolved after a few months.