As soon I started to read this book I got so happy to see his takes on agile and Agile™.Sooner, Safer, Happier is a book that was an "instant hit" with me. First, the approach of the contextual setting that there are no silver bullet. Second the pattterns and antipatterns approach led me to recognize so much that certainly this book has a lot to give. Is my favorite agile book – Wow, I never thought I would say that. There is.
One review title on Amazon says Most honest book I have read in last 4 years. I agree. Because it speaks against the so-called Agile Industrial Complex that broke agile, or well, Agile™.
Most lean-agile practitioners will have a go to set of books they call upon. These books will have no doubt been influential not only in their own journey, but also be a regular recommendation they make to others going through a similar learning and/or upskilling experience. Books that come to mind in this category are publications such as The Phoenix Project, Coaching Agile Teams, Lean Startup and Accelerate. What has been lacking (certainly in this readers opinion), is a book that really tackles how you do this at scale across any type of organization, how to do it in a way that is pragmatic not dogmatic. Something that is principle based and is supported by real empirical evidence of the author(s) own journey. Thankfully, we don’t have to look anymore, as this is it. This is the book you’re looking for. Easy to read for both experienced practitioners and newcomers to modern ways of working, Jon, Miles, Zsolt and Simon have succeeded in putting together a collection of solid patterns and anti-patterns for anyone looking to embrace new ways of working. This will not try to convert you into a single framework/method or present Agile/Lean/DevOps as any form of silver bullet - it will respect you and your context, your complex adaptive system of an organization, and guide you on how you can get to the things that matter for any organization, that is #BVSSH - Better Value Sooner Safer Happier.
The quote above is the review from Nicolas Brown and I can’t agree more.
🌟 Why Matters?Section titled %5Bobject%20Undefined%5D
Did you ever hear someone said something like “We use SCRUM™ here, but not this and that”? Well, I had heard so many times I lost the count. But did you know that the SCRUM™ Guide defines that “Scrum’s roles, events, artifacts and rules are immutable and although implementating only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirely”. So, sorry, you don’t do SCRUM. There’s something with the word immutable that in the context of agile that makes me flinch and you? Several other frameworks brings the same.
We are all striving to deliver better products and value, right? And we need fast feedback loops, which the Waterfall Mode where the work only moves to the next area as in a Fordist montage line works against since an simple correction potentially discovered many times during the development and other phases puts a half-assed product in the market. Then agile came in… and today we have this big set of frameworks, certifications, gurus and… this:
Sooner, Safer, Happier takes an approach of look back at the basics and find your way because, well, every context is different. There’s no solution size fits all.
🔖 HighlightsSection titled %5Bobject%20Undefined%5D
“Organizations are complex adaptive systems. There is no one way of working that suits every context. Change is emergent. Changing how you do change is emergent. Organizations are emergent, with a memory. It’s emergence tripled. The only feasible way to progress is by running experiments, being sensitive to context with a fast feedback loop, and a safe-to-learn environment. There is no such thing as “best practice”; there is no one-size-fits-all set of practices that optimizes for all contexts.”
“Do you want to do or are you currently doing an Agile, Lean, or DevOps Transformation? If so, my best advice is: Don’t.”
They had me at “Don’t”.
“It’s not about “Agile,” or “Lean,” or “DevOps” for “Agile’s” or “Lean’s” or “DevOps’s” sake. Figuratively speaking, they are tools in a toolbox. Of course, they are much more than tools; they are behavioral principles, practices, and tools. The point is that you have a collection of bodies of knowledge to deploy optimally in context. A tool transformation, such as an “Agile Transformation,” is not optimizing for outcomes, it’s optimizing for the tool.”
This books is focused on patterns and antipatterns. So have a lot to offer, go read!
I found this illustration so rich to explain to my team the “spectrum of the agile” and why I think is best to be agile than to do Agile™ sometimes meaning paid for some courses, get some certificates and pats on the back of ourselves. The 24th edition of the ThoughtWorks’s Technology Radar put certain enterprise agile framework on the Hold area.
“Instead of treating product development, change, and improvement as a deterministic, knowable activity—trying to command a square peg into an irregular and regularly changing shaped hole—acknowledge that it is not knowable, that the domain of work is emergent, which requires experimentation and fast feedback. To optimize outcomes, intent-based leadership increases the collective problem-solving capability and collective ownership by everyone in the group. […] The best time to plant a tree was twenty years ago. The second best time is now.”
“The primary orientation is around these business value streams. It’s no longer “the business” and “IT.” If you find yourself saying “the business,” instead say “our business.” Everyone in an organization is in “our business.” Having a tribal identity around value and the customer brings together “business” and “IT,” moving away from an order-giver and order-taker relationship to one where we are all the business and will succeed and learn together.”
“Then, over the course of potentially multiple years, work on breaking it up into many small, independently testable and deployable components, with a people architecture to suit, such as a small agile team and small agile components. A “Strangler Pattern” can be applied. The Strangler Patter was first described by Martin Fowler in 2004, named after the Australian strangler fig. […] The components should sit over time in the proper long-lived value streams. Eventually, you can decommission the temporary value stream, with the monolithic “ball of mud” no longer existing. This takes time. There is no quick fix. Therefore, the best time to start is now. ”
“When architecting and organizing for flow it is advisable to design for what Skelton and Pais call “Team Cognitive Load,” or as Dan Terhorst-North says, “software that fits in your head.”
🐙 Go DepeerSection titled %5Bobject%20Undefined%5D
Chapter by chapter summaries!
Book club AMA with Jon Smart, Simon Rohrer and Zsolt Beren