Rejuvenating Agile Operations By Putting Lead And Cycle Time Front And Centre.
- 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.
- 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?
- 21. Lean Software Development Value Stream
- 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
- 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!