Last Modified: Thu 24 Dec, 2020 10:19 AM
So I had a hard copy of this as well as an e-copy because a few years ago when I was working at ExtraHop Networks the book was published and everybody loved it and the company even had Gene Kim come and talk at one of our yearly kickoff conferences. I didn't read the book then - but I had it!
Fast forward a few years and I'm working in an organization that struggles (present tense, I still work in it...) with agile product development, iterative product cycles, and dev ops. The management of the group has their collective heads stuck in the sand about it, either not being able to admit that they're doing it wrong, or altogether dismissing it as an improvement over what they have done since the '90s. I was asked whether I had any books I could recommend about this - and I had to admit that I hadn't actually read any - so I read this one!
This is not a guide to devops and agile software development. What it is though, is a fictional story that portrays a company that needs to modernize and has all of the archetypal problems that devops and agile claim to combat and solve. They go through a series of realizations and refinements and ultimately wind up succeeding at devops. It's a fun story!
I've been in the technology industry long enough that I've seen everything in this book a few times and it was hard not to draw my own similarities with people from my own past which is always fun as well as my own experiences and mistakes.
Also, my first name is "Brent" - and that's also the first name of the single most capable engineer in this book. Coincidence? Absolutely (and a stereotype I'll never live up to unfortunately)!
That all said, there's a million ways to implement agile and devops and none of them are perfect or best so it's hard to read something like this and turn around and try to replicate it. There is no recipe and every time you implement this sort of thing the results will be different and the implementation will be a bit different. This book could have done a better job of stating that (or if it did, I missed it); devops and agile aren't rigid and different teams with different projects and under different circumstances will do it differently. If anybody ever tells you they have a tried and true methodology that would work for every situation, you can be confident that they have a lot to learn still.
This is probably a 3 / 5 sort of book. Super quick read, fun story if you're in tech, but I can't say I learned very much - but maybe I just read it 20 years too late.
Last Modified: Thu 24 Dec, 2020 10:19 AM