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