lean in software development
DESCRIPTION
Looks at the concept of flow as applied to individuals, teams in the large and in the small.TRANSCRIPT
Lean Software DevelopmentAn SD Times Webinar with Kent Beck and Henrik Kniberg
Aslam Khan :: @aslamkhn :: +Aslam Khan :: factor10.com :: aslamkhan.net factor10
Personal Flow finding waste in my day to day work
Lots of ALMOST COMPLETE work
TOO MUCH WORK!!
TOO MUCH WORK!!
why?
why?
MOVING between different locations too frequently
which is why there is ...
SWITCHING to different task far too frequently
design next generation architecturewrite some mini frameworks
develop legacy replacement strategyteach, mentor, code review
...
no!
Cleaning up wastewhat do you actually have control over?
partially done work
task switching
motion
Which waste do I have CONTROL over?
What is my chain of waste?ALMOST COMPLETE workSWITCHING frequentlyMOVING too frequently
partially done worktask switchingmotion
What did I learn?
DO look for the chain of waste or the root causes
DON’T try to eliminate waste which is out of your control
DON’T try to be too precise in your estimations
but
DO work with good gut-based gross estimations
but
(over optimization)
(over analysis)
motion
buffer the tasksby limiting to 2 in
each category
What did I do?buffer and limit work in progress
prioritize and queue each task
only moved around when needed
partially done worktask switching
tasks started were completed before
taking another task
Team Flowfinding waste in the overall development process
requirements planning development code freeze
work
wait
2 weeks
4 weeks 4 weeks 8 weeks 3 weeks
4 weeks
customer changes approval
2 weeks
Kent Beck’s value stream map(from “Lean Software Development, An Agile Toolkit” by Mary and Tom Poppendieck)
there may be some ‘quick’ wins below the line but ...
Big wins
requirements planning development code freeze
work
wait
2 weeks
4 weeks 4 weeks 8 weeks 3 weeks
4 weeks
customer changes approval
2 weeks
… big wins are above the line
( big wins achieved with small changes may be are more lasting )
At another team with whom I work
highly optimised wait time
estimate and commit development review
work
wait
1 day 3 weeks 1 day
complete unit tests
2 days
Look above the line too
but what’s this?
estimate and commit development review
work
wait
1 day 3 weeks 1 day
complete unit tests
2 days
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?
went for continuous integration as a quick win
estimate and commit development review
work
wait
1 day 3 weeks 1 day
complete unit tests
2 days
pressure to have high coverage from unit tests
which resulted in
but
no one had done TDD before
Lessons I learned
DO look for ways to automateDON’T believe that automation
comes for free
use high fidelity options at the last responsible moment
but
DO look at the impact of automation
and
(automation is a highly mature state of development)
( what are the upstream and downstream demands? )
( what is the simplest first attempt at this automation? )
use low fidelity options at the first responsible moment
and
Multiple Flowswaste as a result of different many processes
The flow for one of the product managers
the intention is to share new knowledge frequently
( this is quite common in Scrum with backlog grooming )
prepare requirements
share with team
releaseplanning
work
wait
next iterationplanning
share with team
share with team
1 day1 day 1 day 1 day 1 day1 week 1 week1 week
prepare requirements
prepare requirements
Multiple Flowswaste as a result of different many processes
Same flow from the development team perspective
prepare requirements
share with team
releaseplanning
work
wait
next iterationplanning
share with team
share with team
1 day 1 day 1 day 1 day 1 day
1 week 1 week 1 week
lots of wait time ?
Intersecting Flowswaste as a result of different ‘mini’ processes
Let’s superimpose this flow with the team flow
the product manager flow disrupts the team flow
estimate and commit development review
work
wait
1 day 3 weeks
1 day
complete unit tests
share with team
share with team
share with team
1 day 1 day
1 day 2 days
Disruptive Flowoccurs when different flows intersect
development
product planning
product plan
ning
… when they meet, little whirlpools form
it reminds me of different currents flowing in river …
( lots of little whirlpools, frequently enough, can be quite disruptive )
Constructive Flowoccurs when different flows are buffered or embedded
create buffers between flows
buffer
create embedded flows
( because it’s automated, the touch point is a tiny, lightweight buffer )
works well for manual or semi-automated processes
works well for highly automated processes
What did I learn?
Buffer flows if it’s manual
Small intersections, frequently enough, can cause nasty whirlpools in your flow
so
Automate a flow and embed it
or
( but remember the automation challenge from earlier )
Feeding back into a flowknowing when to act on valuable feedback
development
work
wait
go live
Software installed in production and in use
toss defects back in
defects are tossed right back into development for immediate attention
Thrashing towards stabilitywhen we react to all feedback immediately
thrashing for stability
( linear reaction to change )
Buffering manual flowsavoiding disruptive intersections of flows
queue
development
work
wait
go live
Software installed in production and in use
workaround workaround workaround
bug bug bug bug
planning
feed into next planning
2
13
defects get ‘work arounds’ and bugs are queued
( 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 101the system is somewhere between two states but it’s in neither state
-
+
+15V
-15V
V-kettleV-in
R1
R2
U1
this feedback loop ... …. causes this (hysteresis) to happen
(fortunately we don’t have to understand electronics)
When we react too soonHysteresis we have built in has too narrow a range
it’s back to thrashing
When we react too lateHysteresis that we have built in has too wide a range
too much energy needed to get it back into a known state
What did I learn?
Finding the sweet spot needs experimentation
Rapid feedback can be as dangerous as no feedback
Slow feedback consumes a lot of energy
and
but
All feedback is created by people and affects all people
so
Waste starts with me and ends with me
Personal flow
Team flow
Multiple flows
Feedback in flows
( fix what I can control )
( big wins need small steps )
( intersections cause whirlpools )
( finding the sweet spot is worth the effort )
Only dead fish go with the flow
Aslam Khan :: @aslamkhn :: +Aslam Khan :: factor10.com :: aslamkhan.net factor10
( blindly following a process does not create masterpieces )