đ en ~ 8 min read ~ â
Share this post
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.
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.
â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.â
Chapter by chapter summaries!
Book club AMA with Jon Smart, Simon Rohrer and Zsolt Beren