A *very* small introduction to Kanban. Covers the basic rules and some peculiar aspects of the methodology.

1. Kanban
a quick intro
by Matteo ‘Peach’ Pescarin (@ilPeach)

2. Kanban (かんばん) literally means “signal cards”.
Was developed as a process management system by
Taiichi Ohno during the ‘40s at Toyota, in order to improve
and maintain a high level of production.
Its aim was to reduce problematic areas by reducing the
number of signal cards in circulation.
The Kanban method used in software development was
introduced by David J. Anderson as an approach to
incremental, evolutionary process and systems change for
organizations.
History (sort-of)

3. Leanest of the Agile methodologies
Kanban is part of Agile
more prescriptive more adaptive
RUP
(120+)
XP
(13)
Scrum
(9)
Kanban
(3)
Do Whatever
Kanban is the most adaptive methodology available with
only 3 basic rules:
● Visualise your workflow
● Limit your WIP
● Measure the lead time (average time to complete one
item, or cycle time)

4. Kanban underlying philosophy
● start with what you do now
● agree to pursue incremental, evolutionary
change
● respect the current process, roles,
responsibilities and titles.
These are also the base for a Lean pull
system and the building of a
continuous improvement (Kaizen) culture.

5. Some myths and notes
Kanban is adaptive, meaning that nothing else
apart from the basic rules, is mandatory. The
team commits to improve the process by
analysing it.
Kanban, being so agile, can be made up of
different practices and tools (e.g. paired
programming, typical of XP, can be used, as
well as sprint retrospectives or stand-ups,
typical of Scrum, or anything/nothing else).
Same goes for roles, timeboxed iterations,
etc...

6. Visualise the workflow
As in SCRUM, Kanban uses a board (either
physical or digital) to visualise the workflow.
The main difference between the two is that
some columns are limited.
Also, the Kanban board is not reset at the end
of each iteration.

7. In SCRUM the WIP is limited per unit of time.
In Kanban the WIP is limited per workflow state.
The general idea is to limit all the workflow states.
The board is persistent and changes can happen at any
time (which is disruptive in Scrum).
Limit the WIP

8. Notes on WIP limits
The only thing needed is to agree who is able to modify
what.
Cross-functional teams are perfectly counted in the process
and can work along in a Kanban workflow.
Same goes for multi-projects.

9. Measure the lead time
Once we have WIP limits in place we can start measuring
and predicting lead time, i.e. the average time for an item to
move all the way across the board.
Having predictable
lead times allows us
to commit to SLAs
(service-level
agreements) and
make realistic
release plans.

10. Notes of lead time
As in Scrum, lead time measurement can’t be
always correct. Although its impact is not
directly related to the estimation of each ticket.
There are no precise rules on how many
columns you should have in the board, what is
you WIP limit, or what roles you need.
The commitment to an evolutionary change
should drive the adaptation based on facts.

11. Further reading
http://www.infoq.com/minibooks/kanban-scrum-
minibook (from which I’ve taken the images :P)
http://www.infoq.com/minibooks/priming-
kanban-jesper-boeg