1. DevOps in a nutshell

Probably almost everyone has their own definition of DevOps, but basically it is about creating better software with a team empowering culture and fast feedback. 

You can look at DevOps also as a continuation of lean and agile transformation, so they do not contradict each other. It can be seen as a pragmatic extension for the current agile ways of working and Lean philosophy, focusing on delivering value to the end users. Shorter feedback loops from production to development reduce risks and enable better quality, as they allow us to better understand what matters to the end users. This is the main reason why it is essential to be able to ship changes and features to production swiftly.

To enable shorter feedback loops DevOps brings a set of practices that encourage software development and IT operations to work hand in hand. It is also characteristic to DevOps that the experts should have full ownership of their work. This way it is easier to explore new technologies and solutions, learn from successes and failures, and have everyone’s voice heard. 

At the heart of DevOps are empathy and understanding of what both the technical experts and the business people need to create competitive products.

A DevOps transformation requires support from the management and it should be seen as a journey, not a two-minute pipeline setup. On the way, there will be highs and lows that will teach the DevOps voyagers precious knowledge needed to become better. Every company must find its own way, as there is not only one way of embracing DevOps practices. Through continuous learning and focusing on human and humane interactions, it is possible to find solutions to even the most complex problems.

2. Treasure map to DevOps transformation

When searching for cultural change in an organisation, there are many obstacles and challenges on the way. DevOps transformation is no different in that aspect. We have found three typical categories for these possible barriers that need to be tackled on the road to DevOps land. Find out more in the following chapters what we want to say about organizational obstacles, psychological and communicational aspects, and only lastly technical puzzles that need to be figured out. 

Here is our treasure map to DevOps transformation!

2.1 Organizational obstacles

Organizational obstacles are things that manifest as rigid power structures and teams or shareholders having goals that detract from each other, instead of inviting them to work together. To get over these obstacles, it is useful to identify distinct groups within the organization that embrace change differently. Who needs to be won over before you can even start? Who are the allies that will help you pioneer the change for the early adopters to follow? And who are those that are only convinced when they see the transformation in action? 

Competing goals between teams or team members can cause friction between departments.

You can avoid this trap by aligning the objectives of different departments using customer centric thinking. All objectives should aim to bring value to the customers, and the related KPIs should measure the actual impact instead of the process itself.

Old school management culture can have difficulties trusting the teams with ownership of their work, leading to micromanagement and stamps of approval which slow things down. Letting the team try their wings and checking the results in small increments builds the necessary trust for the teams to handle their jobs independently. The teams should also have the freedom to choose the tools and methods they want, given they are compatible with the ones used by other teams.

When the organizational aspects are satisfied, the teams can pull together and work as a whole towards healthier, happier customer relationships.

2.2 Psychology and communication obstacles 

Some barriers to DevOps transformation stem from psychology and communication. Change brings not only hopes but also fears for the future. People might be scared for their jobs, making them oppose the change. Psychological safety enables that these concerns can be expressed without judgement and alleviated by facing them honestly. People need to feel safe to fail and share these mistakes, allowing learning and finding ways to implement improvements together.

Building a highly effective devops team requires skilled and motivated people. Where does this motivation come from? The best way to keep a team motivated is to give them ownership of their work and to allow them to participate in the decision making, for example in the architecture and choice of tools.

People who are used to doing things their own way might not be interested in changing their ways of working and don’t believe that DevOps mentality could benefit them. Ensuring that  two-way communication is in place and giving people the option to contribute to the change are vital in helping people see how the changes would make their lives easier and their work more efficient. 

However, some people like being the Hero™, who swoops in during crises, extinguishes the fires and solves the mysteries. The era of superheroes is over in a DevOps organisation and the heroes need to learn how to share their expertise and glory with the whole team. The challenge is to find a team with a well-fitting combination of skills. For example if you need to maintain and host your services yourself, having someone with cloud experience is beneficial. 

Different competencies are required during different phases of the life cycle, and knowledge and understanding should be shared with the team. The biggest change may be in applying engineering practices of continuous improvement and automation in traditional IT operations, not only maintaining all different parts of the product but also making the process more reliable with automation. 

2.3 Technical solutions

Only after building the organization culture around people and communication, we can gain the full benefit from technical implementations. Using technologies is simply a means of smoothing out the processes involved in software engineering and giving confidence to quality and speeding up development.

Automation has a vital role in any company that wishes to become a high performing DevOps organization, and as such, these organizations will have high levels of automation in their IT department. The kind of automation we are talking about is essentially about automating the repetitive processes involved in software development. This will also make these processes more robust and less error-prone, since they will be executed the same way every time. Moreover, automation helps in documenting the processes if the automation scripts are kept human-readable.

How does automation affect software development in practice then? Continuous integration (or delivery) pipelines are crucial for faster, more reliable deliveries. Automated testing during the pipeline, on both the unit test and functional test levels, is essential to ensure that we don’t just end up pushing broken things through faster. Continuous integration allows getting feedback to the developers as fast as possible. This is important because fixing issues gets more and more expensive the farther along they get in the development process. 

Static code analysis should also be included in order to catch issues detectable by algorithms earlier, as well as scanning for potentially harmful licenses or vulnerabilities. If possible, it is also a good practice to measure baselines for non-technical requirements, for example performance and accessibility, so when they are audited the audit process doesn’t waste time on the simplest stuff.

Monitoring the state of the application and end-user behaviour is critical for getting feedback from software that is already in production. The metrics to follow should be related to the actual customer impact if possible, as we tend to optimize the things that we measure. There are also different deployment strategies that can be utilized to ensure that our updates work well in production – a good example are canary deployments where a new version is gradually deployed to growing portions of the user base.

3. How to embark on your DevOps transformation journey?

DevOps practices have emerged to enable teams to solve business goals together more effectively, but quality can not be seen as a lesser goal either. If people are working towards the same goals, everybody can do their part to drive a high-quality DevOps transformation in the organization, no matter what the starting point is.

A DevOps transformation starts with paying attention to overall business understanding – what is my company doing and why? Who are we serving? In addition, everyone in the organization needs to know where we currently are and how we are doing. This makes everyone’s work more meaningful and their own work is more easily aligned with the overall business goals.

Empower teams to work independently and ensure proper support, whether the needs are technical or non-technical. Give teams full ownership of the product – and with it of course the responsibility for the product. Don’t be afraid of failing but make sure that you fail fast, keep the iterations and thus the possible failures as small as possible, and learn from those mistakes as an organization. Having a blameless culture in place is essential.

Build cross-team cooperation. Individual teams should also know what happens around them and work should be transparent. Knowledge and expertise should be easy to spread among teams and inside the organization. The responsibilities between different stakeholders and teams should be crystal clear, since gray areas in them can be devastating for product quality.

In DevOps, competence development and continuous learning together are crucial. Lone individuals or teams cannot succeed in a DevOps transformation alone, as it really is everyone’s job. This does not mean that everybody should do everything. Stop the hero culture and unreal and unfair expectations.

Everything that is done should aim to create some value to our customer or business. Measuring overall progress in creating this value is crucial and these targets should be aligned across the whole organization. This means teams certainly should not have any targets that compete with each other. Closely evaluate existing processes and their purpose to be able to cut waste and focus on creating value to the customer or business. 

Most importantly, a successful DevOps journey needs the whole organization behind it, management included. Without support you can’t get far! 

There were many tips/suggestions in this section, here are the most important ones listed as a checklist: 

• First, understand your own business in order to be able to lead your work in the right direction.
• Empower teams and give them ownership of the product, while ensuring proper support
• Accept failures as part of exploration, share and learn
• Build cross-team cooperation, share knowledge and make sure the various stakeholders’ roles are crystal clear
• Not everyone should do everything. Stop the hero culture and unreal and unfair expectations.
• Everyone is responsible to cut waste and always focus on creating customer value

About the authors: 
We are a group of VALA people studying DevOps coaching together in the Spring 2021 with various backgrounds in software development projects from test automation to development. We want to encourage everyone to take an active part in improvement efforts – especially DevOps transformation –  in the organization you are working with!

Best, 

DevOps Study Group:

Johannes Heikkinen, Juuso Issakainen, Joni Kotiniemi, Sami Nummela, Joonas Peuralinna & Leena Saari

• Blog
|
• DevOps