Which DevOps patterns to implement in your team / company?

Many software development teams and software-producing companies are looking into adopting DevOps patterns and techniques in their way of working. (checkout also my previous blog post on what does DevOps actually mean)

The question arises – how a given software development team or even a software-producing company can make the most out of DevOps, which DevOps pattern to implement first and what is the optimal DevOps-setting for their specific scenario?

As with many topics in the software industry – there is no one-size-fits-all algorithm here. The challenges that teams face can vary greatly depending on:

• business domain
• regulatory requirements
• dependence on external stakeholders
• technologies being used and tech stacks
• team size / company size
• seniority of the team members
• funding
• etc.
  

To give an extreme example, a team in a large enterprise, developing core functionality in a healthcare software dealing with patients health data, faces different challenges than a startup team working on a mobile game app.

With so much variety in the software industry, how to know which DevOps patterns to adopt and which could be an overkill or even inapplicable for a given scenario?

What you can do, no matter what your business domain is, is to analyse the status quo of your DevOps process – the way things are currently working. DevOps is a broad field. Without first understanding where your main problem-points are, it could be challenging to plan concrete changes and be confident that they will positively affect your bottom line.

My approach for improving the DevOps-posture of a given software development team can be described in four simple high level steps:

1. 1. Gather data – extract and document data for the current development process.
   2. Analyse the gathered data – localise areas you would like to improve, create hypotheses how to improve, plan some concrete adjustments in your process.
   3. Implement – implement the adjustments you have planned in the previous step.
   4. Go to step 1

Yes, it is a feedback cycle. Your adjustments and also the constantly changing environment will influence your development process. Instead of evaluating and adjusting once, if you are looking for an optimum, you most likely will need to evaluate again and make new adjustments when needed.

The work-heaviest step is actually step 1 – gather the data. This is a topic on its own. (If you want to know more about the metrics that I use, you can check out my DevOps Process Self-Assessment Checklist. It should be added that metrics are an important aspect, however they are not enough, could be also misleading!, and one should be quite careful with the interpretation.)

Conclusion

DevOps is a very wide area including many different techniques, patterns and ideas. Hence it is difficult, if not impossible, to give concrete advices that apply for all possible scenarios. What development teams and companies can do though is to analyse their current development process, plan adjustments and evaluate the results, on a repetitive basis.

References:

5 tangible metrics for the speed of software engineering teams

Metrics for the efficiency of a software development process

Photo by Alexander Schimmeck on Unsplash