As a consultant (or a new member in a DevOps team), what are your telltale signs of a “DevOps” organization? Do share them in the comments section. Below are my top 5 characteristics of a DevOps organization.

Product based teams over component teams

Autonomous and cross skilled teams are key to deliver and maintain products. An organization structure which is based on knowledge silos (such as dev, QA, ops) is bound to create multiple handovers 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.

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 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 ruthless 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, end user training etc. might still require some manual effort but this should be kept to minimal or look for ways to automate. E.g. to get early feedback from the customer, DevOps teams can use techniques such as canary releases, feature toggle, A/B testing, dark launches etc.

Evidence-based over gut feel

DevOps teams measure what matters. Their KPI’s 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 example, 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 have impact on the code quality or security? Things like these are answered by hard facts and not by 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 gut feel. I rather like to call it assumptions or a hypothesis that a certain feature will make users happier or make them more effective etc. etc. However, their decisions, which are based on a certain hypothesis, need to be validated with data either after a release or preferably before that.

Teamwork over individual work

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

Members in mature DevOps teams hold each other to higher standards. As a team they celebrate each other successes which is in term the teams’ success. This promotes a sense of achievement, quality and a great engine of motivation at your workplace.

Fail fast over delayed learning

Mistakes are mandatory to learn! A team which always plays safe without exploring uncharted territories, will not often challenge the status quo. Mature DevOps teams/organization perform blameless postmortems to get learning from mistakes. Often, these local learnings could be transformed into organizational wide learnings.

Fail 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, high-level of automation comes into the picture. 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/mistakes”. Every monthly all-hands meeting, employees share their biggest mistake/failure of the month. 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 thereby all of us can learn from it.

 

Do you want to learn more about DevOps? Register for our Certified DevOps Foundation training

Previous articleHow to tackle GDPR on your DevOps journey
Next articleGetting the foundations right!
mm
Hi, I’m Phani Bhushan. I work as a Technical Consultant and a Scrum.org trainer at DevOn, helping organizations to make the transition to the Agile way of working. I personally believe that successful software development starts with good collaboration between business and IT people. Success starts with people who are willing to cooperate with other professions. Indeed, individuals and interactions. Agile methods like Scrum help people to understand each other’s challenges and figure out how they can help one another in order to come up with winning solutions. As a Scrum.org trainer, I teach the Professional Scrum Master and the Professional Scrum Product Owner classes. I’m a technologist at heart, I’m passionate about Continuous Delivery, DevOps, automated testing and Application Lifecycle Management. I love to help organizations implementing Continuous Delivery practices such as: Infrastructure automation, DevOps, deployment pipelines etc.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

*