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.
@ Expretio Buddies
ReplyDeleteI carefully choose the term "Digital" to please Said ;)
Very nicely done. Thanks Charles.
ReplyDeleteI 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
Thanks Alex,
DeleteYou 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
Color codes
ReplyDeleteI 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?
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
ReplyDeleteRed 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.