After learning about the Cynefin Framework at the DDDEurope conference earlier this year, it's been interesting to utilize the framework to try and make sense of observations at work.
I've long been very interested in the DevOps movement (like most developers I guess), but I've been frustrated with:
- Having a hard time getting "the business" on board with investing into the non-technical aspects of DevOps.
- Lacking a good "recipe" on how to turn an organization into a DevOps organisation.
While there are some ubiquitous techniques you should apply in a DevOps journey, like source control, continous integration, trunk-based development, frequent/continous deployment, actually getting my organization invested has been much more difficult for me. While I can describe the benefits by using the State of DevOps report, it's difficult to sell this to managers. (And in my experience, that especially makes continous deployment more difficult, as the organization is still scared to deploy without code freeze and verification time, which they don't invest the time into doing frequently enough).
Recently, I finished reading the Accelerate book. The book was great, but while reading it, I still felt frustrated with the lack of a "recipe" on how to get DevOps to work in an organization. While the book describes a good state you should aim for, it doesn't tell you how to get there. That is, until I got to Part III: Transformation. YES! Finally. Interestingly, that chapter emphasises an important point. The transformation journey will be different for every organization. You can't just copy the Spotify model and use it on your organization, because your organization isn't Spotify. You will have to experiment and find out what works for your organization (and what doesn't work).
Solving complex problems is not done following a straight line from A to B. Photo by Raphaël Biscaldi / Unsplash.
I guess in a way I already knew this, I just didn't want to admit it. Because that's hard. But thinking about this and the Cynefin framework gave me an epiphany: Changing an organization is a complex problem, while I was trying to solve it as a complicated one. I was trying to get an "expert" analysis on which steps I needed to take to turn my organization into a DevOps organization. But the truth is that since every organization is a complex adaptive system, changing a culture is complex. And to solve complex problems, you need to do (parallel) safe-to-fail experiments.
I'm sure other people have realised this before, but to me personally, it was comforting to realise that there simply isn't a recipe on how to "fix" your organization. You will have to be ready to experiment, be ready to fail and learn from those failures in your transformation journey. And I guess that's the first step to one of the most important parts of the DevOps transformation - fostering a learning culture in your organization.
P.S - The writers behind Accelerate have also published articles on How To Transform and Transformational Leadership which are good reads if you have the same frustration I had.