DevOps is a term that you currently hear a lot. I will explain to you how you can implement DevOps. Spoiler alert, do not do it! Do not implement DevOps, but use parts from DevOps that you can use in your environment.

Oh by the way, if you are reading this and think ‘What the hell is DevOps?’. Then read my article What is DevOps?

Resistance to change

Not everyone will be excited at first when you drop the bomb. When you say, ‘Hey let’s work DevOps from now on’ you most likely will face a lot of resistance from within the organization.

Resistance from the management team

The most difficult part of implementing DevOps is convincing your manager that your team must become a DevOps team. The fact that it is a radical change with unknown profit is a rather big risk for them. They will have to adjust the current company structure and maybe even the culture. This costs money and it will be difficult to convince the management of the benefit of a DevOps team.

Resistance from operations

Those who are currently responsible for operational activities in your organization may not like the plan. They will fear that their jobs will eventually disappear. The reason is, they are afraid that their tasks will be taken over by the development team.

Resistance from your own team

Resistance can even come from your own team. There may be people in your team who are afraid of change. These people will therefore not like to work in a completely different way. They get extra tasks and responsibilities that increase the chances that if something goes wrong they will be the ones to blame.

Do not talk about DevOps

To avoid the resistance you should not talk about DevOps. Prefer to talk about the parts within DevOps. Use the principles that are most effective for your situation. Then search for more parts that you could use. This way you do not even have to say the word DevOps. It does not matter how you call it, as long as it is an improvement for the current process. DevOps should not be a goal, but a means to reach the goal and in most cases that goal will be to improve the process.

Talk to the other team

Visit the operations team and try to find out what kind of problems they are encountering. Also try to understand why they do certain things the way they do them. When you understand how operations work, you can take that into account during your own work. This will increase mutual understanding and will improve cooperation a lot. People like it when you show interest in their work.

An important aspect of a DevOps engineer is that he is technically strong, but also understands the operations side well. As a result, you know what impact your choices have during development on the production environment.

Automate small things

Another easy thing to do is automating your own work. Take a look at the work you do. Are there any repetitive tasks? They can probably be automated. By automating these tasks you will have more time to deliver value for the customer.

Switch to trunk based development

Chances are that you are still working with long-lived feature branches at the moment. If so, it may be useful to switch to trunk based development. In my previous article I explained what trunk-based development is about. Now I will provide you some tools with which you can try to work trunk based.

Trunk based on dev

With trunk based development you have very short lived branches that are merged directly into master with a pull request. However, that does not mean that you immediately have to implement it that way. Perhaps you are in an environment where you do not have any rights on the master branch, or you must code in a dev branch first or you have another reason why you can not or do not want to push to master.

Even then you can still start with trunk based development. To start, create a branch per backlog item. When your backlog item is finished, merge it into your dev branch and create a new branch again. This will reduce the chances of merge conflicts and you will spend less time resolving these conflicts. However, not everything will have to be released, because you can cherry pick the desired features. This way you have the benefits of short lived branches but you do not have unfinished features in production.

Feature toggles

The next step is to use feature toggles. Make sure you create a feature toggle for the feature you start with. Then try to convince the person responsible for releasing the application to include a single feature that is not yet included in the release. You have placed this feature behind a feature flag that prevents the user from seeing it. Use a feature that is not too big to reassure the responsible person. When this is successful, he will hopefully see that there is little danger of releasing a feature with a feature flag and your team can work quietly towards real trunk-based development.

So…

As I said at the beginning, it is not the intention that you implement DevOps, but that you take parts that can be useful for your situation. Do not try to replace everything at once, but do this step by step. Also keep the goal in mind, stay critical on what you want to change. Does the change really add something valuable to your goal or do you do it because you want to work DevOps? When you do that, it does not matter if you call it DevOps, agile or scrum. These methods should help you deliver more value for the customer and are not a purpose themselves.