Which DevOps patterns to implement in your team / company?

By Published On: April 18th, 2023Categories: DevOps, software engineering

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. 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

Author: Luben Alexandrov

Luben is the main consultant for software engineering and software architecture questions at Version Lambda. Always looking for ways to improve the efficiency of the software teams.

Share this story

You might be interested

  • Agile is not an excuse for lack of longer term planning

    Sometimes I work with teams where I see that there is no clear mid-term to longer term planning [...]

  • What is actually DevOps?

    DevOps is a broadly used IT term, but what does it actually mean? From my conversations with [...]

  • Metrics for the efficiency of a software development process

    Fundamental metrics in software development In this article we assume that a software development process is good, if [...]