DevOps — People before Tech

“You are either building a learning organisation or you will be losing to someone who is.” – Andrew Clay Shafer

Delivery focused leaders often prioritise milestones and deadlines over people and culture and treat technical work as a technology and process challenge only.

This article can help to make the point on how investing into implementing generative culture measurably contributes to more effective delivery in the form of eliminating non-value-add work from the overall process.

My?former article?touched on how to raise awareness of the different priorities and focuses the Dev and Ops teams have. This article gives a further insight into how the organisational silos are generating waste and increasing total cost of ownership.

The three layers of the comprehensive DevOps approach

The three key aspects that represent the critical success factors for any DevOps implementation are:

• Culture: implementing?generative culture
• Practices: adopting existing frameworks including?ITIL,?Lean?and?Agile?and adapting them based on the opportunities for improvement identified by measurement and monitoring
• Automation: adding the level of technology and automation to culture and those practices to streamline and accelerate them. Note: automating bad processes will end up in bad results, the culture and practices factors should be addressed first before adding the technology support

How did task specialisation become the norm?

Modern organisational structures inherited from successful earlier approaches.

Adam Smith (in 1776!) advocated?division of labour?to represent a substantial increase in productivity. He argued, the specialisation and concentration of the workers on their single subtasks often leads to greater skill and greater productivity on their particular subtasks than would be achieved by the same number of workers each carrying out the original broad task. This concept of task specialisation went mainstream with?Henry Ford’s assembly line?revolutionising the American industry in 1908.

The focus on task specialisation, control and measurement are still present in today’s organisation structures. Although it is proven very effective for manufacturing pipelines, it does not answer all the challenges in scope for modern?IT service management.

Team silos vs silo mentality?

Many organisations are trying to break down silos via organisational redesign. They are getting rid of their manager-led, functional teams and moving on to self-organising, cross-functional structures. Although this is an enabler, it doesn’t fully address the silo problem which is rooted in mentality.

Silo mentality occurs when a team or department shares a set of common tasks but operates disconnected from other groups, with their power derived from association with their function or shared technical knowledge.

Some examples of these:

• The “testing team” — focusing on one slice of the process, optimising own approaches, tools and processes, disconnected from the end to end process. They don’t share how to build quality in the end to end process, adding testability requirements, and sharing their knowledge with cross-functional team members. They are ‘managing’ a task and this way, sustaining the reason for their existence
• Feature teams working on the same product but owning one specific user journey — focusing on their slice of the product only, making their choices in terms of 3rd party libraries, technologies. They don’t contribute to end to end optimisation of technologies, approaches, cross-pollinating best practices and reusing solutions instead of duplicating them.

How does the silo mentality generate waste?

Silo mentality leads to a lack of?systems thinking?which is essential for?continuous improvement?of an organisation. In this context, systems thinking means the teams understand that their function is part of a larger system, interrelated and interdependent on other teams, and the system is more than the sum of its parts.

Losing focus from the big picture leads to local optimisation of tools, solutions and processes, which creates

• Overall process complexity due to the complex hand-offs between teams (dependencies) are treated as external to the silo therefore out of focus for improvements. Waiting for resources, information, approval, decision, feedback
• Lack of building or contributing to shared capabilities and resources results in duplicates, re-works and divergent solutions. Working on unnecessary deliverables or features

Waiting, overproduction, defects and over-processing?are forms of non-value-add work (aka waste) which should be removed from the overall process.

How does DevOps address this?

DevOps encourages generative culture

• High cooperation: via cross-functional teams that include representatives from each functional area of the software delivery process
• Messengers are trained: by removing blame and fear, enabling people to bring bad news so we can make things better
• Risks are shared: quality, availability, reliability and security are everyone’s job. The more eyes on the software delivery process, the more errors can be avoided in process or planning
• Bridging is encouraged: by co-locating Ops with the Dev team and including Ops in planning throughout the software delivery lifecycle, continuously breaking down silos is embedded to the organisation
• Failure leads to inquiry: via blameless postmortems, asking questions about what caused the failures and how to keep them from happening again in the future, the technical system, processes, and culture is on a continuous improvement spiral
• Novelty is implemented: giving employees freedom to explore new ideas can lead to great outcomes

DevOps focuses on systems thinking

DevOps puts the focus on all business value streams that are enabled by IT. Simply put, how work moves from Dev to Ops, from left to right, one team to another. Once it is identified how the individual pieces fit together, it?identifies constraints, finds where are the bottlenecks in productivity so that removing those can be prioritised for the biggest positive impact.

DevOps embeds amplified, right-to-left feedback loops

The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made. Feedback loops help to create safer, more resilient systems of work because they provide more opportunities to detect and correct errors.

DevOps brings in learning culture

DevOps promotes creating a culture of continuous experimentation and learning to enable the ongoing creation of knowledge for individuals, teams and the organisation. Turning local knowledge to global improvements, and approaching failure as a learning opportunity for all enables the organisation to see the value in trying new things and innovating.

People before Tech

DevOps gives an effective answer to the business value delivery problems and the IT value delivery problems the modern IT service organisations have.

Building on existing frameworks including ITIL, Lean and Agile, unlocking scaling via automation, DevOps boosts delivery efficiency and scale at the same time.

The one thing making DevOps a truly brilliant philosophy is that it introduces a cultural shift that permeates throughout an entire organisation. It puts people before tech which is a huge step towards a happy, engaged, efficient and productive organisation.

Okay, so where to start?

DevOps provides the signposts for establishing a generative culture, systems thinking, and amplified right-to-left feedback loops… still many organisations and leaders don’t know where to start.

When you are starting out on adopting DevOps for your organisation… I’d recommend focusing on the following:

• Familiarise yourself with the “Law of Diffusion of Innovation”, which is an effective model to use for transformation, DevOps transformation included
• Identify the Early Adopters in your organisation and focus your efforts on them. These individuals have the highest degree of opinion leadership in your organisation
• Your Early Adopters are colleagues who are struggling with problems the DevOps transformation addresses, and are actively seeking a solution to their problems
• Train them for DevOps fundamentals, principles, practices. Once they become aware of how DevOps solves their challenges, you can ask them to join you to develop your organisation’s DevOps transformation program
• Those who volunteer to join and work on the transformation will become ambassadors and agents of change… because they believe in it. Since they have the highest degree of opinion leadership, they are best placed to facilitate the diffusion of change throughout your organisation
• As part of the transformation program, you can create an initiative to demonstrate the impact of the cultural change, e.g. how psychological safety, focusing on continuous improvement, experimentation and innovation enables and empowers colleagues to start challenging the status quo, start asking the right questions, taking ownership of making improvements
• Focusing this on a tangible initiative, creating a 'lighthouse' that enables others in your domain or organisation to see and understand how the full-stack DevOps principles would work in their area, and drive further adoption within your domain
• Once there are multiple teams adopting DevOps principles, it's time to create a Community of Practice where colleagues can share learnings, best practices, can inner-source solutions, demonstrate the technology and business impact of what they are doing
• This Community of Practice could then build and establish those ambassadors, 'coaches' for further initiatives to spin up and drive further adoption of the principles, facilitating the DevOps transformation for your organisation on an even larger scale

Adopting DevOps can be tricky and can take a long time. Be patient, it will be worth it!

Links

Here are some links to follow up and find out more about the concepts mentioned in this article:

• Great DevOps reports, trainings, case studies —?DevOps Institute
• Google article about the?Westrum organisational typology and generative culture
• Westrum, R. 2004. A typology of organisational cultures
• Simon Sinek —?The Law of Diffusion of Innovation
• Differences and similarities in?Lean vs Agile
• Scrum —?Official Scrum guides

Contributing through comments

It would be great to hear your thoughts on this article by commenting on the page or contacting me through Medium, LinkedIn or Twitter below. I am happy to bounce ideas or chat about the topic so feel free to contact me to have further discussion, share what you have learned or tell me your ideas on how to bring developers and operations teams together effectively ??.

Connect to Miklos on Medium

https://medium.com/@miklos.sagi

Connect to Miklos on LinkedIn

https://www.dhirubhai.net/in/miklossagi/

Follow Miklos on Twitter

https://twitter.com/SagiMiklos