Agile methodologies such as Scrum, Extreme Programming and DSDM emerged in the 1990s and most of them were inspired by the Lean Manufacturing movement. While Lean Manufacturing focuses on increasing value and reducing cycle time, work in progress and lead time, Agile methodologies tend to focus on methods. Over the past few decades these methods became dogmatic, businesses struggle to align these methods with their goals and practitioners become disenchanted when they run out of Agile methods to increase delivery speed. During this presentation Zan will present some of his research and show how it is possible to amalgamate Agile methods, Lean Manufacturing and Data Science to get your business back on track. See the full analysis here: https://medium.com/@zankavtaskin/list/research-rejuvenating-agile-operations-by-putting-lead-and-cycle-time-front-and-centre-766cc7993007

1. Rejuvenating Agile Operations By
Putting Lead And Cycle Time Front
And Centre.
By Zan Kavtaskin
Tech Nottingham
v3.7

2. Systems Architect
Focused on analysing how software and people systems integrate, and work
under di
ff
erent conditions. I contribute to open source software and when
possible I dabble in computer and data science.
Director of Architecture, Risk and News @ London Stock Exchange Group
(LSEG). In recent former life, Chief Architect @ MHR.
All opinions are my own and not my current or previous employers.

3. “Agile” Problems
1. Agile practitioners take too long to gain experience. Once they have
experience they can follow methods and understand what needs to be
done. However, they do not understand why the are following these
methods.
2. All this focus on methods makes it hard to know what other improvements
can be made as practitioners run out of the “best practice” book. It is also
not clear if “o
ff
the book” ideas are compatible with the original
methodology.
3. KPIs usually don’t provide much insight into what needs to be done to
improve productivity.
4. Software development does not happen in a vacuum. Most methods do
not discuss or focus on the rest of the business i.e. Marketing, Sales,
Customer support, etc.

4. “Agile” Problems
1. Agile practitioners take too long to gain experience. Once they have
experience they can follow methods and understand what needs to be
done. However, they do not understand why the are following these
methods.
2. All this focus on methods makes it hard to know what other improvements
can be made as practitioners run out of the “best practice” book. It is also
not clear if “o
ff
the book” ideas are compatible with the original
methodology.
3. KPIs usually don’t provide much insight into what needs to be done to
improve productivity.
4. Software development does not happen in a vacuum. Most methods do
not discuss or focus on the rest of the business i.e. Marketing, Sales,
Customer support, etc.

5. “Agile” Problems
1. Agile practitioners take too long to gain experience. Once they have
experience they can follow methods and understand what needs to be
done. However, they do not understand why the are following these
methods.
2. All this focus on methods makes it hard to know what other improvements
can be made as practitioners run out of the “best practice” book. It is also
not clear if “o
ff
the book” ideas are compatible with the original
methodology.
3. KPIs usually don’t provide much insight into what needs to be done to
improve productivity.
4. Software development does not happen in a vacuum. Most methods do
not discuss or focus on the rest of the business i.e. Marketing, Sales,
Customer support, etc.

6. “Agile” Problems
1. Agile practitioners take too long to gain experience. Once they have
experience they can follow methods and understand what needs to be
done. However, they do not understand why the are following these
methods.
2. All this focus on methods makes it hard to know what other improvements
can be made as practitioners run out of the “best practice” book. It is also
not clear if “o
ff
the book” ideas are compatible with the original
methodology.
3. KPIs usually don’t provide much insight into what needs to be done to
improve productivity.
4. Software development does not happen in a vacuum. Most methods do
not discuss or focus on the rest of the business i.e. Marketing, Sales,
Customer support, etc.

7. Inspiration
Accelerate: The Science of Lean Software and Devops

8. Cycle Time and Lead Time

9. Part 1
Seeing cycle time and lead time.

11. C
Y
C
L
E
L
E
A
D
WIP

12. Big Picture WIP, Cycle Time and Lead Time
Cycle Time. Time it takes to deliver a story
from activation to closed.

13. Big Picture WIP, Cycle Time and Lead Time
Cycle Time is typically used internally to
measure productivity.

14. Big Picture WIP, Cycle Time and Lead Time
Lead Time. Amount of time committed work
spent in the system

15. Big Picture WIP, Cycle Time and Lead Time
Lead Time is typically used to measure
customer experience.

16. Big Picture WIP, Cycle Time and Lead Time
WIP. Amount of committed work is the
system (queue + in progress)

17. Value stream?
Value
Solution that solves a problem that customer
is facing.
Stream
A continuous flow

18. What do some value streams look
like?

19. Individual Value Stream

20. Waterfall Value Stream

21. Lean Software Development Value Stream

22. V
A
L
U
E
B
A
R
R
I
E
R
RAW MATERIALS FEATURE

23. V
A
L
U
E
B
A
R
R
I
E
R
EXPENSES REVENUE

24. This value stream is
maximising department
utilisation over global lead
time.
Bene
fi
ts:
• Easy reporting around utilisation i.e. everyone is busy
• Control over own department’s budget, sta
ffi
ng and so on.
• Gives management and employees strong control over their area
of work.

25. This value stream is
minimising work lead time
across the organisation.
Bene
fi
ts:
• Short wait times for decisions and knowledge
• Teams are protected from disruptions
• Team works together to
fi
gure out the quickest way to deliver solutions.

26. What has your organisation
optimised for?
1. Maximising department
u
ti
lisa
ti
on
2. Minimising work
lead
ti
me

27. Part 2
Visualising and reporting on cycle and
lead time.

28. User story cycle time (histogram for a year)
Number of business days to deliver a user story
Amount
of
stories

29. Number of business days to deliver a user story
Amount
of
stories
Quick work.
Might be low
value features.
Slow work.
Might be high
value features.

30. User story lead time (One year, two week sprints)
Business day user story was delivered
Amount
of
user
stories
How
long
user
story
took
to
be
delivered

31. Business day user story was delivered
Amount
of
user
stories
How
long
user
story
took
to
be
delivered
Work is delivered
late in the sprint
Work is drifting
across sprints

32. What if, team has reduced cycle
time by 1 day average

33. Work is delivered
more evenly
across the sprint.
Amount
of
user
stories
How
long
user
story
took
to
be
delivered
Business day user story was delivered

34. More delivered
and more
delivered earlier.
Superimposed before and after
Work is more
evenly
distributed.

36. What if it is just noise and we are
celebrating nothing?

37. Noise Simulation (using random sampling)

38. Did not get
better.
Did not get
worse.
Noise Simulation (using random sampling)

39. Strong signal.
Visualising actual before and after

40. Test lead time using median test.
p-value: 6.47788094142256e-13 p-value < 0.05: True
Testing actual before and after

42. Scientific method

43. This scientific approach gives you
tools to move safely “off the
book” agile methods.

44. Part 3
Lead time observations and how to
reduce it.

46. T1
T3
T7 T10 T11
T9
T6
T5
T2 T8
T4

47. Lead Time is total elapsed time committed work spent
in the system.
T1
T3
T7 T10 T11
T9
T6
T5
T2 T8
T4

48. T1
T3
T7 T10 C4
T9
T6
T5
C1 C3
C2
Σ(T) + Σ(C) > Σ (C)
Handovers

49. Handovers
• Handovers are one of the key factors that increase lead time. Whenever
you can, do reduce handovers through self-service and full stack training.
• Handover latency can be reduced by changing how people and
departments work together. As a starting point this is more important
than focusing on how quickly individuals get stu
ff
done.
See the following fun experiment:
https://medium.com/@zankavtaskin/fun-social-experiment-that-shows-
handovers-are-ine
ffi
cient-in-software-engineering-context-82c0e4b39a15

50. Work in progress
• WIP reduction creates space in the sprint for urgent work e.g. cold or hot
fi
xes. WIP reduction is a way of acknowledging that urgent work is real and
that space should be made for it in each sprint to reduce sprint volatility.
• WIP reduction improves lead time as there is less work in the queue so that
higher priority work does not have to wait for as long.
• WIP reduction makes sense for component teams that provide support.
Global work should be prioritised over local work.

51. Part 4
Cycle time observations and how to
reduce it.

52. Cycle Time
• Wait Time - This is when you are waiting around for some knowledge that you don’t have, decisions
that you can’t make, etc.
• Disruption Time - This is when you have to expedite some work, rework some work, corporate
interruptions and mental health.
• Task Time -This is the actual work that you are doing, purely sitting down and getting things done.

53. Cycle Time - Task Time

54. Number of business days to deliver a user
Amount
of
stories
Cycle Time - Distribution
Number of business days to deliver a user
Amount
of
stories

55. Majority of software development
is craft production.

56. Cycle Time - Distribution
Craft Production Assembly Line Production
Number of business days to deliver a user
Amount
of
stories
Number of business days to deliver a user
Amount
of
stories

57. Cycle Time - Intuition
Craft Production Assembly Line Production

58. One-piece flow
In craft production literal one-piece
fl
ow does not work. It actually damages
quality and slows down cycle time and as a result lead time.
See the following fun experiment:
https://medium.com/@zankavtaskin/fun-social-experiment-that-shows-one-
piece-
fl
ow-is-ine
ffi
cient-in-software-engineering-context-2db89ae1a2e7

59. Theory of constraints
Theory of constraints (ToC) assumes that there is one-piece
fl
ow and work is
standard (average).
Di
ff
erent feature requests will engage di
ff
erent people in the team at di
ff
erent
times. This means the bottleneck is dynamic and it depends on what that
team is working on and who is working on the work.
In craft production work itself is a primary constraint. This is because as a
team you can choose: how you do it and who does it.

60. Little’s Law
Little’s Law assumes that work has an average cycle time. This is true for
standard work. This not true for craft production as it follows negative
exponential distribution.
Meaning “out of the box” Little’s Law can’t be used in software development:

61. You now know how to follow
cycle and lead time
• Visualise your existing value stream, how raw materials travel from start to the end for the
committed work.
• Measure cycle time, this can be done at task level all the way to the department level.
• Measure how long committed work takes to get to the customers hands i.e. lead time.
• Visualise and report your cycle time and lead time metrics. Share this with your team,
stakeholders and business sponsors. Run what-if scenarios and test your results for noise.
• Visualise your target value stream that will move your organisation towards improved lead
time. Work with the business to move towards this new value stream.
• Consider unlearning ToC, one-piece
fl
ow, Little’s Law, reduce handovers and work in
progress.
• Remember that software development is craft production, so do not use average statistics
for lead time or cycle time!