
A New Copy!
Before we wrap up our re-read of Daniel S. Vacanti’s Actionable Agile Metrics for Predictability: An Introduction (buy a copy today) remember that we will begin our re-read of Turn the Ship Around by L. David Marquet next week and I am stoked Buy your copy and listen to the interview I did with Mr. Marquet (SPaMCAST 202). If you want to get ahead, the book after that will be The Checklist Manifesto by Atul Gawande (I recently bought a copy and want to share what I have gotten out of it). Now on to the main attraction!
This week we conclude our re-read of Daniel S. Vacanti’s Actionable Agile Metrics for Predictability: An Introduction (buy a copy today). Over the past 18 weeks, we have explored the power of a few metrics to help teams deliver value. None of the books we have explored in the re-read series are simple, one-idea books. The complexity of these books are the reason they are important, but it makes it difficult to boil them down into a few words. If pressed for a one-line summary, I would say that it is that every team or organization should use data to pursue continuous improvement.There are four concepts that I would like to revisit as we conclude. They are:
- Measuring flow is means understanding process. Predictability and metrics require teams and organizations to spend the time and EFFORT needed to understand the processes used to deliver work. While at a very granular level, the work needs to deliver a new or changed feature is different from the one you have done before, if we take even one step back we can observe and measure a smaller set of common steps. The value of understanding your process is that understanding allows measurement, experimentation, and change so you or your team can deliver more value.
- Cycle time is a tool for developing and using predictability. There are many metrics and measures used in software organizations. Many of these are useful, yet very few of them are as obvious and unobtrusive as the length of time needed to complete a piece of work. Every human in the workplace understands the calendar and the clock. Measuring how long work takes forces organizations to understand how work enters and then exit the process. This provides the team with the data so they can answer questions about how long work will take and when specific pieces of work might be complete without blind guessing.
- Avoid averages. Very few processes deliver values that are normally distributed (you remember the bell curve). Much of the standard statistics often used describe metrics make the assumption of normality. Statistics I have seen in metrics presentations typically include averages, means, standard deviations and less often, concepts like control limits. Unless you can plot the data and prove the distribution of the data falls into a normal distribution, avoid using those statistics. In the book, Vacanti, uses the simple concept of percentage lines on scatter plots (for example, if you drew an 85% line, 85% of the observations would fall on this line or below). The approach allows the person reading the chart to develop service level agreements and forecasts.
- Use data to improve how you work. Continuous process improvement is either an explicit or implicit goal in every organization. Unless we generate more value or revenue some other organization (you can substitute person or team) will find a way to eat your lunch. In week 18, I used the punchline “define your process, get some data, and then do something with it” to draw attention to the need to pursue continuous improvement.
Constraining the wrap-up to four items means that I left a ton of items on the floor: cumulative flow diagrams, Little’s Law, histograms, flow debt and Monte Carlo analysis are just of few of the important items discussed in Actionable Agile Metrics for Predictability: An Introduction. You need to read the book and our re-read because a simple wrap-up can only scratch the surface of the value in the 300 pages of this book. Start using the ideas in the book. Using the ideas in this book will change how you work. Period!
PS – As usual, I agree with Steven Adams who commented last week. You should read Chapter 17, the case study even though we did not include it in the re-read. Also, SPaMCAST 486 (March 18, 2018) will feature an interview with Daniel Vacanti.
All Installments
Introduction and Game Plan
Week 2: Flow, Flow Metrics, and Predictability
Week 3: The Basics of Flow Metrics
Week 4: An Introduction to Little’s Law
Week 6: Workflow Metrics and CFDs
Week 8: Conservation of Flow, Part I
Week 9: Conservation of Flow, Part II
Week 11: Introduction to Cycle Time Scatterplots
Week 12: Cycle Time Histograms
Week 13: Interpreting Cycle Time Scatterplots
Week 14: Service Level Agreements
Week 16: Introduction to Forecasting
Week 17: Monte Carlo Method Introduction
March 11, 2018 at 1:28 am
The big take-away for me is understanding the 5 assumptions behind Little’s Law (cycle time = work-in-progress / throughput).
When I first heard of Little’s Law, but not the 5 assumptions behind it, I wondered why it did not seem to apply to the software projects I was involved with. By reading this book, I have have a good understanding of when Little’s Law can work in the real-world.
The other big take-away for me is to collect the flow metrics and use Monte-Carlo simulations for predictions. Do not use Little’s Law for predictions, except for a rough estimate of a short-horizon, calendar goal.
March 11, 2018 at 1:57 am
Excellent points!
March 11, 2018 at 4:11 am
Thanks Tom for this re-read and the whole re-read series!
March 11, 2018 at 9:08 pm
[…] Week 19: Conclusion […]
March 20, 2018 at 8:55 pm
[…] Week 19: Conclusion […]