Select language, opens an overlay

Comment

Accelerate

the Science Behind DevOps : Building and Scaling High Performing Technology Organizations
Mar 06, 2020dixithanoop rated this title 3 out of 5 stars
I'm typically allergic to verbose, pedantic, preachy books that lack real-life examples and use-cases, specifically those related to management, but nevertheless picked this up after hearing a lot of positive things about this from more than a few of my esteemed, book-savvy colleagues. It's hard to review the book as a whole, mostly because it's divided into three sections that are drastically different from each other with their interesting-quotients. That said, what's phenomenal about this book is that it's thoroughly and wholly data-driven, and that's rare for the kind of books that attempt to prescribe certain management practices. Additionally, the entire book is dedicated to practices that improve DevOps, which I believe has come a bit late, given how central DevOps as a responsibility is for any firm. The first section - What We Found - was very absorbing because it was all about results. The authors highlight the results of their work in a very organized, methodical, and story-like manner which makes you want to note down a lot of points and maybe even add your own scribbles to their conclusions. In this section, I got to explore a lot of new systems and traverse some interesting concepts, including Wardley Maps, Likert Scale (remember those Agree/Strongly Agree/Disagree questions?), intricacies of Lean manufacturing, Melvin Conway's thoughts about how a team's technical architecture more or less resembles the communication structure of the organization itself, Shift Left policies on info-sec (meaning, involve info-sec from the very beginning, and as just a reviewer or approver), IBM's Think Friday like Google's 20% rule etc. One place where I saw that needed some attention was their rejection of measuring work using the number of lines of code written. While obviously it's wrong to use that as a measure, i think the reason it was in practice was because during the era of Assembly Level Programming, the number of lines of code did mean something, some measure of work, as there was only so much one could do with smart-coding! I also like to add a few more of my own inferences about how Missions of a company have different levels to them - visionary, inspirational and executional; about how we should all design our systems and stack as a "Blameless Architecture", meaning you can't blame any one person or in ideal case even a group of people, for any failure. The second section was of less interest to me as it was all about how the authors did the survey, or how they got the primary data on which they based their conclusions! Except fot the section that described the six different types of data analysis there are (mechanistic, being the most complex and my personal favorite among them), the section was of little importance for a manager, and probably more intriguing for a psephologist! That said, some concepts like "Yak days" at work - the days you dedicate to distribute knowledge or/and reduce tech-debt, Kata, Obeya kind of processes just like Kanban and Scrum, etc were particularly underlining worthy. The third section was a real-life use-case of the transformation story at ING-Netherlands bank, and like always, practical examples are my favorite in a book, and thus, so was this. Overall, I think the book is a decent read, and even though opinionated, because they're backed by solid data and research, I wouldn't probably mind it.