5 Characteristics of a DevOps Organization

Characteristics of a DevOps Organization

The characteristics of a DevOps organization encapsulate a set of guiding principles and behaviors that collectively drive efficiency, agility, and innovation throughout the entire software development lifecycle. Here are some of the most important ones:

Product-Based Teams Over Component Teams

Autonomous and cross-skilled teams are key to deliver and maintain products. An organization structure that is based on knowledge silos (such as Dev, QA, Ops) is bound to create multiple overlaps and thereby increase waste and risk of things going wrong. In a mature DevOps organization, you will typically find organizational structures based on the products/services they offer.

However, there is still value in “component teams.” For instance, the core technology services/capabilities of the IT organization can still be fulfilled by a technology team. This is an acceptable situation when these core services/capabilities are enablers for other DevOps teams to deliver value to end customers.

Obsession With Automation Over Preoccupation With Manual Work

DevOps teams are obsessed with automation. Every manual task has an increased risk compared to its automated counterparts. In most cases, one of the biggest bottlenecks in the overall value stream is manual interventions. This manual intervention is also highly error-prone and time-consuming. Hence, mature DevOps teams rely on automation to achieve consistency and speed. DevOps organizations enable their teams to focus on consistent automation of all their activities such as infrastructure, deployments, testing, documentation, etc.

However, there is still value in some manual interventions. Typically, activities such as exploratory testing or end-user training might still require some manual effort but this should be kept to a minimum or look for ways to automate. To get early feedback from a customer, DevOps teams can use techniques such as canary releases, feature toggle, A/B testing, dark launches, automation testing, etc.

Evidence-Based Over Gut Feeling

DevOps teams measure what matters. Their KPIs give insights into various aspects such as code quality, build quality, release quality, NFRs, and various production monitoring metrics. Technology and business decisions are driven by data. For example, how did new architecture design changes impact performance? How is the new feature we implemented being used by our users? When do users use a feature in our application? How does the new code we shipped impact our code security or quality? Things like these are answered by hard facts and not by the gut feeling of the team.

Data-driven decision-making is one of the key aspects of DevOps teams and organizations. However, in some instances, businesses might make some decisions such as a new feature implementation based on gut feeling. However, decisions that are based on a certain hypothesis need to be validated with data after a release, but preferably before that.

Teamwork Over Individual Work

DevOps teams require a high level of professionalism and engineering excellence. Professionalism is reflected in their ability to do the right thing, the courage to say "No," the willingness to ask for help, disagreeing respectfully, commitment to deliver, and the ability to have an open and honest collaboration with each other. When people disagree, argue, or criticize, they shouldn't disrespect each other. They only disagree with the idea, not the person.

For members in a mature DevOps process, teams hold each other to higher standards. As a team, they celebrate each other's successes, which is in turn the team’s success. This promotes a sense of achievement, and quality, and is a great engine of motivation at the workplace.

Fail Fast Over Delayed Learning

Mistakes are mandatory for learning! A team that always plays it safe without exploring uncharted territories, will not often challenge the status quo. Mature DevOps teams/organizations perform blameless postmortems to learn from mistakes. Often, these lessons could be then shared organizational-wide.

Failing fast will be an effective strategy only if the cost of failure is small, manageable, and doesn’t result in a cascading chain reaction. This is where effective feedback loops and a high level of automation come in. Apart from this, mature DevOps teams have a culture of trusting each other, challenging each other, and an eye for constant improvements.

For example, in our organization, we have a culture of celebrating failures and mistakes. At every monthly all-hands meeting, employees share their biggest mistake/failure of the month. Then, the whole organization votes on which is the biggest “screw-up” and that person wins a nice dedicated parking spot for a month. This resulted in a culture where people are open to sharing their mistakes and all of us can learn from them.

Do you notice these characteristics in your team/organization? What would you add to this list?