DevOps is NOT Jenkins

All too often I run into companies who think that declaring DevOps as a "thing", renaming a team and buying shiny new tech is enough to improve their time to market. DevOps is a company culture and has to be embedded into the grain of everybody working there. This means putting the right KPIs in place so that a clear motivation starts to evolve to increase synergy between the different disciplines.

My boss told me to do DevOps

These days, more often than not, DevOps is proclaimed at the highest level of enterprises and usually gets a significant amount of attention in the technical echelons of the company. C-level executives have been advised by knowledgeable Consulting firms that DevOps will propel them into a new league. This often means that there is now budget to acquire new tools and technology that will help speed up software delivery. Many times a DevOps team is formed to manage all this shiny new tech and there are usually some signs of improvement. But it doesn't bring the acceleration that was promised, not by a long shot. This is because a new silo has been created in the company and new walls have been erected between teams. Sometimes resentment arises because tasks and responsibility are taken away from people.

Synergy

DevOps is the merger of Developers and Operations engineers and even the two disciplines within a single engineer. This means that we have to find ways to bring these two worlds together. And not only those two, because there's also InfoSec, network operations, the QA team and possibly other disciplines which are involved in bringing a new application or feature to light. Achieving synergy between all these teams and disciplines is what DevOps is all about. In existing organisations, the quickest win is often to make use of existing organisational structures and build the DevOps processes around them. You typically need to have a lot of conversations with everyone involved to really understand the goals and motivations of the different teams and the people in them. You need this firm understanding of people's frustrations and roadblocks in order to improve processes and procedures.

Lead by example

Now that you've been told to do DevOps, take that mandate and carve out a small, manageable unit of work and use that as your breeding ground. Once the changes start to show their merit make sure you have metrics to show the improvements. You can then take that information to your management and talk about how further collaboration, often in only slightly different structures or procedures, can yield even more benefits. As an example, you can embed some security checks in you CI pipeline and present the results to the InfoSec team in an automated report. They will soon realize that the checks they have to do for compliance always yield the same results as the report they already received. Since the CI system will prevent any failing software from getting to the InfoSec team, those tests will never fail again for the InfoSec team. It frees up Security Experts to concentrate on new and upcoming threat vectors. In a second iteration you might ask the InfoSec team to join the design phase of a new feature or bug fix to help make it more secure by design.

Shifting left

This is just one example of a concept in DevOps that is called "Shifting Left". Any issue or problem that is detected earlier in the process is orders of magnitudes cheaper to fix. Not only because of the time that is saved by individuals and teams but also because the tedious and repetitive tasks are offloaded to automation and you have a better chance for talent to stay on board.

DevOps can be a great accelerator for organisations even if you never implement a new tool at all.

Disclaimer: These are my personal views and ideas, not those of any of the companies I might be working with at any given point in time.