Lean in Software Development

Lean Software Development An SD Times Webinar with Kent Beck and Henrik KnibergAslam Khan :: @aslamkhn :: +Aslam Khan :: factor10.com :: aslamkhan.net factor10

Personal Flow finding waste in my day to day workdesign next generation architecture write some mini frameworksdevelop 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

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 workWhich waste do I have CONTROL over? partially done work task switching motion

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)

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 beforequeue each task when needed each category taking another task

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) customerrequirements 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 ...

Big wins … big wins are above the line customerrequirements 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 )

At another team with whom I work estimate and complete unit development review commit tests 1 day 3 weeks 1 day 2 daysworkwait highly optimised wait time

Look above the line too but what’s this? estimate and complete unit development review commit tests 1 day 3 weeks 1 day 2 daysworkwait 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)

What is the real problem? estimate and complete unit development review commit tests 1 day 3 weeks 1 day 2 daysworkwait 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

Lessons I learned DON’ T believe that automationDO 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

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 iterationrequirements 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 )

Multiple Flows waste as a result of different many processesSame 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 ?

Intersecting Flows waste as a result of different ‘mini’ processesLet’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

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 dpr o … when they meet, little whirlpools form ( lots of little whirlpools, frequently enough, can be quite disruptive )

Constructive Flowoccurs when different flows are buffered or embeddedcreate 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 )

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 )

Feeding back into a flow knowing when to act on valuable feedback defects are tossed right back intodevelopment for immediate attention Software installed in production and in use toss defects back in go live developmentwork wait

Thrashing towards stability when we react to all feedback immediately thrashing for stability ( linear reaction to change )

Buffering manual flows avoiding disruptive intersections of flowsdefects 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 )

Gently gaining stabilitywhen we choose which feedback to react to and when to react gently gaining stability buffered feedback ( non-linear reaction to change )

A Lesson in Electronics 101 the system is somewhere between two states but it’s in neither stateV-in +15V V-kettle + U1 - R1 -15V R2 this feedback loop ... …. causes this (hysteresis) to happen (fortunately we don’t have to understand electronics)

When we react too soon Hysteresis we have built in has too narrow a range it’s back to thrashing

When we react too late Hysteresis that we have built in has too wide a rangetoo much energy needed to get it back into a known state

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

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 )

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

Lean in Software Development

by Aslam Khan

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 7

Statistics