Anyone need a book recommendation? 🙋🏻♀️ Today I’m going to talk about Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren PhD, Jez Humble, Gene Kim.
Who should read this book?
“Accelerate” is a book full of practical, peer-reviewed advice on how to be more successful at building software. Therefore I’d really recommend it to the following types of people:
- 👩🏽💼 Decision makers who want to have scientifically backed data to make their decisions to change and improve their organisations.
- 👩🏻💻 People who code and want to understand how to change and improve their code processes to deliver measurably better software.
- 👩🏾🔬 People interested in research techniques and data science especially applied to building better technology organisations.
Why should you read this book?
If you’re usually one to skip the foreword (or in this case, forewords) and make your way to reading the main portion of a book, in this case I’d say - don’t! Reading Martin Fowler’s foreword really put me in the right mindset to understand exactly why this book is valuable. Also, it’s just plain hilarious 😂.
Whilst I know that you’re definitely going to read the foreword for yourself now I’ll just summarise: Fowler explains his journey from first reading some of the “2014 State of DevOps Report” (which is also written by the authors) and wanting to “toss it with great force into the rubbish bin” 🚮 to being convinced that there was real analysis behind it, even more than some academic papers.
I agree: If this book were just based on opinion or purely anecdotal, it wouldn’t be that impressive or at least widely applicable. The fact that it is peer reviewed research gives substance to previous discussions on what should be best practice in the lean and devops space.
When should you read this book?
Personally I found that when sitting down with this book, it was important to be very focused. In “Part I: What We Found” especially, the book is densely packed with information. It truly felt like each paragraph (if not each sentence) contained nuggets of interesting information to absorb and reflect on.
I bought this book on Kindle and found that it was very helpful to highlight the sections which stood out to me, or which were surprising. This both helped me to focus, and to be able to turn back to what I found to be the most interesting points to reflect on further. If you buy this in paper form, I hope you’re not too afraid to ruin a book with highlighter ✍🏻!
What did I learn?
As I mentioned previously, the book is packed with interesting insights. I’ve picked out two which struck me most at this time, being most applicable to me right now as a software engineer. This means I’ve not focused as much the equally insightful culture and leadership content.
🚢 Ship ship ship
Whilst it wasn’t news to me that continuous delivery improved delivery performance, what Chapter 5 “Architecture” highlighted to me was exactly how much it affected performance, especially in large organisations. It really made me more conscious to try and deploy my code at least daily, and to ask myself what I can improve to enable myself to deploy daily when I was prevented from doing so.
👿 Bureaucracy is not (necessarily) evil
I love it when a book challenges my worldview, and Chapter 3 on “Measuring and Changing Culture” certainly did that. The chapter discusses applying the paper “A typology of organisational cultures” by Professor R Westrum to technology organisations. Whilst the main takeaway of the chapter discusses the efficacy of generative cultures and the importance of information flow, I was struck by a few paragraphs which were more of an aside.
We should emphasize that bureaucracy is not necessarily bad. As Mark Shwartz points out in The Art of Business Value, the goal of bureaucracy is to “ensure fairness by applying rules to administrative behaviour […]”
My experience tends to be that many people in this industry are allergic to “rules”, but the point made that some rules “remove arbitrariness” and helps prevent “discriminatory treatment” will ring true. From personal experience, for example, having performance frameworks tend to be fairer because all parties know what goals need to be met to get to the “next level”, rather than it being arbitrary.
Summary
I really enjoyed reading Accelerate. So if you build software, or work with people who do, I encourage you to take a quiet couple of afternoons to read through it (ideally with a trusty highlighter). If you do I’d love to hear about your key takeaways!
Top comments (0)