This document discusses applying lean and agile principles to maintenance teams. It provides tips for using collaboration and optimization techniques like having continuous integration and delivery, using swim lanes and a hot lane to prioritize work, ensuring defects are testable by writing test cases after reproduction, measuring lead times and cycle times, and conducting regular retrospectives to continuously improve. Leadership techniques include rotating team members between roles, meeting with them face to face weekly, and implementing a pull system to avoid interruptions from issue notifications.
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptx
Maintaining Stabilisation with Kanban
1. Maintenance Stabilisation
kaizen WIP kaikaku flow value
stream mapping visualize
work flow cycle
time lead time throughput
TPS build failed CFD
created by
Zsolt Fabók
me@zsoltfabok.com October 25, 2011 @
twitter: @ZsoltFabok evoline, Cluj Napoca, RO
3. Two myths about maintenance and
Kanban:
"Maintenance cannot be done with teams."
"Kanban is designed for Maintenance."
Fortunately, both of them are wrong!
7. Defects aren't different from tasks, user
stories or work items
● Easier to handle and manage teams
● Maintenance is not a punishment
● Methods/frameworks fit better
8. Data collector script
● [semi] automatic
● No more arguments over missing log files
● Collects what the team needs
9. Different daily stand-up with managers:
● task oriented
● talk about new defects
● prioritisation for each column
● transparency
● faster reaction time
● spending time on work items which really
matter
10. Prioritise by
● business value
● cost of delay
● service level agreement (SLA)
● actual resource availability
● current capacity and load
photo: http://agileconsulting.blogspot.com/2011/03/using-cost-of-delay-functions-to.html
11. Design discussion every afternoon
● follow up the ideas from the stand-up
● technical help on the investigations
● two heads are better than one
12. Write your own bug reports
● easier to close them
● external findings are duplicates
● they will be filled out correctly
13. Communicate through mailing lists
● archived, searchable
● everybody can see, contribute
● no more annoying direct contact from bug
reporters
14. Mentor and coach other teams
● give them feedback on their work (they may
have introduced the defects)
● improve current processes in order to have less
defects later
15. Keep the size of the Cloud small, and the
Live large
● large Cloud is really demotivating
● takes too much time to review a large Cloud
● large Live is really motivating (+ managers like it
better)
16. Throw away old defects
● don't bother with old (more than half a year)
defects. If they are still necessary, someone will
write you a mail. If not, it wasn't that necessary
18. Have continuous integration, staging
machine and continuous delivery
● packaging and regression problems will be
discovered sooner
● failed build immediately indicates a problem
photo: http://www.infoq.com/articles/Continous-Delivery-Patterns
21. After reproduction, write a test case
● reproducible -> testable
● if another fix broke this fix it will be visible immediately
● much faster integration and delivery
22. You cannot test what you code yourself,
always have somebody else do it
● improves verification
● distributes knowledge (test and domain)
● less work items will be rejected at validation
23. Measure everything, really everything
● lead time -> how much time we need to fix a defect
● cycle time -> where can we improve
● capability + lead time + inflow -> helps estimation
24. Collaboration and Optimisation
Tips and Tricks
(Leadership techniques)
photo: http://carterkellyconsulting.com/lifepoint_leadervisionspirit
25. Do not wait with the retrospective, do it on
the spot
● maintenance is continuous, regular scheduled
meetings aren't effective
● people forget things very fast
● empowers Lean thinking
26. Rotate people between Reproduction and
other phases
● it is demotivating to do only one thing
● team members can hide
● feedback loop
27. Talk to team members face to face on a
weekly basis
● maintenance is not motivating, people open up
better in a face-to-face meeting than in front of
the group
● prevent unnecessary fluctution
28. Turn of the issue/defect notification emails
● don't let the system interrupt your work
● implement a pull system for your own
29. Thank you very much for your attention!
For more check out my
website:
http://zsoltfabok.com/
or follow me on RSS:
http://www.zsoltfabok.com/
blog/?feed=rss2
and Twitter:
@ZsoltFabok