Velocity is the most commonly used metric in agile software delivery. It is also perhaps the least effective metrics in agile software delivery. In "Escape Velocity", Doc Norton walks the reader through common issues with metrics and how to avoid them, altermative metrics that not only help agile teams perform better, but enable them to continuously improve, and techniques for forecasting that vastly outperform the use of velocity. In a quirky, casual, and information dense style, Doc Norton makes the topic of tracking data entertaining and shows us how to be more effective in the pursuit of excellent software.
Based on his experience, Doc Norton starts his book with a long discussion of the flaws of the velocity metric. Then he goes forward and explains the issues with metrics in general and proposes alternative measures (lead time, team joy, etc.) to monitor the evolution of Agile teams. So, obviously will recommend the book to managers and scrum masters of Agile teams to read and come up with set of measurements.
I was so glad to see the Hawthorne Effect and Goodhearts Law talked about. Doc Norton has years of experience and true insight which he shares in this book with practical uses.
This book is chocked full of practical advice from years of experience and practice. Doc presents a solid case for alternatives to Velocity as a means of measuring and tracking software development efforts. The examples are detailed but not overwhelming and I really appreciated the careful walk through of both the math and the reasoning behind each measure. Each measure is examined thoroughly and the pros and cons of each are examined. Docs singular wit and charm comes through in his use of language. It is clear that he speaks from long experience and careful consideration. I strongly recommend this book.
As opinionated as it can be Escape velocity gives some insights on metrics that can be used in "agile" (whatever agile means in a given context) teams.
From the start a distinction is made from velocity and value. On one hand, the way the author depicts the chasing for speed rather than added value is surrounded by his examples that he might have faced in the real life, while on the other hand, he also makes clear that story points are relative to a given context and that the team can also game this metric (as any other).
As the book progress to alternatives to only "velocity" (meaning how many story points were achieved), alternatives are shared with the reader, such as:
- Lead time - Delivery frequency - Cycle time - Cumulative Flow Diagram - Code quality - Team joy - Forecasting
Lead time is also present in the famous book "accelerate" published in 2018, Delivery frequency is close to the "Deployment frequency" as well but there is some details on the understanding of what delivery means for each one of them.
Besides that, Doc dive a bit on what "code quality means" from two angles: code complexity and code coverage. This is a mix feelings terrain with many discussion among practitioners and academics.
Nevertheless, Doc concludes that code complexity is directly related to the amount of lines that a given code has, leading to the metrics that many lines of code is a signal of poor quality. Even though on page 118 he recognizes that this is a failed metrics by itself as he also claim:
"Didn't we learn this was wrong in the 1970's?
I am advocating for it.".
The argument used is a simple generalization of a piece of code that uses many if's and he refactor that to use a strategy pattern, which can be a metrics for this specific case, but can we generalize that?
The other metrics mentioned by Doc are metrics that hopefully might help teams that are stuck on the scrum framework and in love with X story points delivered but no value added.
All in all the book is in my understanding a entry point for anyone that would like to know what metrics can be used in a team beyond story points.
Great ideas, a great first part that clearly explains what velocity is, how it should be used and what are the problems around it.
Then it gets into a part that might feel related to the main topic (in my opinion) but somehow tangential to the topic, speaking about stories, estimation, and metrics that were at least to me less helpful.
I would recommend it as follows: * for managers, agile coaches, and scrum masters new to agile and the idea of velocity up to the other metrics chapter * for experienced agile coaches and scrum masters up to perverse incentives * not sure about everyone else
When I first saw the book, I was interested due to the subtitle: “better metrics for agile teams”. As scrum master I knew the basic metrics, and I was eager to learn more. Along the way, the book explains the issues with the well-known basic metrics. Especially towards predictability, there are better ways than just using your average velocity. For me the book is a must-read for every starting scrum master. In order to be able to measure things that matter for your teams.
Great read. Reads like a mentor giving you a behind the scenes view of how he approaches metrics and what is substantive vs what is fluff. Doc does well to drill down on the application of concepts with detailed examples and calculations. No heavy critique or negative feedback - the book delivers as expected.