DevOps- The culture of collaboration

Nearly every enterprise is facing extraordinary competitive pressures. Innovative software is a great source of value to the customer, and for many organizations, it is what sets them apart from the competition. It is through tech-savvy, agile software that organizations build products and rapidly deliver business value to achieve a competitive edge.

While getting ready to build cutting edge software solutions, organizations often come face-to-face with five key challenges:

1.    delayed time to market,

2.    high development cost,

3.    long release cycles,

4.    disjoint functioning of IT with business, and

5.    poor quality products.

In the past, the software was delivered relatively infrequently. This gave operations teams ample time to prepare and meet the inherent performance and stability mandates for enterprise-grade applications. Developing software today means juggling more platforms, teams, tools, and infrastructure than at any point in history.

With the growing need for audit and compliance, it is critical that Dev and Ops have complete visibility into each other’s processes. Businesses now demand answers to challenging questions such as:

·      What changes went into this application?

·      Who approved these alterations?

·      What packages comprise this application?

Without a complete understanding of the entire Dev and Ops process, it’s not possible to conclusively answer these inquiries. Clearly, the time has come to bridge the gap between the Dev and Ops teams. 

Why DevOps

There happens to be a wall of confusion between developers and operations because institutions/organizations incentivize the opposing behavior of teams.

Developers are charged with adding new functionalities, making changes, and pushing the changes to the existing systems whereas operations are charged with maintaining stability and controlling the changes to the existing systems.

These teams are incentivized to care and optimize their areas of concern. Lack of context and conflicting goals enables misunderstanding to creep in and fuels opposing behaviors.

DevOps aims to take on this situation and offers solutions by creating a culture where both development and operations play on the same team. DevOps integrates the development and operations activity of the software development process for the goal of shortening development cycles and increasing deployment frequency. Also helps in answering compliance and audit inquires conclusively. Let’s look at what is DevOps next.

What is DevOps

Originating out of the Agile software development movement, DevOps is a culture where people trust each other, have full contextual awareness of why they are working as a team, do blameless postmortems, and keep transparent uptime of the systems.

DevOps is a movement by the practitioner for the practitioner.

DevOps is not a tool, not a standard, not a product, and not a job title. DevOps is a software engineering culture and practice that aims at unifying software development and software operations.

Gartner defines DevOps as “a change in tech culture, focusing on rapid software service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. It emphasizes people and culture and seeks to improve collaboration between operations and development teams.”

How DevOps helps

DevOps aims at shorter development cycles with more dependable and frequent releases keeping a closer alignment with business objective.

It encourages and enables both the dev and ops team to play on the same team, sharing the same goal, and chasing the same metrics. The Key dimensions and metrics it suggests to aim for are –

Dimensions –

·      Quality – technical debt paydown, compliance consistency. Customer-facing as well as a team facing quality.

·      Speed (Overall Lead Time, Delivery Lead Time, Deployment Frequency) – cycle time measures at different points of the process and at different levels of details

·      Operations (MTTR) – system efficiency in production. How easy is to operate, diagnose, and fix the software.

·      Infrastructure – cost, reliability, and consistency of the infrastructure we work with

·      People – engagement and motivation levels

Metrics –

·      Deployment/Change Failure rate – how often a deployment fails or software deployed in incorrect resulting in an outage or degraded service

·      Deployment Time – how long it takes to deploy the application

·      Regression Test Defects over time – how often have we regressed our software

·      Ticket volume – how many tickets are being raised against our software

·      Mean time to recover/restore – how long it takes to recover from a failure of the system. This includes identification of the issue, debugging, providing fixes, and releasing the fixes to production.

Further, it suggests to beware of metrics getting stale, e.g. if the delivery lead time is stabilized by properly implementing delivery pipeline skeleton patterns, identifying and removing bottlenecks, putting technical best practices in place. And still if one feels that it is taking time in releasing the feature to production, then it’s time to focus on end-to-end lead time.

It’s a good idea to pick applicable metrics than trying to improve on all these metrics. A good starting point would be quality, speed or operability. One should avoid improving one at the cost of the other. Metrics goes up and down over time, it’s important to have an acceptable variation limit.

It also warns us that we should never use metrics to compare teams against each other. Each team is different with their own background, stage of maturity, and complexity of the software they're responsible for.

It recommends looking at metrics as guidance for outcomes, not as a tool to compare teams. What we want to ensure is that we're going in the right direction, by progressing on the key metrics we care about. Avoid the temptation to search for magical numbers for these metrics, or to standardize across teams.

Another goal of a successful DevOps practice is to produce and filter pipeline data per user persona of the team. User personas are a representation of a class of users of our system personified as an individual with specific needs, skills, goals, and frustrations. User personas for a delivery pipeline might include developers, testers, operators, but also product owners, marketing, or compliance officers. Understanding user personas' needs and frustration helps put the right information in front of the right people, at the right time, and in the right format for them to consume.

How Teams and Its Leaders can build a DevOps culture

To build a DevOps culture aiming a higher velocity of concept to cash, Leader should focus on building –

·      Ensuring Dev and Ops are playing on the same team and their share the same goals and track against common metrics

·      Trust and Discretion among teams

·      Provide context and clarify ambiguity

·      Independent cross-functional teams. The destination is to have an end-to-end accountable team, until then we can aim for a separate delivery team, a lean operations team, and a DevOps team sitting between these two teams.

·      People first approach

·      Agile and lean processes, DevOps grew out of the Agile software development movement

To build a successful DevOps culture, where both Dev and Ops are playing on the same team, Teams should focus on - 

·      Having a common backlog for all participating functions, this brings transparency and increase systems thinking for the final aim of making the deliverables run in production.

·      Building a common vocabulary, to help all speak and understand the same language.

·      Relevant information radiating to appropriate stakeholders. Automated notifications broadcast to the team’s communication channels, like Jenkins pipelines to Teams channel.

·      Doing a blameless postmortem, human error can’t happen if the process didn’t allow.

·      Adopting to 5 Why principle to reach the cause of the problem. Focusing on causes and not symptoms. Human error is not an acceptable root cause.

·      Knowing stakeholder’s persona and accordingly automate filtering and dissemination of required information/metrics out of delivery pipeline data.

What After DevOps

Out of many possibilities here are a few –

·      A backlash against DevOps and some alternative processes, culture, or practice taking over space by doing things differently, or it stays in hybrid mode, where its principles, tools, and practices get mixed up with earlier eras principles, tools, and practices of software delivery.

·      Another possibility is that organizations start to extend DevOps in other areas of businesses that are not directly related to it, dev and ops. For example, DevSecOps (extending DevOps into the security realm), DevQAOps (integrating Quality Assurance into continuous delivery). Or other relevant departments like legal, Open Source Software compliance getting tightly integrated into the software delivery process.

In conclusion

DevOps is not only important to speed up software development, but also improves the quality of the software. DevOps bring a new mindset, agile practices, and smart tools that together accomplish that goal. Besides that, DevOps can help with the spotting of coding errors very early in the CI/CD cycle, improving communication between team members, and is overall cheaper for developing software. With so many benefits like faster development & quicker innovation, fewer mistakes making to production, motivated & engaged staff; it is not hard to see why DevOps is the choice of any organization.