From mindset to culture: key insights to know in your transition to DevOps

Are you transitioning to DevOps, contemplating to do so, looking to improve your existing DevOps culture or approach, or just fill the gaps between expectations and reality?

From mindset to culture: key insights to know in your transition to DevOps

Are you transitioning to DevOps, contemplating to do so, looking to improve your existing DevOps culture or approach, or just fill the gaps between expectations and reality?

The stage at which you are in your DevOps journey is not as important, as this transition is a process rather than an overnight change, requiring successive iterations of improvement.

With this in mind, we’ve collected a series of articles that explore the topic of DevOps into its depths, offering an overview on: the DevOps mindset, how does a medium-term agenda for a DevOps implementation could look like as well as the techniques and solutions for getting the DevOps culture right.

Let’s see what the specific articles discuss about:

  • The essentials of the DevOps mindset & its benefits

  • Address the cultural issue

  • Engagement and business re-alignment

  • Continuous Delivery workflows and progress acceleration

  • The case for a change in culture

  • Techniques and ideas for IT executives to get the DevOps culture right

  • Bonus: 20 things that high-performing organisations do

The essentials of the DevOps mindset & its benefits

So what’s the more important piece of information that an IT executive should be in possession of?

First of all, it’s crucial to understand the real importance of DevOps and Continuous Delivery for businesses

DevOps and Continuous Delivery are far from being trends. They represent a quiet and necessary revolution, meant to introduce innovation into IT departments and regain the time lost in fixing bugs and patching code.

This revolution brings companies closer to the era of the digital business – as Gartner envisions it.

The adoption of DevOps and emergence of Continuous Delivery are imminent for businesses but it’s important to understand it’s a process and one which companies need to progressively adopt a new mindset for.

Continuous Delivery is also one of the pillars that support the building of an Agile culture which is essential for any digital transformation project.

The main principles for a DevOps/Continuous Delivery mindset:

Turning this mindset into a reality can be a challenge for today’s IT leaders.

But, from my experience, it often boils down to just two key points: collaboration and automation. So in order to make Continuous Delivery a reality, I believe that companies must change the way people work together and start automating.

Align your expectations: where could collaboration and automation take you and your team?

DevOps and Continuous Delivery can make their mark in three major areas:

  • Agility & speed

  • Optimized costs

  • Increased quality

Address the cultural issue

According to a Perforce report, 35% of businesses are yet to embark on the path of Continuous Delivery 28% say they are using it across all of their projects and 37% say that they are using a Continuous Delivery approach only on isolated projects.

So what is it that inhibits an IT leader from introducing a Continuous Delivery approach on all projects instead of just an isolated few? In today‘s lesson, we will attempt to address this question.

First things first: addressing the cultural issue

You may have, by now, be familiar with the benefits of DevOps & Continuous Delivery and you may be determined to make a move. But before you start, it is the people aspects that you should consider as a priority.

Does your team’s culture inspire the right attitude that is necessary for a successful implementation of DevOps & Continuous Delivery?

If not, how can you start inspire the change?

Some might say that the absence of a DevOps culture is what might initially impede a smooth transition to Continuous Delivery. Almost everybody in the industry talks about DevOps as a culture but they fail to draw the line between the theoretical dimension and the practical aspects.

Gartner’s view may turn on some lights.

“DevOps is a philosophy, a cultural shift that merges operations with development and demands a linked toolchain of technologies to facilitate collaborative change.” – Gartner. Source.

DevOps is supported by a set of technologies and practices that facilitate agility and encourage collaboration between all stakeholders in the value stream. This transforms the way IT leaders and product managers deliver customer value. With DevOps, people work together using automation wherever possible, following a set of practices that improve the way projects are delivered and forging the way towards innovation and change.

Nevertheless, in a complex IT landscape where multiple stakeholders, assets and variables must be taken into consideration in order to inspire and generate change, what can be done to prepare for it?

Engagement and business re-alignment

So, what can you do, as an IT leader, to prepare for DevOps adoption? Here are a few high-level tactics that might help you redirect your efforts effectively.

Start engagement and help people along the path of continuous improvement

Cultural change happens when people are engaged, informed and aware of their role in the process. What’s in it for them?

To introduce a DevOps culture, you don’t have to start by implementing a CD workflow or by creating a CI / CD infrastructure or completely change the way you deliver your features. Don’t try to eat the problem in one sitting – take it a spoonful at a time.

Start small – with the people, not processes or tools. For example, have “continuous improvement” as a secondary objective.

A good starting point could be testing. Incentivise your people to find ways to improve how testing is performed. What can be done better?

How about tasks? How can they be broken down to achieve a higher level of continuity and speed in terms of improvement?

Progressively, start bringing all teams together in sprint discussions – development, testing, QA, Security, Audit, Operations and the Product Owners. Establish cross-functional teams to break free from the silos and reward collaboration and communication instead.

Acknowledge the reality of failure and frame it in a new perspective. In DevOps, accepting a few failures is essential, as it motivates people to experiment and find new ways of doing things better.

In your effort to introduce change, getting to know your stakeholders and appreciating their roles and challenges is essential. Identify the leaders, early adopters, promoters and followers. Delegate the tasks to the appropriate roles and watch how a focus on continuous improvement starts to transform the organisation into a more open, blame-free and collaborative culture.

In parallel, introduce training and communication events on the topic of DevOps and Continuous Delivery. This will build upon the base of small changes that you’ve encouraged in your team and empower them with the knowledge to fully adopt a DevOps culture.

Find the way back into the business

While you are steering your team towards DevOps and Continuous delivery, you are also establishing a path back to the business-side of your organisation. CD practices and the DevOps culture bring the IT team and the business together. As the team becomes more agile and communicates more, it will now be able to create and continuously improve on delivery of new features based on real-time user-generated feedback. This will gain more time to innovate – for the benefit of the entire organisation.

Now you are well on the way to demonstrating how IT can be a real asset to the business, your team will be able to adapt itself to the changes generated by any market shift or change in business strategy.

Bearing this in mind, identifying the key business objectives, market requirements, customer behaviour and customer pain can help you further outline the way continuous delivery should look in your organisation. Adapt your way of working to something that is totally focused on a fast, flowing and highly secure delivery of business value.

Continuous Delivery workflows and progress acceleration

Preparing for DevOps in advance can be a strategy that everyone can benefit from. Even though you haven’t a culture or tight processes in place, you still can take steps that would slowly shape your culture.

Here are two more tactics you might want to be aware of and eventually discuss with your team.

Identify and define your CD workflow

A few lessons back, Gartner said that DevOps is a cultural shift that merges operations with development and demands a linked toolchain of technologies to facilitate collaborative change – we now need to focus on the toolchain aspect of the issue. More specifically, there’s a need to think about outlining and building a pipeline able to deliver excellence and continual feedback and learning.

In its simplest form, a DevOps pipeline, or a Continuous Delivery workflow can look something like this:

However, due to the complexities of IT environments and its limitations, it may resemble something like this:

Here we exploit automation to ensure a fast and efficient deployment of production-ready code, tested and ready to go whenever we want it to. The high-performing organisations always have their systems in a state where they can be shipped at any time.

The benefits of Continuous Delivery, in this case, are attainable via a micro-segmented delivery, which allows your team to control the impact of the deployment, its level of complexity and gain immediate visibility of any problem areas.

Start to accelerate progress

The actions you take to remove the roadblocks to accelerated delivery will get you on the right path. Adopting DevOps is like any transformation – it’s 80% people and 20% process and tools.

Remember you are bringing together functions with diametrically opposed terms of reference with the goal of attaining world-class capability – for the organization and not the silo.

The DevOps mindset is about innovation, automation, collaboration and improvement. Your team will become a creator of business value, with reduced risks, higher quality, better security and exponentially quicker speed to market. All of these things will free up time for your people to be creative as all historical constraints will have been identified and removed. Gone will be the days of huge communication efforts for every release, multiple hand-offs and single points of failure.

It is an enormous opportunity to both do things differently and make that difference.

The case for a change in culture

To make DevOps work, what we need is a change in culture.

Do you wish you had a pound, euro or dollar for every time you heard someone say that? It’s ubiquitous – a sign of the times and a sad reflection on the current state of organisational design, if true. Ironically, these words are often spoken by the person or people responsible for creating and encouraging the existing culture in the first place.

But can culture ever be changed?

Is it mission impossible or do we have to accept that the best we can achieve is to change the way the work works and the way people think and work together? This may be good enough. Changing customs, values and beliefs is a tough call.

Although this is about DevOps, the content could equally apply to many transformational attempts in other areas. It’s just that DevOps is a little more challenging than the norm. We are asking people to work together when they have never had before. In fact, once could argue that collaboration and co-operation has been actively discouraged as the objectives of the organisation have taken a lower priority than those of their particular silo. It’s not an easy ride.

DevOps requires Product Owners, Software Development, Infrastructure and Operations, QA and Testing, Security and other support functions to work collectively in order to create, support and improve a secure environment where valuable work flows smoothly between processes and hits production at speed, with high levels of quality and security and at a time the customer demands it.

These disparate groups have to unlearn the things they have been brought up with to create a brave new world of continuous integration, delivery and deployment, always being in a position to release a version of a system into production. The days of the monthly or quarterly release are numbered – great for business, not so great for the pizza company with their late night deliveries to our heroes.

Yes, there are some great tools that will enable the new tool chains to be architected but…

…total success will only come if the people issues and challenges are addressed up-front.

So what can be done? How does one start? For the last couple of lessons in this course, we’ve prepared a list of techniques and ideas for IT executives to get the DevOps culture right.

  • Communication

  • Value stream mapping

  • Business simulations

  • Lunch & learns

  • The IKEA moment

  • Coaching

Techniques and ideas for IT executives to get the DevOps culture right

Communication

Leaders need to let everyone know why things have to change and what the world will look like in the future, for ALL stakeholders in the value stream. As Simon Sinek says – Start with the Why? The How? and The What? can come later.

Tell everybody that they will be working in a blame-free environment where innovation and experimentation is encouraged. Product Owners need to understand that not everything will work first time out but the new processes will enable a Fail fast, Backout faster strategy – they will hardly notice.

Then, assure people that reduction in headcount is not the name of the game. The focus will be on removing non-value added activities (when it makes sense to do so) and the automation of manually-intensive tasks. There can then be a blitz on all the things everybody has always wanted to do, but never had the time, authority or budget to address e.g. reducing technical debt, re-architecting applications to build loosely coupled services or simplifying the landscape by removing redundant tools and hardware.

Also, let everybody know that performance-related objectives will give priority to organisational goals as opposed to functional or silo-based ones – with a focus on teamwork. The organisational model will change and there will be a little disruption to be expected as everyone gets used to their new role. This is to be expected.

Finally, let the people know that they are working in a learning organisation and channels will be opened for everyone to share knowledge and best practice, as well as what doesn’t work so well. Knowledge is not power; heroes will be thanked for their great work and support in the past but they will be required to work for the team in the future and strive to remove constraints and single points of failure, instead of being one.

Do this and do it continuously in support of the initiative. Be visible and open to challenge. Ask what’s not working and give your support to getting things fixed. Walk the talk and don’t just ask to be told when it’s finished – DevOps never finishes – it is continually improving.

As someone wise once said – it’s time to stop starting and start finishing.

Value stream mapping

Take a look at the principles and activities outlined in the book of the same name by Karen Martin and Mike Osterling. A key component of the lean movement in manufacturing is to remove non value-adding activities or certainly reduce them from the value stream. Focus on mapping at the macro level to give visibility and let the teams work at the micro level after the exercise.

As with any change, everyone needs to understand how the work works today before they can truly envision the future state and implement a transformational plan. A cross-functional team should walk the chosen value stream and observe what happens, at least twice, before mapping the current state. This is where the team starts to gel as there will be some astonishing findings that will enable everyone to understand each other’s problems and issues, probably for the first time.

Again, it must be stressed that this is not a headcount reduction exercise or a time and motion study but a knowledge gathering exercise for the team. Everyone must feel safe or the results will be skewed; the process is being measured not the person.

Health warning: This is an intensive exercise and to gain the most benefit, it is strongly recommended that an expert facilitator is procured who will guide the process, keep everyone focused and ask the challenging questions. It is an advantage if the facilitator has minimal knowledge of the value stream being mapped – this will keep their interventions at the appropriate level

Business simulations

These are worthy of consideration. It is becoming widely accepted that Game-Based Learning is far more effective and delivers more rapid improvements than having just a classroom approach to training.

Why not mix up the silos and get people working together on a real assignment and see what happens? Collaboration and Competition over two or three rounds will almost certainly produce some astonishing outcomes and in every game, the chaos of Round 1 becomes a dim and distant memory by the end of Round 3 and the actions can be taken straight back into the workplace – the next day – and the basis of a highly effective team has been established.

Lunch and learns

These are great ways of engaging people but need to be carefully thought through. People are being asked to give up their personal time so the topics being discussed need to cater for the needs of the entire stakeholder group.

Why not invite industry experts to run the first couple of sessions? They can come on-site and talk about their experiences, do’s and dont’s and the real benefits from every perspective. The What’s In It For Me Stakeholder Map will then begin to take shape and if all goes well, people will start to talk to their colleagues, and a groundswell of motivation and enthusiasm will begin to build.

Health warning: This is not the forum for sales pitches about consultancy or tools. These may result as a by-product but the focus must be on providing great content and helpful hints and tips. Many transformation and major change programmes have failed as a result of taking on external help and then abdicating the delivery to them (it’s not their programme).

DevOps is the real deal and needs to get continuous backing from the leadership team.

That IKEA moment

It will soon become obvious that the office design needs a total makeover; people who now need to work together will not be sitting together – on the same office floor, in the same building or even in the same city.

This is unavoidable but if people can be co-located – it’s worth considering. This may not be practical in all cases, so look at tools and processes so everybody can have a quick and easy access to each other when needed. There is no point in reducing non value-adding work and hand-offs only to find that the communication channels have not taken into account the new ways of working and wait time doesn’t reduce by as much as it should.

This is also a great opportunity to make the progress visible, whether by charts or kanban boards – whatever works for the organisation. Everyone can then see what’s going on, the progress being made and how serious executives are to making it work. It’s always good to see the grown-ups when things are going well and not just when there’s been a major incident.

Coaching

Trained coaches should be made available to everybody as they go through the change curve. These can be external and independent or trained-up members of the workforce who have shown both enthusiasm and a natural aptitude.

Coaches challenge by asking difficult questions and help people find their own way through the treacle. They are not mentors; they need not know anything about DevOps; they need to be able to motivate and encourage. A great coaching session should feel like it would feel after 10 rounds with a boxing champion – it is not a cosy chat!

However, in some cultures, coaching is seen as a nice to have or a failure in leadership. This is quite strange as most great leaders have coaches and nobody bats an eyelid. The key is to make sure there is a safe environment where rapport and trust can be built up over time between the two parties. What is said in the session, stays in the session.

Lose the trust – Lose the individual – Initiative sunk below the water-line.

20 things that high-performing organisations do

Have you ever attended an event where there have been sessions on creating high-performing teams within even higher performing organisations?

I always ask the question – Compared to what? It’s actually the same answer to many questions such as those on daily rates or costs of services. There is rarely a well-thought through answer based on data, which means it’s just someone else’s opinion.

In the DevOps world, Puppet Labs and DevOps Research & Assessment (DORA) produce a survey based on science not opinion. It contains feedback from over 27,000 professionals world-wide over a five-year period.

Of course, no high-performing organisation can exist without visionary, transformational leadership; one that creates an environment of trust that is free from blame when things start to go wrong.

So what are the things that high-performing organisations do? Not necessarily the unicorns such as Amazon, Google or Netflix as they are well ahead of the game. What are the benefits that can be obtained from the journey? – and let’s not forget it is a journey and not a sprint.

Below is a summary of activities and outcomes:

Here's what it's like

  • A culture that is highly co-operative and collaborative – where risks are shared, innovation is encouraged, learning is mandatory and failure leads to an investigation and not a witch-hunt.

  • Transformational leadership is visible – everyone knows why, what and when. The leader walks the talk.

  • All work in progress is visible – everyone can see where features have progressed to in the value stream.

  • There is a strictly observed limit on work in progress to ensure maximum throughput and flow through the value stream.

  • Quality is built in from the beginning via peer level review activities and processes.

  • Security considerations are left-shifted so they are not an afterthought a few days before Go Live.

  • Everything that can be automated, is – e.g. version control, code deployment, testing, environment creation.

  • New features are built in small batches that can quickly be switched off when there are live issues e.g by feature toggles

  • There is a continuous blitz on the existing architectures to ensure they are loosely coupled and teams can act autonomously to deploy new features without impacting other functions

  • All branches are integrated into the main trunk at the end of each day

  • Releases can be deployed at will – even during business hours

  • Implement customer feedback on new features immediately

  • Ensure all change approval processes are as light as possible.

  • Monitor both applications and infrastructure and act on feedback.

  • Relentlessly strive for continuous improvement – there is no end

  • Let the teams choose their tools to design the chain

  • Let the teams choose their own training plans – give them a budget

  • Use automation to regularly communicate good/bad practice (ChatOps)

  • Give dedicated time to experiment and learn – DevOps Dojos

  • People will encourage others to join as it is now a really great place to work.

On any journey – and the DevOps journey makes no exception – there will be turbulence; but fly though it and come out the other side for a smooth landing.

Thanks for reading! We’d really appreciate it if you share this post so other people can find it.

P.S. If you enjoyed our article, please consider joining the mailing list, where we share the lessons we’re learning on our DevOps journey.