AWB - 10 - Kanban

337 Agile White Book – AXA Emerging Markets EMEA-LATAM
Chapter 10
KANBAN
V1.0

Contents
WHAT WILL I GET TO KNOW FROM THE CHAPTER? ...................................................................................................................................................... 340
THE KANBAN PRINCIPLES ..................................................................................................................................................................................... 341
PRINCIPLES OF THE KANBAN METHOD ....................................................................................................................................342
GENERAL PRACTICES OF THE KANBAN METHOD ........................................................................................................................344
WHERE TO USE IT ................................................................................................................................................................347
WHAT IT TRIES TO SOLVE ......................................................................................................................................................348
WHAT IT IMPLEMENTS .........................................................................................................................................................349
WHERE TO START ............................................................................................................................................................................................ 350
HOW TO CREATE A KANBAN BOARD........................................................................................................................................351
KNOW LEAD TIME AND CYCLE TIME .......................................................................................................................................353
SET A LIMIT ON WORK IN PROCESS..........................................................................................................................................354
MEASURE YOUR LEAD TIME AND CYCLE TIME ..........................................................................................................................357
DEFINE EXPLICIT PROCESS POLICIES .........................................................................................................................................359
MANAGE THE DIFFERENT KINDS OF WORK................................................................................................................................361
UNDERSTAND THE KANBAN, SCRUM & SCRUMBAN DIFFERENCES............................................................................................................................... 362
PLANNING..........................................................................................................................................................................362
ESTIMATION.......................................................................................................................................................................363
PRIORITISATION ..................................................................................................................................................................363
ITERATIONS ........................................................................................................................................................................364
TEAM SYNCHRONIZATION .....................................................................................................................................................364
RETROSPECTIVES .................................................................................................................................................................364
ROLES ...............................................................................................................................................................................364
VISIBILITY...........................................................................................................................................................................365
EXAMPLES.................................................................................................................................................................................................... 366
TAKE AWAY.................................................................................................................................................................................................. 368

Kanban
Kanban is a management method for improving
service delivery in an evolutionary approach. It uses
boards to visualise the products creation flow
through its different stages. It is oriented to
continuous delivery and Just-In-Time production.
Kanban implements a “pull” system based on each
stage capacity and it increases flow by limiting work
in progress.
Kanban enables people to collaborate in a more
efficient way and emphasises on improving the
process by continuous learning. It enables you to
identify the areas that need improving to focus your
efforts, applying small changes (evolutionary
change).

What will I get to know from the chapter?
KANBAN TECHNIQUES
I know the benefits of visualising processes in a Kanban.
I know how to use the Kanban techniques.
I know what to do to improve the system.
LEARN TO
VISUALISE THE
CURRENT
PROCESSES FLOW
KNOW HOW TO
IMPLEMENT A
KANBAN
KNOW
HOW TO
ESTABLISH
RULES
LEARN HOW TO
IMPROVE & USE
WITH OTHER
FRAMEWORKS

The Kanban principles
Kanban uses a set of Visual Management techniques that help you see, “touch” the process flow and
define a set of rules to improve the way that work is done. It uses a physical board plus cards that are
moved -following some clear policies- across the columns in order to reach a result.
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.

PRINCIPLES OF THE KANBAN METHOD
I have found that Kanban allows people work better as they agree on 4 principles:
1. Start with what you have
2. Agree to pursue incremental, evolutionary change
3. Respect the current process, roles, responsibilities & titles
4. Encourage acts of leadership at all levels in your organization
Start with what you do now
This method does not require you to change your current process. It is the only
method from the Agile community that takes this non-disruptive, evolutionary approach.
There is no engineered change to a new process but an evolution of the current process
based on collaborative improvement.
Agree to pursue incremental, evolutionary change
Everyone agrees on a slow, gentle, evolutionary, iterative approach. Maybe
because the context or the politics make it too risky to try a more disruptive change; or
maybe another approach has already failed or encountered resistance.

THE Kanban principles
Respect the current process, roles, responsibilities and job titles
Preserve everything the organization does that already works. We eliminate
initial fears by agreeing to respect current processes, roles and responsibilities. This
agreement often facilitates obtaining support to the Kanban initiative.
Encourage acts of leadership at all levels in the your organization
Improvement requires strong leadership. This leadership can come from every
level in the organization. A culture of safety must exist to encourage individuals to
push change.

THE KANBAN principles
GENERAL PRACTICES OF THE KANBAN METHOD
I have found that Kanban allows people work better as they agree on 6 core practices that also you
can follow:
1. Visualize the workflow
2. Limit WIP
3. Manage Flow
4. Make Process Policies Explicit
5. Implement feedback loops
6. Improve Collaboratively
Visualize the workflow
Representation of the current process. Teams use a Kanban board (often a
whiteboard or electronic board) organized into columns, each one representing a stage in
the process; and optional rows for splitting among different types of work, for example
Classes of Service (to be managed under different priorities).
Visualization and understanding of the work, workflow and business risks by
everyone involved. The Kanban board indicates where each piece of work is in the
process in context of each other, and let the team identify queues, bottlenecks, business
risks and even lack of workload promoting collaboration. It seeks to make the invisible,
visible. When something is seen, it is easier to identify a problem and come up with a
solution. This is especially true with a process that cross different specialities or areas;
everyone can have a slightly different idea about what it entails and what are the current
cross impacts and dependencies if flow is not visually represented.
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.
Single-piece-flow. Continuous delivery and Just-In-Time is achieved by implementing a
pull system. When an item is finished, the next highest priority item is pulled (instead of
pulling batches as would be a Sprint Backlog) if there is available capacity within the stage
WIP limit.
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.
Make Process Policies Explicit
Explicit rules are followed for moving a card. Strict “process policies” are
established in order to objectively define which things are expected or should happen
when moving a card. Explicit understanding enables discussions about how process
improvement to be rational, empirical and objective rather than emotional anecdotal or
subjective. This approach often leads to consensus around improvement suggestions.

Implement feedback loops
An evolutionary process requires feedback loops. A feedback loop takes the
outcome of the process into consideration and routes it back as an input forming a circuit.
The purpose of these loops is to compare the expected outcome to the actual ones and
make adjustments to the process. When Kanban is implemented at an organization level
four specific practices for feedback are used: the standup meeting; the service delivery
review; the operations review; and the risk review.
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.

WHERE TO USE IT
Kanban particularly supports services and projects where the most important thing is continuous
delivery and the time resolution of every single request. And is especially suited for
environments where disruptive change is not desired:
 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.
 Non-easily schedulable environments - Places where there is no defined scope
and there is no anticipation of the work coming. Each day brings a new challenge.
For example: operations, systems changes and evolutionary maintenance.
 Environments where priorities change very frequently or where is a need to
put order in a chaotic environment- Places where deferred commitment is
desirable because early commitment is causing excessive re-work and wasted effort.
Nevertheless this can be is a signal of lack of good product management before
setting up priorities and it should be improved.
 Places where maximum delivery flexibility is required – For example when
you can’t wait to specific times to "package" requests (if that was the case, Scrum
would be more suitable). In these places, the development start of a request and its
release are initiated as soon as possible (but always considering Kanban principles
and rules as pull, WIP limits, explicit process policies, etc.).
 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.

Three threats are generally found in systems
which erode productivity: blockings,
concurrence and unordered activities.
WHAT IT TRIES TO SOLVE
 Kanban as a pull system tries to solve the following things:
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.

WHAT IT IMPLEMENTS
A good thing about adopting Kanban is that it doesn´t mean refitting your existing methods and
processes. Kanban provides a way of visualising what you are already doing –without changing it- and
then identifying which parts of the current approach impact efficiency and change them.
This is way team empowerment and involvement for this identification and solution are key,
as they are knowledge workers who struggle everyday with the problems in the trenches.
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.

WHERE to start
This is what I suggest you when implementing Kanban:
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.

WHERE to start
HOW TO CREATE A KANBAN BOARD
You start by identifying the major stages to be used and draw them in columns. A typical
Development Kanban board should look like this:
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”.
Remember that a pull system brings the following advantages:
- 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.
- Minimise re-work. As it is taken at the very responsible moment, possibility
for things to change or jobs that “are not needed anymore” is reduced.

There is something very clear now which is
that it doesn’t make any sense to
continue sending tasks to a blocked
column! and instead work on unblocking
it in order to create flow (fixing the
current issue and/or improving the system
using causal analysis).
WHERE to start
In order to have an effective Pull System, we advise you split the board in “In Progress” and
“Ready” status for each stage to clearly mark the boundaries of when something is prepared to be
taken to the next stage or it is still incomplete.
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.

WHERE to start
KNOW LEAD TIME AND CYCLE TIME
There are two very important concepts to understand in Kanban which are Lead Time (LT) and Cycle
Time (CT). Lead Time clock starts when the request is made and ends when it is delivered.
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.

The most effective way to deliver faster is to limit work
to capacity in order to maintain a continuous flow.
WHERE to start
SET A LIMIT ON WORK IN PROCESS
Once you have drawn the columns, it’s time to set the limits.
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.).

When the right Work In Progress is chosen,
you will notice that elements flow smoothly as if
they were no limit.
WHERE to start
The "ideal" WIP limit (one that produces the best flow) depends on the project, stage, composition of
teams, etc. People generally try a certain WIP limit and go raising or lowering it until finding the right
value; an Agile Coach can assist you with this task.
Consequences of high WIP limit
 Lead Time (LT) high.
 Lead Time (LT) variability.
 Increase on "Idle" requests.
 Long waiting queues.
 Reaction time to blockings increases.
 Loss of focus.
 Creates more relationships and dependencies (complexity) that finally reduces productivity.
Consequences of small WIP limit
 Lead Time (LT) small.
 Increase on "Idle" People.
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.

WHERE to start
There is another scenario where a Work in Progress is set but there are urgent jobs that need to be
taken on board. In this case, a special emergency swimline can be created to prioritise over the
normal flow.
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.
Emergencies
swimline

WHERE to start
MEASURE YOUR LEAD TIME AND CYCLE TIME
Measuring Lead Time helps predict and plan deliveries and compromising on certain requests. It
will also tell the Team and Management how much time they need to finish a certain request. In this
way, everybody can understand the measurement of the time spent and there is no need for
complicated equations. One chart which is especially useful is a Cumulative Flow Diagram (CFD).
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.
As a result of that, we can have 3 very important pieces of information:
 An approximate idea of how long an item takes or Lead Time(LT).
 The number of items that are not finished/started in the system.
 An idea of a finishing date if scope is not highly changed.

WHERE to start
We could also triangulate this information with other data, such as team size, changes in the
Team, etc., in order to get more valuable information.
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.

WHERE to start
DEFINE EXPLICIT PROCESS POLICIES
When people are working together, a lot of implicit assumptions and policies are at play. It is normal
for individuals have different ideas about what a process involves. This kind of things leads to
misunderstandings and ineffective Teamwork, conflicts and more expensive processes.
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.).

You can start by writing the developer’s
Definition of Done and mapping it to a
stage on the board.
WHERE to start
As you begin to post policies, Team members generally become curious and open the door to
discussion. Remember that explicit policies can also be associated to any stage (column) and
even at any sub-status (In Progress, Ready) as long as the Team believes it improves what is
produced.
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:
- Criteria must be demonstrable, verifiable and understood by everyone.
- Writing policies in sticky notes proves useful and easy to change.
- 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.

WHERE to start
MANAGE THE DIFFERENT KINDS OF WORK
You can also design a Kanban by having in mind the types of works to be done and the ones that
need special treatment/different rules. For that to happen, rows or “swimlines” are added to the
board to separate the different criteria. For example:
 By type of work / classes of service (emergencies, projects, evolutionary, defects, support)
that need a different response time.
 By projects.
 Works related to areas/departments.
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.

UNDERSTAND the Kanban, Scrum & Scrumban differences
As we have seen, Kanban is a technique that helps display the value chain and uses Just-in-time As
we have seen, Kanban is a method that helps visualising the workflow and uses Just-in-time
concepts in prioritizing and Pull to limit work to capacity. Since Kanban is not a development
process or framework, it is sometimes complemented with Scrum principles and practices
to create cadenced control and create synergies among team members. Continuous work
is used along with short iterations for planning (for example once a week).
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.

A semi-automatic prioritization mechanism can also be used and
based on diverse criteria such as:
 ROI (business value vs. cost) and strategy factor.
 Urgency.
 % Effort to spend by type of work (e.g. 80% for new
projects, 20% for maintenance and support).
 % Effort to spend per project or product.
 Stakeholder or person who asked for it (i.e. CEO, etc.).
ESTIMATION
Relative estimation is a commonly used Agile technique to determine the time required to finish a
requirement/request/item. In Scrum, the estimation of the time required for the items to be
completed is done in the Product Backlog Refinement and reviewed in the beginning of the
Sprint. As there is a cycle, it is important that items are shorter than the time allocated for the
time-boxed cycle.
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.

Kanban allows adding new items or reprioritise
them whenever WIP limits and system capacity is
respected. Therefore, Kanban is very useful for
functions with Just in time and continuous
flow.
ITERATIONS
In Scrum, an iteration is the heartbeat of product lifecycle and define how new items are added to
the iteration. In Scrum, it is discouraged to add new items during the Sprint. If there is a
new item, it is better to wait until the next Sprint in order to be developed. If the project also
requires dealing with some unpredictability (e.g. support or emergencies), it is generally a good
idea to use Scrumban. But if there is a lot of unpredictability or continuous need of
reprioritizations, the best option is to use Kanban.
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..

VISIBILITY
Regardless of the approach you use, it is a good idea to provide as much visibility as possible having in
mind that the key performance metric in Scrum is the burn-down chart and the cumulative flow
diagram and others related to the Lead Time (LT) in Kanban.
These are some ideas of the charts that can be created:
Charts & Metrics
Cumulative Flow Diagrams.
Throughput by type of work.
Dedicated effort by type of work.
Product Backlog Burndown per project, etc.
Diagrams
Architectural maps, models, product maps.
Calendars
Release calendars or Roadmaps.
Vision, medium-term goal or purpose.
Distinctive
Visual Help
Tags to indicate why a card is not flowing (reason for blocking, pausing,
etc.), tags for priorities, etc.
Avatars (or name-tags in different colors) for team members to easily
identify who is working on what. Note that a maximum number of
assignable avatars are an indirect way to limit Work in Progress (WIP).

EXAMPLES

TAKE AWAY
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.

AWB - 10 - Kanban

Recommended

Recommended

More Related Content

What's hot

What's hot (8)

Viewers also liked

Viewers also liked (20)

Similar to AWB - 10 - Kanban

Similar to AWB - 10 - Kanban (20)

Recently uploaded

Recently uploaded (20)

AWB - 10 - Kanban