Professional Documents
Culture Documents
KANBAN
V1.0
KANBAN TECHNIQUES
Kanban is not a development life cycle or project/service management methodology but a method that
can assist you with product development.
It is a widely used tool for incremental, evolutionary maintenance and systems changes; many times
used when things cannot be predicted but must be solved as soon as possible.
2. Limit WIP
3. Manage Flow
6. Improve Collaboratively
Real-time depiction. The board is updated by team members as work proceeds, and
blocking issues are identified during daily meetings.
Limit WIP
Work in Progress (WIP) limitation. People should focus on finishing things and
understand and agree on it, instead of starting many things or committing to too
much work at once. By limiting unfinished items in the process stages, you can reduce
the time it takes for them to travel through the system and increase overall productivity of
the team. As queues are visualised, people start identifying the roadblocks and proactively
working on them. In this way you also avoid inefficiencies caused by task switching and
reduce the need to constantly reprioritize items.
Manage Flow
Flow analysis based on Lead Time (LT) and Throughput. Lead time measures the
duration from the moment something is conceptualised or enters the system until it is
delivered. Improving the system from an overall and shared perspective, in order to
reduce the Lead Time, increase throughput and smooth the flow, increases the ability to
frequently deliver value as well as predictability, which is minimizing risks by
expectations misalignment and helps build trust with stakeholders.
Improve Collaboratively
Collaborative continuous improvement process is carried out. People identify
impediments and perturbations that uneven flow and challenge WIP limits. They try new
approaches and adopt them if they are successful. That is a continuous process and not a
one-off, in which also the explicit process policies are expected to be changed for the
better. When using Kanban, everyone needs to be fostering a culture of continuous
improvement to reach the optimal performance as a Team/department/company, in
terms of lead time, throughput, quality, etc.
Organizations not allowing disruptive change. Since it is the only method from
the Agile community not requiring changes to current process, roles and
responsibilities it is very convenient for organizations where such a change would be
too risky or where a more disruptive approach is not possible or desired.
The workflow system (and its workers) are overburdened – There is too
much WIP, multi-tasking, task switching and queues of requests waiting to be
serviced which lead to stressed workers, poor quality as well as long and
unpredictable lead times.
o New request are taken only when there is capacity for working on them (not
overburdening workers), by priority order of the requests signalled as ready to be
pulled.
o In this way it minimises overproduction and waiting time of not finished items as
well as rework of systematic defects.
o It also defers to take prioritization decisions until the last responsible moment
(Just-In-Time).
Kanban helps maximizing the Team’s productivity by reducing queues in a workflow and
makes sure that everyone is focused. A Kanban board easily communicates priorities, flow
information and blocks in a visual way, the board indicates the work to be done.
Kanban uses visual management to make it easy to identify blocks and queues and to
reduce them.
In order to reduce concurrency and multitasking (which increase effort and time), Kanban
limits the number of items that can be in a process stage. That supports the idea of helping
maximise productivity and efficiency by focusing on the current thing to do.
Clear process policies are defined and made explicit, often by writing them next to the
Kanban board. This enables work standardisation and enables a rational and objective
approach to continuous improvement that eases reaching consensus.
As you can see, Kanban facilitates collaboration and teamwork, encouraging all people work
following the same goals and inspiring others to move in the same direction.
When using Kanban, we get progressively closer to the Agile approach without any radical
change; this facilitates transformation and gradually improves the production process. Kanban
enables you to identify the areas that need improving to focus your efforts, applying small
changes. It is incremental, evolutionary change.
Kanban is generally adopted with little resistance as it is seen more as a tool for inspecting the
current workflow rather than a change itself.
Kanban does not require a change in the processes and the first step is simply by start viewing
the current situation and mirroring it in the board. We can use the Deming circle to represent this and
the next steps.
The main objective is the continuous learning in order to keep improving the way that work is done
and thus provide better and faster service. Kanban unlike Scrum, does not impose a change in the
beginning but eventually may be doing something very similar in the end.
1. Start with the current process. Kanban is based on the concept of evolving the current
process, without radical changes or redesign the initial method of work, so, one way to start
would be in compliance with the current process, roles and responsibilities.
2. Follow a gradual and evolutionary change. Continue with those aspects of the
work process that work well and ensure an evolutionary improvement. Do not worry about doing
the perfect thing the first time and keep continually experimenting. Remember to truly
consolidate what was learnt to avoid a bouncing effect.
3. Assure process transparency. Make sure Teams have all they need to foster self-
organisation and continuous improvement. Kanban provides transparency regarding the
process and workflow, queues, blockages even lack of workload.
4. Make sure everyone have the same vision of the overall workflow status (queues,
waiting, lack of workload), inefficiencies and impediments roots to make the work more
collaboratively. Discussion of improvements, the consensus and the implementation of
actions that lead to the reduction of WIP and thus the Lead Time should be encouraged.
The Backlog column for example, contains elements to be developed; they can vary but are always
in a prioritised state. The one at the top is the next to be developed and cards flow through each
column as the different jobs are done. One important thing for you to have in mind is that items are
always pulled by a person when she is effectively ready to commit the job. This is known as “pull
system” or “on demand”.
- The person takes the job on board when is ready (last responsible moment). This allows
you to have the best possible and known priority and detailed requirement for the elements.
- Minimise waiting. People can plan on realistic scenarios where no more than the current
capacity is used.
As you would be able to see in the Estimation chapter, the human brain has a fantastic ability to
analyse visual information but struggles analysing the data. Placing a Kanban on the wall helps
people know what is going on, makes sure nobody forgets important things and finally assists making
decisions and keeping everyone aligned.
Cycle Time (CT) clock instead starts when commits to work on the request and ends when the item is
ready for delivery. As you can see, this is a more technical measure of process capability. Remember
that Lead Time is what the customer sees.
Limiting the maximum number of work items in progress at each stage encourages finishing the
requests and allows elements flow well as they gain speed and predictability in the global system.
When a good limit is established Lead Time (LT) is reduced. Note that we are pursuing flow efficiency
with this method and not resource occupation. A balance between cost of the delay and cost of idle
time should be evaluated.
You can also set limits on each sub-state, i.e. the columns from where elements are pulled ("Ready",
etc.).
Loss of focus.
Creates more relationships and dependencies (complexity) that finally reduces productivity.
You can start with a WIP limit per stage = 2n-1, where n is the number of full time people
working on that stage. The -1 is the reserved capacity to help remove blockages in other
stages. This limit also applies to the WIP of the entire system in the event of having a Team where
everyone can do almost anything at any stage.
Emergencies
swimline
In this case, everyone should understand its impact and what happens when something is added to
this row (i.e. high emergency, everyone should stop whatever is doing and solve it, etc.).
This starts to introduce the concept of “classes of service” that will be described in a while.
Extract from Kanban vs Scrum. How to make the most of both (Free book) - Henrik Kniber and Mattias Skarin.
On this, the vertical axis contains the number of items/ requests and the horizontal the timeline. The
idea is that information is shown cumulatively; the line goes up every time an item is finished in each
stage (Test, Development, etc.).
The horizontal space between the blue (Backlog) and the purple (Production) lines represents an
approximation to the Lead Time (LT) while the vertical represents how many items not started or
finished (Work In Progress) are in the Kanban. This chart can give you important information as it can
roughly help you estimate a delivery date.
In the context of product maintenance, there is often a SLA (Service Level Agreement) in place that
defines in which time frame you have, for example, to fix a bug; that time is the same as the Lead
Time.
When using explicit process policies, all actors know and share the same ideas (i.e., “I can add or move
a card if certain conditions are met”). This allows people discuss the problems and obstacles and
establish a common language and knowledge based on empirical concepts and tangible things.
An example of these policies is the Definition of Done (Read Chapter 4, Agile Requirements for more
information) where a list of things needs to be fully checked in order for a requirement to be considered
finished. Another is the Definition of Ready which specifies what is needed for an item to be included
into the Backlog column (i.e. “all requirements clearly listed”, “clear acceptance criteria”, etc.).
We also see that Policies work to improve the dynamics inside Teams and the combination of
Kanban board visualization with them is truly transformative.
There are three things I recommend you to have in mind when implementing explicit process policies:
- The fewer, the better. Simplicity should be considered at all times. We generally put things
there which either proves to be repeatedly problematic or especially important for the
Team.
By projects.
Alternatively and/or in combination, sticky notes with different colours can be used for
signalling the need of a different treatment / response time for specific requests. Remember that
everyone should understand its impact and what happens when something is in a specific line, so a
Kanban legend hanged on the board will also be very useful.
In this way, Kanban, Scrum, and Scrumban are options that can be used to manage product
development cycles. The three of them emerge from the Agile community and use the Pull
principle. Scrumban combines the pull principle and the work-in-progress limits from Kanban the
iterations from Scrum and allows some amount of unplanned items to pop-up in the middle of the
sprint.
PLANNING
In Scrum for example, Product Backlog items are pulled into to each Sprint. Tasks’
planning is regular and occurs in the beginning of each cycle. Project planning is supported by an
on-going activity called Product Backlog Refinement that takes place during the Sprint.
Kanban instead, does not prescribe a precise replenishment activity thus gives more freedom in
that area. For example, teams can choose to replenish when they run out of backlog items
(demand planning) or when the code or version is released.
In Kanban, items are not estimated –as a rule of thumb- items should be small and of a
similar size (split them if needed) in order to achieve a smooth flow, easily predict
behaviour and times. Instead of predictive estimation, Kanban uses probabilistic forecasting. It
uses historical data to model the expected capabilities and build a probabilistic forecast of the
project outcome.
PRIORITISATION
In Scrum the prioritisation is done by the Product Owner based on many parameters (Business
Value, risk, etc.).
In Kanban, you can still use this role and/or the Service Owner role, who is a person or committee of
prioritization who reflects the needs of all stakeholders and petitioners. They can meet weekly at the
board and decide what requests are prioritized for a specific week.
Urgency.
TEAM SYNCHRONIZATION
Scrum uses certain fixed meetings plus a synchronisation meeting called Daily Scrum.
Kanban can also benefit from a similar daily meeting but starts analysing blocks at the rightmost
side of the board, where there is the highest value (nearly finished work) and where to create more
capacity for pulling. This is why it is recommended to use magenta sticky tags to signal blocks
and their causes. In Kanban there is a further focus on identifying the queues between
stages and possible "bottlenecks" in the workflow.
RETROSPECTIVES
One core Scrum practice that can be lost in a Kanban transition is the retrospective, as learning and
corrections look more to be a “Just-in-time” process. Kanban does not prescribe regular meetings for
process improvement, but you should make sure that frequent process improvement activities
are carried out in order to improve the way that things are done (a core practice of Kanban).
ROLES
In Kanban there is no role definitions as it uses the current roles in the organization. You can still use
the same roles as in Scrum or define different ones. Nevertheless, it helps a lot when using the Kanban
Method to have someone focused on process improvement.
Remember that full responsibility from people involved is required to make sure that the
Kanban is updated..
Tags to indicate why a card is not flowing (reason for blocking, pausing,
etc.), tags for priorities, etc.
REMEMBER
You can use Kanban to create teamwork between different areas or departments that participate in the
value chain (Business, development, operations, etc.).
The more important things to solve at an operative level are blocks and queues, from right to left, in
order to create flow.
WIP Limits, Process Policies and even Kanban stages can vary on time as the Team learns.
Process improvement activities should be carried out frequently.
ADDITIONAL RESOURCES
Kanban vs Scrum. How to make the most of both (Free book) - Henrik Kniber and Mattias Skarin.
Scrumban - Essays on Kanban Systems for Lean Software Development - Corey Ladas
Lean from the Trenches: Managing Large-Scale Projects with Kanban - Henrik Kniberg
Kanban - David Anderson.
LeanKanban University
BENEFITS
Start with what you have approach, respecting current process, roles and responsibilities.
Continuous delivery and focus on finishing things.
Flexibility and Just-In-Time prioritization.
Improves the way to work in non-easily schedulable environments.
Helps you predict an average response time per request.
Reduction of idle time and wasted work (over production, rework of systematic defects), so increasing
productivity.
Allows people visualise, understand and share a common understanding and goals. Increases team
focus by shared system overview of priorities, blocks and even lack of workload, so promoting collaboration
and teamwork.
Helps to avoid overburden in the workflow system and its workers.
Incremental, evolutionary changes. Fosters a mindset of continuous improvement based in visualization
and explicit work standardization.
Easy way of introducing Lean – Agile principles.