Title: Achieving the potential of Kanban: Use LEAN

1. Achieving the potential of Kanban - Use LEAN
Avinash Rao
1

2. What a difference a year makes.
2

3. 3
At LKI 2015
• MF to New Gen transformation, $12 M / year vendor spend
• 30% extra effort – we (i.e., the client) decided to rip and replace the architecture after a fixed
price was agreed
• Fixed bid, timelines - Desperate times, desperate measures
• From an ongoing LEAN initiative, we determined that cutting out wait times will help achieve
the target
• Without telling management, we stopped estimating, and moved to a Kanban board

4. 4
Results
• We delivered the 6 month development program 15 days ahead of schedule, without
weekend work

5. 5
Then we (i.e., I) learnt the wrong lessons from this success, and applied it to the
next program
… and that’s the story for today.

6. 6
Factory Migration
• $5M Migration contract
• Bucket of migrations, to be migrated at a Catalog price depending on size
• Client does not pay for overhead, so need to keep costs down
• Freedom to choose how we delivered the work
• Tailor made for Kanban!

7. 7
And so we started off …
• Process workshop to formalize the process, columns and swim-lanes; set up in a tool in short
order
• We got our large screen TV 
• Built the team to 50% of the capacity

8. 8
And so we started off …
• Process workshop to formalize the process, columns and swim-lanes; set up in a tool in short
order
• We got our large screen TV 
• Built the team to 50% of the capacity
… and waited

9. A slow start
9
• For the first two months, demand was closer to 20% of capacity (for reasons
unrelated to the project team)
• So moving our Kanbans on the board was a mechanical exercise

10. And then as demand picked up …
10
• We quickly saw a pile up before testing
• Which, of course, simply means that testing was understaffed relative to
development, for Flow
• So we increased testing
• Still the throughput was low

11. And then as demand picked up …
11
• And so, we applied WIP limits
• Though why people would pick up multiple items in a low constraint
environment was a mystery
• And the capacity needed for development went up

12. And then as demand picked up …
12
• And so, we applied WIP limits
• Though why people would pick up multiple items in a low constraint
environment was a mystery
• And the capacity needed for development went up
!!!

13. Taking stock
13
• So, we took a step back and took stock
• The TV was unused, and the board discredited
• And this in what was an idea application for Kanban

14. 14
Back to the drawing board
• Why does Kanban improve throughput in IT?
 The power of averaging (“use variability”)
 Schoolboy problem
 Bunch the buffers to the end

15. 15
Applicability in the current case
• Why does Kanban improve throughput in IT?
 The power of averaging (“use variability”)
 Schoolboy problem
 Bunch the buffers to the end

16. 16
Comparing the original approach
 Piggybacking on an existing LEAN initiative
 Defined and, more importantly, aligned the process ahead of the Kanban rollout
 As an example
 Dev and QA clashed on the measurement of a defect
 No common understanding of what is ‘pull’ing the system
 Defect ping pong – gaming the board

17. Deep v/s Shallow
• “Deep” Kanban v/s “Shallow” Kanban
• The same discussion we have been having in Agile!
• The rituals are (relatively) easy
• The process looks easy
• But the right application to our situation needs skill
• Process
• Re-engineering (ugh!)
• Political (ugh again!)
17
Both political skill and
capital

18. 18
Here’s some suggestions -
• Don’t ramp up teams in advance – the inbox of your Kanban board must be full !
• The process side benefits from a perception of capacity constraint
• You need a full time coach!
• Lead with a LEAN initiative; as much as it helps the process, it aligns goals and vocabulary

19. 19
Questions?
Thank you!