ConfidentialPA12012-07-201
Maintenance using Kanban
Beijing experience
Rune Hvalsøe
ConfidentialPA12012-07-202
Background
• Building up UI development and maintenance
– Expat in Beijing (2007-2009)
– Nokia’...
ConfidentialPA12012-07-203
The story
• It all started October 2008, I met with
Ronan Jezequel (French) in Beijing
– Ronan ...
ConfidentialPA12012-07-204
ConfidentialPA12012-07-205
Original way of working
DB with
issues
20 issues
Responsibility Active work
Issue 1
.....
Issue...
ConfidentialPA12012-07-206
First attempt
• Scrum and maintanence
– Does NOT work
ConfidentialPA12012-07-207
Great wall II
ConfidentialPA12012-07-208
Kanban flow
Impediments
Backlog
100+
Workinprogress
WIP=1
Readyfortest
Released
Verifiedandclos...
ConfidentialPA12012-07-209
Second attempt
• Scrum -> Kanban
• We wanted to spread knowledge
• We wanted to secure priority...
ConfidentialPA12012-07-2010
Output
Time
+70%
Significant decrease in output
Team of 12 developers working with maintenance...
ConfidentialPA12012-07-2011
Conclusion
– 70% increase in output, this was clearly not what we expected
• We removed an uni...
ConfidentialPA12012-07-2012
Executive summary
• We found that switching from traditional
way of working to Kanban gave us:...
Upcoming SlideShare
Loading in …5
×

Maintenance using Kanban | Rune Hvalsøe | LTG-20

459 views

Published on

Presentation held at Lean Tribe Gathering 20 in Malmö May 6 2014.
See more presentation at: http://leantribe.org

Published in: Engineering, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
459
On SlideShare
0
From Embeds
0
Number of Embeds
49
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Maintenance using Kanban | Rune Hvalsøe | LTG-20

  1. 1. ConfidentialPA12012-07-201 Maintenance using Kanban Beijing experience Rune Hvalsøe
  2. 2. ConfidentialPA12012-07-202 Background • Building up UI development and maintenance – Expat in Beijing (2007-2009) – Nokia’s S30 platform (low cost, 100M/year) – Approx. 15 UI-developers – Lack of skilled SW developers in general – Maintenance (+bringup) – New stuff • 90 - 10
  3. 3. ConfidentialPA12012-07-203 The story • It all started October 2008, I met with Ronan Jezequel (French) in Beijing – Ronan gave me a crash-course in Scrum – We tried Scrum in a 4 man team, • 3 developers • Me as lead architect, SM and PO (first story DoD in a couple of hours...) • Amazing experience! http://en.wikipedia.org/wiki/Nokia_Life_Tools
  4. 4. ConfidentialPA12012-07-204
  5. 5. ConfidentialPA12012-07-205 Original way of working DB with issues 20 issues Responsibility Active work Issue 1 ..... Issue 4 Issue 1 ..... Issue 6 Issue 1 ..... Issue 5
  6. 6. ConfidentialPA12012-07-206 First attempt • Scrum and maintanence – Does NOT work
  7. 7. ConfidentialPA12012-07-207 Great wall II
  8. 8. ConfidentialPA12012-07-208 Kanban flow Impediments Backlog 100+ Workinprogress WIP=1 Readyfortest Released Verifiedandclosed Kanban Chief Errors If an error require extra trace etc, it will be moved to impediments and developer select a new error while waiting for input – when the input comes, the error manager will move the error back to the backlog. Show stopper errors would be marked with a red dot to indicate that they have to be fixed first. Kanban chief will put errors on the prioritized backlog when they have sufficient description including needed log files with relevant trace Developers can only have one active error(s) at a time in work in progress.
  9. 9. ConfidentialPA12012-07-209 Second attempt • Scrum -> Kanban • We wanted to spread knowledge • We wanted to secure priority • We wanted to build stronger team feeling • We wanted better time estimates  Our findings was not even close to our expectations  Trying something ”new” sometimes give the un-expected  We wanted to be faster
  10. 10. ConfidentialPA12012-07-2010 Output Time +70% Significant decrease in output Team of 12 developers working with maintenance – switching to Kanban
  11. 11. ConfidentialPA12012-07-2011 Conclusion – 70% increase in output, this was clearly not what we expected • We removed an unidentified time consumer – task switching, people (developers, project managers and people managers) did not see that this was causing delays in deliveries, actually most people felt that they were less effective after the new wow, because they had idle time – however statistic showed that we were 70% more effective due to the focused way of working - I guess at this time, most people was admiring other people who was solving many complex things concurrently, an interesting article about the topic can be found here: http://blog.codinghorror.com/the-multi-tasking- myth/
  12. 12. ConfidentialPA12012-07-2012 Executive summary • We found that switching from traditional way of working to Kanban gave us: – 70% performance increase • Understanding that task switching cost is HUGE – Better overview of remaining work – Better priority - Always fixing the most critical issues first – Better knowledge sharing – Happy developers – Less stress

×