Wednesday 18 February 2015

Kanban System Deployed


Published with the authorization of Expretio technology


The following article is an example of a Kanban System that I designed for a software development company. Each organisation workflow have their own particularities so this should not be seen as a guideline.


Obeya room

A war room was dedicated to project visualization, architecture diagrams and daily meetings. One side of the room contain an heijunka board covering an entire wall, a small ressource allocation board and a digital heijunka board on touch screen.



A standup daily meeting is held every day at the same time to update all the boards. The room act as a converging point for strategic planning. It's map the entire team works and should bring an understanding of our system immediately and intuitively. 

Used by people of different roles, the room dissolve division between the department of the organisation.


Heijunka Board

The goal of the heijunka board is to visualize our entire value chain, from idea or concept to software in production. It's also make policies explicit and give a quick feedback based on objective data that allow us to track and optimize the flow.

The board give three essential informations:

  • what to produce
  • when to produce
  • how much to produce


 
The board itself is built from two magnetic whiteboard steel panels for a total of 10 feets long by almost 8 feets high. The lines and labelling are done from vinyl tape and stickers. No writing is necessary, the board is entirely managed with magnetic accessories for clarity and efficiency.

It is divided horizontally by stages or columns and vertically by swim lanes. Kanban card flow inside swim lanes through all the stages until completion.


Stages

The different stages of our workflow are shown as columns on the board. They are the steps required to bring work items from concept to working software.



A stages contain the following sections:

  • Criteria: determined what need to be met in order to move a work item to the next stage.
  • WIP limit: the maximum number of items in the stage. This include the items in both queues. Work in process limit is a fundamental aspect of Kanban. Further reading may be required to fully grasp the idea.
  • In progress queue: contain the item currently targeted by team members and not yet completed.
  • Done queue: contain the completed items that are waiting to be pull to the next stages. To be part of the done queue, a work item must respect all the criteria.
Swim lanes

Swim lanes can be used to split the board vertically so different type of work or project can flow independently. Each lane may have different policies regarding WIP limits and criteria. We don't mix the metrics between lanes: each swim lane record their own cycle and lead time.

Apart giving an overview of the activities of various project in parallel, having multi lanes on the same board also give an interesting feedback when resources are reallocated to different project or product.

Let say you move 2 team members from the development to the research lane, you will be able to probably observe a direct impact on the both lane simultaneously with some lead time gained on the development lane and some lead time reduction on the research lane.




It's a common practice to have a Urgent / Expedite lane for critical item. This particular lane have usually a WIP limit of 1 and should not be used frequently. Each item flowing in this lane affect the lead time of other lanes and can be a signal for some quality problem so we always keep an eye on it. 


Kanban cards


 
The kanban cards represent work orders. They are laminated 5” x 8” index cards and are reused after reaching completion. Formulated by following the user story convention, they are detailed in the project tracking software.

On the card itself, we only write a short description under the ticket number. When a team member is assigned to a card, a round magnet used as the person avatar is placed beside the card.

We use the following colors to qualify and distinguish the various class of work order:

  • Red: Rework item. More this waste appear frequently on the board, greater is the chance you got serious quality problems.
  • Blue: Valuable item for your customer that bring revenue to your organisation. Should be the most common item on the board.
  • Yellow: Non functionnal item. Improve the infrastructure by decreasing the lead time of the blue card and/or decreasing the frequency of red card.
  • Purple: Kaizen event. As it flow in the lane, it's trigger a team workshop event in each stage. Environment improvement and productivity optimization of the targeted stage is the goal of the event. A kaizen card always appear when 15 cards have been completed.
 
Tasks cards

 
When a kanban card reach a specific stage, it may be necessary to break it down in smaller task so team members can individually target portion of the work to be done. 

In our workflow, the tasks are defined in the TASK stage so when the work order reach the CODING stage, the tasks are ready to be targeted by programmers.

The task need to refer to an explicit and well defined area. In our case, tasks refer to architecture layers and are represented by small laminated colored card. Instead of writing the layer description on the card, we used again a color convention. By example, the persistence layer is pink and the presentation layer is green.

When a team member target a task, we put his avatar on the card. Once all the tasks are completed, we move the kanban card to the done queue.

 
Digital Heijunka Board

Digital board contain the same stages as the physical board. In our case, we were using a JIRA kanban board on a 40 inches touch screen.

After updating the physical board, we replicate the change by dragging the items on the digital board.

Using both physical and digital versions of the board and doing a little double bookeeping may first appear as a form of overhead but it's well worth the investment. 

Digital board is useful for generating various report on the lead and cycle time without effort. Cumulative flow diagram is a particulary expensive report to produce without a digital board. It is also practical for allowing off-site team member to collaborate.

You may be tempted to use only the digital board but it's usually a bad idea. A physical board is a better information radiator. It's always available, bigger, more visible to the entire organisation and easier to update.




Ressource Allocation Board

A ressource allocation board is installed beside the Kanban Board.




It's main function is to give an overview of the resource or team members that are not currently working or assigned to a production stage. The board contain categories such as vacation, sick leave, corporate event and client meeting.

We also use calendar date magnet with the resource in the vacation category so we know with a peek when someone should come back to work.

It's can be interesting to record metric for this board as well. By example, you may determine an average of corporate event per week, vacation leave for each month, etc. These trends may then help you for future planning and kaizen event session but be aware of bad corrolation before making conclusion.

A section of the board is reserved for storing magnetic accessories and unused kanban cards.



5 comments:

  1. @ Expretio Buddies
    I carefully choose the term "Digital" to please Said ;)

    ReplyDelete
  2. Very nicely done. Thanks Charles.
    I would suggest people to first try the kanban part before going to the heijunka.
    First to understand how the kanban flows and the wip limit. There would be some natural balancing (help from others) when a stage is full.

    I like what was built in terms of using the heijunka for urgent items. I would need more explanations on the research lane

    ReplyDelete
    Replies
    1. Thanks Alex,

      You are right, they have a natural balancing that occur when a stage is full since card from the upstream stage cannot enter it. People effort will be realigned to the downstream stage where they are the most needed so the congested stages can eventually start to release their card

      I should demonstrate this dynamics with pictures since it's help to really grasp the idea behind the flow and the WIP limit.

      Thanks for your observations

      Delete
  3. Color codes
    I would be curious to know more about how the purples code is used: is it when there are too many items, triggering a kaizen event, or is it a review (lessons earned)

    I see also the red color, which is rework. Does this replace the technical debt tracking, or is it in complement?

    For the JIRA kanban board, is it updated daily?

    ReplyDelete
  4. The purple card appear when a specific number of card have been completed and are no more on the board. They flow following the same constraint as the other cards. The kaizen event term may not be the appropriate one since it's not targeting the whole but only the stage where the card is currently located. It's more a lessons learn or a retrospective with only the stage in scope. You may as well trigger a real kaizen event (with no card on board) after a certain number of completed cards or from a schedule

    Red card are for bugs but also include rework due to wrong user need analysis, bad specifications or design. They are actual work that need to be redone because the initial released feature was flawed.

    Technical debt are targeted by the criteria of each stage. If they eventually pass through, they are eliminated via a yellow card but you can think of introducing a new color code to differenciate improvement from debt if the later became frequent.

    The Jira Kanban board is updated at the end of every daily meeting to reflect the changes of the physical board. The both need to be kept in synch. The JIRA board is available to everyone for consultation but only the person that lead the daily meeting may modify it.

    ReplyDelete