Disclaimer: this book review is still in-progress and thus the analysis may seem to end abrubptly.

While I've been "doing agile" for a long time now it is always good to refresh yourself on the roots of your processes. This book is well written and still very useful in terms of guidance and best practices. I'm sure if I read this every year I'd pull out different quotes and learnings but the fact that any software development book is still relevant a decade in is very indicative of its value and the transformative nature of these concepts.

Output vs Impact

There is a never-ending struggle of software development teams being asked to "go faster" and "do more" but I found the section about "good teams vs bad teams" (my renaming of the section) to be an intriguing angle on this struggle.

One of the common misconceptions in software development is that we're trying to get more output faster. Because it would make sense that if there was too much to do, doing it faster would help, right? But if you get the game right, you will realize that your job is not to build more--it's to build less.

At the end of the day, your job is to minimize output, and maximize outcome and impact.

We can always ship more code and we can do things to ship more code faster. Increasingly I see posts about AI-driven development being a game-changer in this way. AI can certainly help us ship more code faster, of that I have no doubt. However these quotes are spot-on in that we shouldn't be focused on the quantity of output. Whether we measure in lines of code, issues, closed, deployments made, or any other GitLab-driven metric we're stuck without the whole picture. The quality of the product that comes out of those metrics is what truly matters. And that is a very difficult metric to track and correlate.