1. Our experience
Daniel Céspedes Daza

2. Agenda
1. Kanban in a nutshell
2. Kanban in SW development
3. Scrum – Kanban similarities
4. Scrum – Kanban differences
5. How to apply Kanban
6. How we applied Kanban in our project
7. Conclusions
8. Questions
9. Sources

3. 1-Kanban in a nutshell
• Kan-ban (看板) = Signal-card.

4. 1-Kanban in a nutshell - JIT
• In the late 1940s, Toyota started studying store and
shelf-stocking techniques from supermarkets

5. 1-Kanban in a nutshell – Queue Mgmnt
• Cashier focuses on taking order
• Barista focuses on supplying coffee
• Separated by queue allowing variable demand
to be “absorbed”
• Cashier moves to help Barista when no
customers waiting to order
• Focus is on end to end FLOW = customer-
centric

6. 1-Kanban in a nutshell – Process Mgmnt
Tool
Principles
Make work Visible
Limit Work In Progress
Help the work Flow

7. 2-Kanban in SW development
The Kanban method formulated by David J. Anderson.
1st virtual kanban system for SW engineering was
implemented at Microsoft en 2004
Kanban method as an approach to change
started to grow after Agile 2007 in Washington
DC

8. 2-Kanban in SW development
• Is an approach to change management.
• It isn’t a software development process or project management
methodology.
• Kanban is an approach to introducing change to an existing software
development process or project management methodology.

9. 2-Kanban in SW development
• Kanban leverages many of the proven concepts from Lean including:
• Defining Value from the Customer’s perspective
• Limiting Work in Progress (WIP)
• Identifying and Removing Waste
• Identifying and Removing barriers to Flow
• Culture of Continuous Improvement

10. 2-Kanban in SW development
• Kanban encourages incremental evolution of existing processes.
• Kanban does not ask for a revolution of how people work, rather it
encourages gradual change.

11. 2-Kanban in SW development
• Kanban is based on a very simple idea. Work In Progress (WIP) should
be limited.
• The kanban (or signal card) implies that a visual signal is produced to
indicated that new work can be pulled because current work does not
equal the agreed limit.

12. 3-Scrum – Kanban simmilarities

13. 4-Scrum – Kanban differences

14. 5-How to apply Kanban?
• The principle of Kanban is that you start with whatever you are doing
now.
• You understand your current process by mapping the value stream.
• You agree to WIP limits for each stage in that process.
• You then start to flow work through the system by pulling it when kanban
signals are generated.

15. 5-How to apply Kanban?
• Visualize the workflow
• Split the work into pieces, Stories we already do that.
• Use named columns to illustrate where each item is in the workflow.
• Limit Work In Progress (WIP) – assign explicit limits to how many items may
be in progress at each workflow state.
• Measure the lead time (average time to complete one), optimize the process to
make lead time as small and predictable as possible.

16. 5-How to apply Kanban?
Lead Time =
Customer View
Cycle Time = Internal View

17. 6-How we applied Kanban in our project?
•Process – we modeled our process
•Work – we decided the unit of work
•WIP limits – limit WIP to help work flow
•Policy – set quality policies
•Bottlenecks and flow – move resource to bottlenecks
•Class of Service – different work has different policies – done definition
for each state
•Cadence – Releases, Plannings, Reviews

18. 6-How to apply Kanban in our project?
We modeled our process

19. 6-How to apply Kanban in our project?
Value Stream

20. 6-How to apply Kanban in our project?

21. 6-How to apply Kanban in our project?
iProtect : internal

22. 6-How to apply Kanban in our project?

23. 7-Conclusions
History:
Team: 14 members, 8 at Arg, 6 at US. 2 years doing Scrum with 1-week sprints
(3 years Scrum in total) before shifting to Kanban
Kanban implemented 6 months ago on TFS (Visual WIP) with some Scrum
practices (PO, Scrummaster, standup, review, retrospective)

24. 7-Conclusions
Benefits
Simplified “pull” system to the team, visibility on workflow and bottlenecks
Stories defined as per valuable product rather than to fit within an iteration, with
less and clearer gauges (lead time, WIP limit) with more focus on work product
With clearer “Done” criteria for each column (state of a work item) quality
became integral part along dev process. Stabilization reduced from 2 months to
2 weeks.

25. 7-Conclusions
To-do
Still difficult to have mid-long term visibility (e.g. done-not done for next release)
Results
1st release done March with 15 stories and 160 bugs fixed. Beta released 2-
month ago to experts and early adopters (1st time a beta is provided).
Lead time 60 days average per story, while with Scrum it was ~90. (lead time
~45 days for next release).

26. 8-Questions

27. Sources
1. Kanban - Wikipedia
2. Lean Manufacturing - Wikipedia
3. Taiichi_Ohno - Wikipedia
4. TechDays Kanban
5. Hydra Pros Cons discussion
6. Kanban by Dave J Anderson
iProtect : internal