Sooner, Safer, Happier: Micro Review
This might be a little more than a “micro” review :) I first came across Jonathan Smart’s work in last year’s DevOps Enterprise Conference where he gave the lightening talk on CRAP (Certified Really Agile Practitioner), where he makes fun of many agile practices in the enterprise. Like many others I found that performance extremely funny yet it hit too close to home too.
So I was excited to get the opportunity to get my hands on his new book “Sooner, Safer Happier” early this week at the virtual DOES Conference and I jumped right into it. The book did compel me into 3 late night reading sessions so that says something. Read on for what I think.
Fair warning. The book is written for the uninitiated. So Jon does spend some time explaining and revisiting some basic concepts which you can quickly peruse. Also, if you have read The Unicorn Project and some of the books recommended in it, some references and content can seem repetitive and probably would make for a quick read. Or if you are like me and geek over this kind of stuff, its just more interesting reading !!!!
However, once you get past that, the real meat of the book are the anti patterns and corresponding patterns that Jon walks through based on his experience driving digital transformations in large enterprises. Also, his premise and definition of DevOps is one of my favorite that I have come across — Better Value Sooner Safer Happier.
The book lists 26 anti-patterns and corresponding patterns that are spread over 8 chapters which cover topics like “focus on outcome”, “leadership”, “flow”, “technical excellence” and more. The book’s final chapter focuses on how to bring it all together and where to start. I also liked that every chapter has a summary and principles at the end.
I have had the privilege in my short career to be part of at least 3 large digital transformations and as I read through his anti patterns and patterns, so many things just clicked. Things I have done in the past, things I am doing, things I see people around me doing and the environment I find myself in !!! There were so many parallels (both anti patterns and patterns). And Jon has done a great job of bringing together the different concepts into practical stories, advice and guidance for your digital transformation journey. Like I said, there are overlaps with other material out there but if you are in a mid size or large enterprises, this book neatly packages it for you.
Here are some of my favs from this book:
My favorite (or most frustrating) anti pattern — local optimization.
My favorite pattern — Continuous Technical Excellence.
My new favorite term — “Cargo Cult Behavior”
That was hard to choose. Really. I have a feeling, I will be constantly going back to this book.
Another must read if you have a role to play in digital transformation in any enterprise.
Here are some sample of my favorite excerpts (without giving away too much):
For most large service-based organizations, in my experience, flow efficiency is typically 10% or lower. This means that work is waiting at least 90% of the time.
Focusing on “Agile,” “Lean,” or “DevOps” as the end rather than the means to an end is using old ways of thinking to apply new ways of working.
Capital “T” Transformation in this antipattern represents an imposed change. It represents a program of work with a start date and an end date when the firm will have magically and permanently transformed, like a caterpillar turning into a butterfly.
An organization is a network of interdependent services. Therefore, the descaling efforts should include working to break dependencies, not only to manage them. This leads to fewer bottlenecks, less effort required for coordination, higher autonomy, and increased agility
If members of a leadership team are not prepared to adopt the principles and practices that they expect their followers to adopt, success will be limited.
Many enterprises fail to recognize individual (non-manager) contributors at senior levels, at least ones with hands-on software engineering roles. In traditional organizations outside of the IT industry, software developers often have to stop coding and take up either line management or PowerPoint to progress in seniority.
There should be a focus on architecting for flow and autonomy (as well as the “-ilities”) — not only for individual applications but also for the interplay of the enterprise application ecosystem, which is often counterintuitive for traditional EA functions.