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

ConfidentialPA12012-07-201

Maintenance using Kanban

Beijing experience

Rune Hvalsøe


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


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

http://en.wikipedia.org/wiki/Nokia_Life_Tools


Maintenance

maintenance


Original way of working

DB with issues

10 issues

20 issues

30 issues

Responsibility Active work

Issue 1.....Issue 4

Issue 1.....Issue 6

Issue 1.....Issue 5


First attempt

• Scrum and maintanence– Does NOT work


Great wall II


Kanban flowIm

pedi

men

ts

Bac

klog

100+

Wor

k in

pro

gres

sW

IP =

1

Rea

dy fo

r te

st

Rel

ease

d

Ver

ified

and

clo

sed

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.


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


Out

put

Time

+70%

Significant decrease in output

Team of 12 developers working with maintenance – switching to Kanban


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/

http://blog.codinghorror.com/the-multi-tasking-myth/


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

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

Engineering

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