5 Characteristics of a DevOps Organization
5 Characteristics of a DevOps Organization
Increased dedication to automation and collaboration, the ability to fail fast, and using evidence over instinct are signs of a mature DevOps team.
Join the DZone community and get the full member experience.Join For Free
As a consultant (or a new member in a DevOps team), what are your telltale signs of a “DevOps” organization? Share them in comments section. Below are my top five.
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 organization 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.
You may also enjoy: 7 Signs You're Doing DevOps the Right Way
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 minimal 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, etc.
Evidence-Based Over Gutfeel
DevOps teams measure what matters. Their KPIs give insights into various aspects such as code quality, build quality, release quality, NFR’s and various production monitoring metrics. Technology and business decisions are driven by data. For e.g. how did new architecture design changes impact performance? How is the new feature we implemented is being used by our users? When do users use a feature in our application? How does the new code we shipped impact out code quality or security? Things like these are answered by hard facts and not by the gutfeel of the team.
Data-driven decision making is one of the key aspects of DevOps teams and organizations. However, in some instances business might take some decisions such as a new feature implementation based on gutfeel. 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 reflects in their ability to do the right thing, the courage to say "No," the willingness to ask for help, disagreeing respectfully, commit to deliver, and have 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.
Members in a mature DevOps process, teams hold each other to higher standards. As a team, they celebrate each others' successes, which is in turn teams’ success. This promotes a sense of achievement, quality and a great engine of motivation at the workplace.
Fail Fast Over Delayed Learning
Mistakes are mandatory to learn! A team that always plays it safe without exploring uncharted territories, will not often challenge 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 comes 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. 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 share their mistakes and all of us can learn from it.
Do you notice these characteristics in your team/organization? What would you add to this list?
Forget About 'Fail Fast' - Just Fail Well
Published at DZone with permission of Phani Bhushan . See the original article here.
Opinions expressed by DZone contributors are their own.