If I were suddenly put in charge of a software organisation, the lessons from this book would underpin everything I did. It’s a super simple book on the best way to deliver value from software, which is both simple, and hard.

It’s not just that I learned a lot from this book, it’s that so many people I respect (I’ll call them informal mentors) have clearly been influenced by the same ideas (whether directly from the book or from other sources on agile). I heard one of them recommend it over and over for years before I read it, but he is too oblivious to realise that I’m talking about him (and he never reads my blog anyway).

Part 1: Delivery of value through agile

The first part of the book is a description of agile.

But isn’t agile dead?

I avoid capitalising “agile” because Dave Thomas said Agile (as a noun) is dead). Dave Thomas and Ron Jeffries (the author) were both members of the group that drafted the Agile Manifesto. This book seems like the kind of “agile as an adjective” that Dave Thomas was saying is not dead.

How to deliver the most value, in simple steps

The most important thing for delivering software is value. Software can create value or not. Obviously it’s better if it does, and the way to do that is to:

  • constantly deliver working software (because non-working software cost money for no value)
  • constantly prioritise the things that will deliver most value (because a business needs more revenue, sooner)
  • de-prioritise things that deliver less value (why would you even consider doing something that doesn’t add value?)
  • constantly re-evaluate priorities as you go (because you certainly know more about the problem now than when you were building your initial wishlist)
  • learn from the results and repeat all the above over and over to produce a better product
  • …ensuring quality (well-designed and bug-free) software at every step

Agile learning: for engineers AND managers

These steps add up to agile. It is simple to read, and hard to do. Doing it right will require softare people and all layers of management to learn and grow.

Part of the difficulty for me is how much people push back on these lessons: “Do you really need to spend all that time on infrastructure? Do you need to fix bugs now? We need to show the boss we’re making progress against the plan!”

Jeffries tells us first of all to question which is more important: sticking to the plan, or creating value.

Second, we don’t want to just make progress now, we also want to keep making progress in future, at a predictable rate. We can take on some technical debt, but if we neglect good design and bug fixes, we’ll quickly slow down to a crawl.

From my own experience, a lack of good design and unfixed bugs also leads to problems that someone else created for me.

However (and also from my own experience), there’ve been times when I was pushing for good design, but I haven’t actually been skillful enough to do good design. At least not fast enough. It’s not sufficient for me to deliver the next feature only after I’ve learned good design.

How to deal with this absolutely necessary skill that I don’t have yet? Trust teammates who are (between them) experienced in a variety of disciplines, and be able to learn.

Deliver infrastructure and working features in parallel

It’s easy for me to explain the necessity of learning (and very close to my heart right now), but a harder lesson for me in my career has been that too much infrastructure without generating value is also a problem. You don’t want to build what you don’t need. Instead, you need to build infrastructure and working features in parallel.

There are a lot of other lessons in here, including the practises you need to make this work. Amongst the ones he singles out are TDD and refactoring, but he endorses all of Extreme Programming (XP), citing the original Extreme Programming book by Kent Beck. The XP book is similar to this in that I know it has influenced mentors and has been on my “actually read this (and write a review)” list forever.

I say “essays”, but part two really reads like a collection of blog posts. They are remarkably simple, in the way that someone can only write when they are confident because they’ve seen their ideas work over and over.

The list of topics is like a list of things People At Conferences Want to Know:

  • how to identify value
  • how to help teams thrive
  • how to forecast
  • helpful management (hint: not by “whipping the ponies”)
  • how to go fast
  • how to keep software easy to change
  • how to scale agile (hint: not by making agile more complex)

I already knew that

My first reaction to these essays is that mostly, I already knew these answers. I was just avoiding them, or I lacked nuance in my understanding.

For instance, helping teams moves faster probably requires the team learning new skills, but I’ve always been a bit scared of learning (even though I love it and want to make a career out of it) because it doesn’t help me deal with the pressure I feel from my scary manager.

(and I’ve basically never had a scary manager, I just tend to over-interpret uncertainty as judgement)

The things they didn’t tell me

My second reaction is that I’m really glad that I finally read the book for the bits that the informal mentors didn’t pass on. Here I’m partly thinking of the lessons for upper management (less relevant to me, possibly, since I’ve never been in upper management), but mostly thinking of the essay on scaling agile.

I now know that Ron Jeffries considers the line where “agile doesn’t scale” to be at a point where basically no-one knows what works: hundreds or thousands of developers, working on projects that are not divisible into small teams. I will be taking the word of the guy who helped write the Agile Manifesto (Jeffries) over the word of the consultants who want to charge lots of money to tell me about SAFe.

Conclusion

This book is a quick read and distills so many important lessons into an easily understandable package. If I were a head of software development, this would be my cheat sheet.