In attending the 2015 DevOps Enterprise Summit (DOES15) in October, I expected to catch glimpses of key insight from today's top technology organizations in regards to their implementations of DevOps practices. I expected a lot of talk to center around tools, around automation strategies and around tactical and clever use of software. These topics were definitely discussed, but what I found to be arguably the top theme of the entire summit was something different, though not entirely unexpected: Culture. Every speaker whose session I attended—whether the speaker represented a 'unicorn' company, a 'horse', or one at the beginning stages of its DevOps evolution—emphasized the cultural aspect of DevOps, and many sessions focused mostly on this aspect. It was interesting to hear even today's most successful companies discuss culture and their unique approaches toward improving it. In hindsight, this attention to culture and the people/team aspect of DevOps should not have been a surprise for me. Technology today, including the tools of the trade and DevOps technology, has become more advanced and a lot more accessible, at the same time. It is more tangible, with more defined capabilities and measurable benefits. Culture, on the other hand, is more abstract, experienced differently from one role to the next, and more difficult to analyze and evaluate. It is something that every company in the world has, since every company is comprised of people. It is inescapable, whether ignored or consciously tended to. When implemented correctly, it is what drives commercial success, employee happiness, innovation, motivation for change, quality and a company's reputation. When implemented poorly, well, the opposite of each of these can occur: stagnation, lack of satisfaction, attrition, and even going out of business.
I compared this predominant message of culture to my own experiences at previous companies I have worked for. When I applied what I heard at DOES15 to my own experiences, I realized that the "health" of the culture in my work experience at different company environments directly influenced and was reflected in the productivity, business performance and employee satisfaction of those companies. Since I have an "engineering mindset", this realization had me thinking of reproducible steps toward the successful implementation - or fostering - of a culture that enables DevOps. Drawing upon DOES15 and the experiences shared by the enterprises who have successfully adopted DevOps, as well as my own experiences -- here are some takeaways and best practices to consider for implementing a DevOps culture:
1Morph the mindset of people on your project's Development and Operations sides, such that they feel that they are on the same team
This means literally putting them on the same team and having regular meetings with people representing Development and Operations in the same room at the same time. This is easy to implement if using an Agile-like methodology, as Agile promotes planning meetings, retrospectives and daily stand-ups. Give this team a mission : having a shared goal (i.e., a quicker, high-quality release to market) helps foster commonality and the spirit of being one unit. This also means removing biases and using speech that focuses on "we" in lieu of "I," encompassing everyone.
2Communicate, without playing the blame game
Stating that communication is important is a no-brainer. But - if people are consciously or unconsciously defensive in everything they share with the team, for fear of taking blame, then they will always be prepared to protect themselves instead of working together with others to determine root causes and eliminate them. It is a subtle but vital shift of mindset to focus mainly on the work rather than the people behind the work, a shift that often leads to increased team efficiency. Things going wrong should be viewed as opportunities to improve, and this improvement goal should be celebrated as something for which to strive. To do this, teammates should be realistic by removing themselves from the situation or process and looking at the actual data and facts of the current project state. People should consciously (at first) and unconsciously (with repetition) aim to fix the problem, rather than pointing fingers at specific individuals, because no one completely understands the specific intricacies and day-to-day of someone in a different role.
3Examine the whole DevOps process itself
Do not assume the bounds of the process as immutable. As a lightweight example, if you have never taken formal typing lessons and want to become a faster typist, you could start timing yourself and compete against that time. This approach could have you seeing marginal improvement. In comparison, if you took a course instead, and learned a better strategy for typing, your improvement would be much more dramatic. Look at the trends and bottlenecks and learn from them. Spend the time up-front to eliminate the roadblocks instead of doing the same thing over and over and all the while hoping for better results (the definition of insanity). If it hurts, do it more, and do it until it is smoothed out. Oftentimes, smoothing a process out involves making it simpler, such that the process does not get in the way of itself.
4Automate!
This one frequently goes hand-in-hand with the previous point. Time is money, so prioritize work based on what would provide the biggest time/expense improvement. During the above-mentioned examination of the DevOps process, each piece of the process should be scrutinized as to whether it is automatable—more often than not, it is—assuming that it is needed to begin with. Automate as much as possible, using the abundance of industry tools available to software organizations. CloudBees Flow is a great example of such a tool, as it gives organizations the ability to automate everything from developer code check-in to product release, allowing for integration of existing tools, authoring of repeatable workflows and processes, rule-based decisions and checks, notifications, approvals, auditable change tracking, visibility, reporting and more.
5Be transparent
One thing I have learned at other companies is that identifying problems can hurt and make people feel defensive (again, it is important to eliminate blame). Yet, being transparent and encouraging sharing of information to allow visibility for all stakeholders is crucial to drive improvements. This transparency can be captured in metrics to improve upon as a team. Embrace that you can see problems sooner rather than later, as a result of increased transparency. As an added bonus, transparency has a multiplicative effect. This comes in the form of more immediate success from other project teams, who, as a result of metrics-quantified transparency, are now motivated to apply your team's cultural changes in attempts to duplicate the quality of your project's outcome.
6Practice
Rinse and repeat. Implementing these best practices takes time, but each step brings this change of culture closer to second-nature - and that is where the magic really happens. These traits get incorporated into your team's "muscle memory," and team members make decisions and act in the best interest of the team and in the most efficient manner, naturally. All of these cultural steps are commonsensical when you hear them, but practically every software company can stand to improve in some or all of these points. It is something that must be purposefully looked at and cultivated in the never-ending journey to stay relevant, streamlined, and - ultimately - successful.
Want More?
One of our c9d9 episodes has a really good discussion on implementing a DevOps culture, and the key tenants of such a transformation. Check it out here.