Lean in Software Development
8 likes7,141 views
This document summarizes key lessons from examining different types of flows and finding ways to reduce waste: - Intersecting flows can cause disruptions, so it's important to buffer flows if they are manual or embed flows if automated. - Rapid feedback can cause thrashing while slow feedback wastes energy, so finding the sweet spot through experimentation is important. - Personal, team, and multiple flows all need to be considered to reduce waste and increase value. Only through examining interactions and tradeoffs can flow be optimized.
Lean in Software Development
- 1. Lean Software Development An SD Times Webinar with Kent Beck and Henrik Kniberg Aslam Khan :: @aslamkhn :: +Aslam Khan :: factor10.com :: aslamkhan.net factor10
- 2. Personal Flow finding waste in my day to day work design next generation architecture write some mini frameworks develop legacy replacement strategy teach, mentor, code review ... TOO MUCH WORK!! why? TOO MUCH WORK!! no! MOVING between different locations too frequently why? SWITCHING to different task far too frequently which is why there is ... Lots of ALMOST COMPLETE work
- 3. Cleaning up waste what do you actually have control over? What is my chain of waste? MOVING too frequently SWITCHING frequently ALMOST COMPLETE work motion task switching partially done work Which waste do I have CONTROL over? partially done work task switching motion
- 4. What did I learn? DO look for the chain of waste DON’ T try to eliminate waste but or the root causes which is out of your control (over optimization) DON’ T try to be too precise DO work with good gut-based but in your estimations gross estimations (over analysis)
- 5. What did I do? buffer and limit work in progress task switching partially done work motion buffer the tasks tasks started were prioritize and only moved around by limiting to 2 in completed before queue each task when needed each category taking another task
- 6. Team Flow finding waste in the overall development process Kent Beck’s value stream map (from “Lean Software Development, An Agile Toolkit” by Mary and Tom Poppendieck) customer requirements planning development code freeze approval changes 4 weeks 4 weeks 8 weeks 3 weeks work wait 2 weeks 4 weeks 2 weeks there may be some ‘quick’ wins below the line but ...
- 7. Big wins … big wins are above the line customer requirements planning development code freeze approval changes 4 weeks 4 weeks 8 weeks 3 weeks work wait 2 weeks 4 weeks 2 weeks ( big wins achieved with small changes may be are more lasting )
- 8. At another team with whom I work estimate and complete unit development review commit tests 1 day 3 weeks 1 day 2 days work wait highly optimised wait time
- 9. Look above the line too but what’s this? estimate and complete unit development review commit tests 1 day 3 weeks 1 day 2 days work wait They write tests in development but it is like “tag team” TDD … I write the code, tag out You write the tests, tag out I write the code ... ( which is not really TDD at all)
- 10. What is the real problem? estimate and complete unit development review commit tests 1 day 3 weeks 1 day 2 days work wait went for continuous integration as a quick win which resulted in pressure to have high coverage from unit tests but no one had done TDD before
- 11. Lessons I learned DON’ T believe that automation DO look for ways to automate but comes for free (automation is a highly mature state of development) DO look at the impact of automation ( what are the upstream and downstream demands? ) and use low fidelity options at the first responsible moment ( what is the simplest first attempt at this automation? ) and use high fidelity options at the last responsible moment
- 12. Multiple Flows waste as a result of different many processes The flow for one of the product managers the intention is to share new knowledge frequently prepare share prepare share prepare share release next iteration requirements with team requirements with team requirements with team planning planning 1 week 1 day 1 week 1 day 1 week 1 day 1 day 1 day work wait ( this is quite common in Scrum with backlog grooming )
- 13. Multiple Flows waste as a result of different many processes Same flow from the development team perspective prepare share share share release next iteration requirements with team with team with team planning planning 1 day 1 day 1 day 1 day 1 day work wait 1 week 1 week 1 week lots of wait time ?
- 14. Intersecting Flows waste as a result of different ‘mini’ processes Let’s superimpose this flow with the team flow estimate and complete unit development review commit tests 1 day 3 weeks 1 day 2 days work wait 1 day 1 day 1 day share share share with team with team with team the product manager flow disrupts the team flow
- 15. Disruptive Flow occurs when different flows intersect it reminds me of different currents flowing in river … n g ni p lan u ct r od p development n ing p lan u ct d pr o … when they meet, little whirlpools form ( lots of little whirlpools, frequently enough, can be quite disruptive )
- 16. Constructive Flow occurs when different flows are buffered or embedded create buffers between flows works well for manual or semi-automated processes buffer create embedded flows works well for highly automated processes ( because it’s automated, the touch point is a tiny, lightweight buffer )
- 17. What did I learn? Small intersections, frequently enough, can cause nasty whirlpools in your flow so Buffer flows if it’s manual or Automate a flow and embed it ( but remember the automation challenge from earlier )
- 18. Feeding back into a flow knowing when to act on valuable feedback defects are tossed right back into development for immediate attention Software installed in production and in use toss defects back in go live development work wait
- 19. Thrashing towards stability when we react to all feedback immediately thrashing for stability ( linear reaction to change )
- 20. Buffering manual flows avoiding disruptive intersections of flows defects get ‘work arounds’ and bugs are queued go live development planning work wait Software installed in production and in use 3 1 queue bug bug bug bug 2 workaround workaround workaround ( the system is neither stable nor unstable )
- 21. Gently gaining stability when we choose which feedback to react to and when to react gently gaining stability buffered feedback ( non-linear reaction to change )
- 22. A Lesson in Electronics 101 the system is somewhere between two states but it’s in neither state V-in +15V V-kettle + U1 - R1 -15V R2 this feedback loop ... …. causes this (hysteresis) to happen (fortunately we don’t have to understand electronics)
- 23. When we react too soon Hysteresis we have built in has too narrow a range it’s back to thrashing
- 24. When we react too late Hysteresis that we have built in has too wide a range too much energy needed to get it back into a known state
- 25. What did I learn? Rapid feedback can be as dangerous as no feedback and Slow feedback consumes a lot of energy so Finding the sweet spot needs experimentation but All feedback is created by people and affects all people
- 26. Waste starts with me and ends with me Personal flow ( fix what I can control ) Feedback in flows Team flow ( finding the sweet spot is worth the effort ) ( big wins need small steps ) Multiple flows ( intersections cause whirlpools )
- 27. Only dead fish go with the flow ( blindly following a process does not create masterpieces ) Aslam Khan :: @aslamkhn :: +Aslam Khan :: factor10.com :: aslamkhan.net factor10