Not only do high-velocity organizations get better at what they do, they get better at getting better at what they do. This scales so that no one can keep up with them. After all, most companies hire from the same pool of talent, they use the same software practices such as Agile/Scrum, they use the same tools, and so on.
Beyond Lean, another important contributor to DevOps is the safety science movement. In this blog, Ron discusses this subject and show how important this is and how it changes the ways we think of the systems we build.
We need to regularly update our Mental Models but more importantly we need to find better means to update our Mental Models if we are serious about enabling a better culture which enables more innovation and happier individuals in our organization.
What is DevOps? This is a question that I find challenging to answer and the more I study the subject the more difficult it is to define the term. One way to think of DevOps is by applying the notion of Complex Adaptive Systems.
The very notion of economies of scale arose during the early industrial age but unfortunately is still prevalent in many industries, including software development. However, that has changed with DevOps but it still isn’t obvious otherwise I would not come across customers that still work in this paradigm.
Unfortunately, many enterprises have multiple organizations and projects in their portfolio and merging them into a single project can seem a daunting task. While there are tools out there that can help, there is no “Single Tool To Rule Them All”.
if you want to change something, never immediately assume that current conditions are immutable. If you’ve never discussed the possibility to change, you cannot know whether others – your partners, customers, teammates, or managers – would resist, or the reverse – enthusiastically gush and support the change.
How do you deal with the fact that the developers in your organization cannot or will not own the process of delivering into production? How do you deal with the fact that your operations engineers cannot or do not fully understand the software to which they have been given stewardship?
At this point we were five plus years into a local transformation that was underappreciated and overlooked by the global IT organization. The frustration was high and the hope was waning. For me this became my motivation to start a journey to understand why some organization can adopt DevOps strategies successfully and other struggle.
By removing or reducing tribal knowledge from projects and teams, organizations set themselves up for success in an ever-changing landscape (exponentially changing). In other words, you can add to your DevOps culture (or create one) simply by subtracting the bad habits and behaviors.