Why Teams call analytics are critical to your entire business
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