DevOps is a human problem and a leadership problem. Building a DevOps culture requires more than giving developers root, installing a configuration management tool, using a source code repository, and proclaiming ‘yes, we’re a DevOps shop.” At the end of the day all aspects of the people, process, technology continuums get impacted by DevOps. However, there is little doubt that the people aspect has the most to gain (and the biggest challenges) for anyone who is considering, or already on, the journey to becoming a DevOps ninja.
Patrick Lencioni's The Five Dysfunctions of a Team - A Leadership Fable is an outstanding business book that uses a model of 5 dysfunctions of a team that affect team performance. I find these concepts universally applicable and very relevant to the DevOps movement. This is the first in a series of posts around DevOps culture and lessons learned from Lencioni’s leadership book.
Absence of Trust
"The first dysfunction is an absence of trust among team members. Essentially, this stems from their unwillingness to be vulnerable within the group. Team members who are not genuinely open with one another about their mistakes and weaknesses make it impossible to build a foundation for trust."
If DevOps is about culture and collaboration, then the most important cultural ingredient a team must establish and cultivate is trust. As per Lencioni, members of trusting teams admit their weaknesses and mistakes, ask for help, accept questions and inputs about their areas of responsibilities, give one another the benefit of the doubt before arriving at a negative conclusion, take risks in offering feedback and assistance, appreciate and tap into one another's skills and experiences, focus time and energy on important issues and not politics, offer and accept apologies without hesitation and look forward to meetings and other opportunities to work as a group.
Does this sound like the way your daily interactions go between ops, dev, QA, EA and security? If so, then congratulations! But in reality the finger pointing and IT blame game between individuals, departments and business units can be suffocating. So how can we break through to establish the trust necessary? These sorts of changes don’t happen overnight, but here are a few ideas for how to begin to establish trust across your team:
1. Align Dev and Ops in a Way that Prevents Local Optimization
Putting developers on call for their own software can help shift ops from being the people that just deal with all the problems to people that become experts on all the services that allow the software to run. There will be pain and frustration, but is essential to establishing trust across your most prized resources.
2. Start with a Small Motivated Team and Build Some Success
There is a strong tendency we’ve seen for organizations to try and boil the ocean when trying to adopt DevOps principles. In order to make this transformation, you have to make the experiment of changing things safe. Don’t even use the word DevOps, just focus on the problems and get permission to start to change it. Consider investing in in-person or remote team building activities.
3. Make Your Boss a Champion
It should go without saying that in order to establish trust you must be sure that your boss can explain what you are doing and why or at least be able to provide air cover for you.
4. Get as Many Metrics as You Can
John Allspaw talks about things like MTTR, mean time to recover. Also, make sure that you are good at telling your story with the data that you capture. Here is a great TED talk about how to use data to tell a great story.
5. Celebrate Your Success
If your DevOps experiment is the best kept secret in the office, then shame on you. Not only is it important to celebrate your early wins for the morale of the team, but celebrating the changes that you’re bringing about allows everyone involved to take a moment to reflect on the progress being made.
Conclusion
Quality of teamwork is impacted by various factors such as motivation levels of individual team members, levels of trust among team members, clarity of purpose, understanding of the business goals, lack of resources, poor communication among the team members, and so on. Thus, it comes as no surprise that appropriate investments must be made to make your DevOps team click. However, most often, team dysfunctions affect a team's performance at a higher rate than the ability of any state of art processes or tools. Most IT leaders lack the ability to detect such deeper sociological clues, thus are unable to deal with its impact. Remember, "any improvement not made at the constraint is an illusion" (source: The Phoenix Project).
