Introduction to the Kanban Method for Continuous Improvement

Introduction to the Kanban Method

Agenda
1. Basic Concepts
2. A bit of our real-world experience
3. Q&A

Kanban: Signaling
●Capacity signaling
●Work is always “pulled”, not ”pushed”
●Started at Toyota (TPS)
●We use it already in many places

Kanban Method
2. Limit WIP1. Visualize
work
3. Manage flow

Get to know…
Softwerks
■ A startup with 6 partners, developing mobile and web products
■ 1 marketing/finance/account mgr/PO
■ 3 devs
■ 1 designer
■ 1 QA/support engineer
■ They’re working on 3 projects to finance the development of their own product

They’re working hard
1. Lots of delays
2. Not sure who’s doing what
3. QA complains that many silly bugs should not land for acceptance testing
4. PO complains that their own product gets no attention
5. Many tasks have no clear prioritization, and customers and the commercial team
interfere a lot on sprint work
6. Lots of rework and unfinished stories
7. Some developers became very specialized on some bits of the product but never
touch other parts (some bits of code have an exclusive “owner”)
8. Nobody wants to deploy new versions of the apps because it’s a lot of work and
has to be done at night
9. Can’t see a way out of this, except work harder and harder

Kanban Method
1. Visualize
work

Backlog Done
1. Separated what’s really in progress and moved
unstarted work to a backlog
In Progress

2. Removed from the backlog old cards that had no clear
value or felt like “wishful thinking”
Backlog DoneIn Progress

Backlog AcceptanceIn Progress QA DeployDesign Done!
3. Mapped their current process

Anatomy of a Kanban
post-it
#435
RV, VC
15/11 27/11
Bug no gráfico
de acessos
Ref number
(JIRA, Pivotal,
Trello..)
Title
Start date End date
Responsible
Any other
relevant
signaling

Little’s Law
(1961)
Lead Time =
WIP
Throughput

Lei de Little
(1961)
WIP
Throughput
Lead Time =

4. Defined a goal for new WIP Limit
Backlog In Progress QA DeployDesign Done!Acceptance
WIP Limit = 20 (current: 33)

Doing Waiting Doing Doing Doing Doing
5. To stop “pushing work”, created some queues per
service
WIP Limit = 20 (curr: 33)
Waiting Waiting Waiting
Waiting

Doing Waiting Doing Waiting Doing Waiting Doing Waiting Doing
6. To reach WIP count of 20, they agreed on stop
starting new work until the current work in progress was
done

Doing Fila Doing Fila Doing Fila Doing Fila Doing
Stop starting, start finishing

7. They started running their dailies from right to left on
the board

8. Finally reached 20! Now they decided to keep at 20
for a while and see how it went

Cycle time
Avg weekly WIP
Avg cycle time
(days)
Week 1 33 8.7
Week 2 30 8.0
Week 3 27 7.5
Week 4 20 6.0
Week 5 20 5.1
Week 6 20 5.2

Avg WIP Avg cycle time
Throughput
(WIP/TC)
Week 1 33 8.7 3.7
Week 2 30 8.0 3.7
Week 3 27 7.5 3.6
Week 4 20 6.0 3.3
Week 5 20 5.1 3.9
Week 6 20 5.2 3.8
Cycle time

“
Theory of Constraint (ToC)
“A system of local optimums is not
an optimum system at all”

6 20 4 ?12 7
The throughtput of a system is equal to the throughput of its
bottleneck
Any attempt to increase the throughput of a system beyond that
will cause issues and affect quality
ToC: an analogy

ToC: a process of
continuous
improvement
1. Identify the current bottleneck
2. Ensure the bottleneck is working at its best
3. Subordinate the process to the bottleneck
4. Elevate the bottleneck’s performance
5. Repeat the process to find the next bottleneck

Scenario: Designer is available but the system is on WIP
limit

Suggestion: The designer helped with QA, and a dev was
allocated to deploy to reduce WIP

Scenario: QA is always overloaded (bottleneck)

Suggestion: Establish a WIP limit for QA
Backlog In Progress QA (4) DeployDesign Done!Acceptance

Backlog In Progress QA (4) DeployDesign Done!
Acceptance
Suggestion 2: Switch the order of Acceptance and QA
services so that a story wouldn’t go on QA twice

Backlog In progress QA (4) DeployDesign Done!
Acceptance
Suggestion 3: Dev team agreed on adopting unit tests
for new stories, to reduce the amount of work to be
performed by QA

Suggestion 4: The team will count stories that were
rejected on acceptance testing or QA, to track quality
improvement over time
Backlog In progress QA (4) DeployDesign Done!
Acceptance

Limite WIP = 20 (curr: 20)
Scenario: PO is too busy to perform acceptance testing
Backlog In progress QA (4) DeployDesign Done!Acceptance

Limite WIP = 20 (curr: 20)
Suggestion 1: Empower team to have a “proxy PO” who
can perform acceptance testing of non-critical work
Backlog In progress QA (4) DeployDesign Done!Acceptance

Doing Fila Doing Fila Doing Fila Doing
Backlog In progress QA (4) DeployDesign In Prod
WIP Limit = 18
Suggestion 2: remove acceptance testing from the
process, since the team feels they’re mature enough for
it. Let PO test cards in prod, and track rejected work to
see the impact of this change
With one service less, reduced WIP limit to 18

Backlog In Progress QA (4) DeployDesign In Prod
Limite WIP = 18 (curr: 18 + 2 urgent bugs)
Scenario: urgent bugs and requests show up and must
be worked on ASAP

Suggestion: Create an “expedite lane” which is part of
the process and is prioritized on top of everything else

Backlog Em dev QA (4) DeployDesign Feito!
Limite WIP = 18
Scenario: the team never has the chance to work on
their own product

WIP Limit = 18
Suggestion: the team agreed to put a “product card”
after every four “customer cards” (dedicate 20% capacity
to their product)

Backlog In Progress QA (4) DeployDesign In prod
WIP Limit = 18
Scenario: there are cards which only 1 person knows
how to implement them (specialist)

Suggestion: the team agreed that anyone can pull the
topmost work from the backlog, and request pairing
when needed
WIP Limit = 18

Scenario: the deploy queue is usually long and everyone
hates deploying at night
WIP Limit = 18

Limite WIP = 18
Suggestion: the team agreed that one member would
spend a week studying CI/CD and share what she
learned, and put some of it in practice

Let’s see that list…
1. Lots of delays
2. Not sure who’s doing what
3. QA complains that many silly bugs should not land for acceptance testing
4. PO complains that their own product gets no attention
5. Many tasks have no clear prioritization, and customers and the commercial team
interfere a lot on sprint work
6. Lots of rework and unfinished stories
7. Some developers became very specialized on some bits of the product but never
touch other parts (some bits of code have an exclusive “owner”)
8. Nobody wants to deploy new versions of the apps because it’s a lot of work and
has to be done at night
9. Can’t see a way out of this, except work harder and harder

Three Principles
1. Start with what you do now (use Kanban as a tool for your current
process)
2. Agree to pursue incremental, evolutionary change
3. Respect the current process, roles and responsibilities
How to adopt
Kanban

Limit
WIP!
What can you start
doing tomorrow?

I need some questions, who can help? 
Q&A

Introduction to the Kanban Method for Continuous Improvement

Recommended

Recommended

More Related Content

What's hot

What's hot (10)

Similar to Introduction to the Kanban Method for Continuous Improvement

Similar to Introduction to the Kanban Method for Continuous Improvement (20)

More from Rodrigo Vieira

More from Rodrigo Vieira (13)

Recently uploaded

Recently uploaded (20)

Introduction to the Kanban Method for Continuous Improvement

Editor's Notes