Why DevOps?

There can be many positive effects of organising as a DevOps organisation. If you look at companies that are further in a successful DevOps journey you see that it has an overall positive effect on the whole system that is that company and their products. 

However great they are, in most companies it isn’t possible to achieve all of these positive effects in one go. There is a need to implement gradually, iteratively and learn from the iterations while keeping the store open. 

Pattern

A pattern that can be regularly seen is that the reason for organising as a DevOps organisation is unclear/implicit.

Symptoms 

Some symptoms amongst others you will recognise is that employees have a hard time adopting DevOps WoW since the direction and reason are unclear. 

There are many different views on the value and definition of DevOps and what is expected from a DevOps organisation and the employees.

Discussions are not about the essence of DevOps (and often Agile) but more on a mechanical level.

Since the reason for DevOps is unclear there are many views on what is important and what should be done first.

Long term effect

You often see a history of many initiatives starting and stopping and much effort put into finally getting the WoW to work.

The desired outcomes (more quality, speed, levels of knowledge, lower costs etc) are not being reached since there is no clear direction where to start.

Frustration concerning the lack of progress turns into general apathy.

No clear and concise definition of the why results in many discussions on what is most important and how to approach.

Where to go from here

Like stated earlier there can be many reasons to organise as a DevOps organisation but often an explicit reasoning of the why, who will benefit from it and in what way is absent. A strong emphasis on innovation has a different implementation strategy than if the primary need is to improve stability

• It is important to make what is being expected from the organisation, the teams and individuals very explicit.
• Propagate that the road to a DevOps organisation is a never ending continuous improvement journey that will be taken in baby steps.
• Explicitly and transparently discuss the expectations and the concerns with teams and individuals as leadership.

The first step is to choose a main reason in this moment of time for organising as a DevOps organisation. See this as a starting point in the journey to embed DevOps and not the end goal. Starting is the hardest part. When looking at the essence of DevOps practises the rest will be pretty easy. By choosing this starting point you will help the organisation by bringing focus:

 We want to organise as a DevOps organisation because it will increase our _____________(choose one from the list below)

• Speed of software delivery
• Quality of processes and products
• Service to our colleagues and customers
• Speed of Innovation
• Costs reduction

The second step is to make the vision on DevOps more explicit. This way we make sure the whole organisation understands who is responsible for what and what is expected from everyone. This exercise will give great context to all involved. There needs to be a clear and concise view on what is our understanding of DevOps, what that means for every team and each individual. For example:

When we in Company X talk about DevOps we talk about:

• a set of practices that combines software development and IT operations.
• shortening the systems development life cycle (planning, analysis, design, development, testing, implementation, and maintenance)
• continuous delivery of high software quality.

When we in Company X talk about a DevOps team we talk about a multidisciplinair team that has the responsibility for both change and run of an application or service.

That means that the responsibility of the following is also a teams responsibility:

• Securing the Service Level’s to which their application is bound
• PBI’s for analysing and solving problems
• The status and roadmap of the reduction of tech debt
• Test, build and deployment automation
• Proactive monitoring of all applications (also when hosted at third parties)
• Scripts are considered code and should be tested and versioned
• Happy end users
• …

Step three is to share the expectations and have meaningful conversations with teams. Some will have valid reasons for not being able to do a certain practise while others just need a bit more guidance. Some just need to get something off their chest and others need assurance that leadership will make sure that they will provide all necessary resources in regards to people, process and technology.

You are now entering the subject of change management and depending on the starting point a roadmap can be made and shared. It will be tough sometimes but now everyone in the companies have a shared understanding of the goals and directions the change will take them. You now have a shared conception of the why and where to start.

Onwards you will see other challenges, which we at Software in Rhythm like to call patterns, which you will have to solve step by step. Please have a look at our ever expanding list of patterns and their solutions here.