Some might call me an armchair football fan. I know all the teams, facts and figures, I’m good at Fantasy Football, but please don’t ask me to play the game! The same could be said about me and DevOps. But, one of the reasons I was asked to champion this topic is that there is a strong desire to change the culture and organization within Axway, so that we can efficiently deliver on our SaaS platform, which requires a strong DevOps presence. So, with that in mind, pass me some shoulder pads (if football means American football to you) or shin pads (if football means soccer to you) and let’s get on the field/pitch!
Are we, Axway, a company where engineering and operations only meet at the board level? DevOps will be just another buzzword if we don’t have the right culture. Cultural change is difficult. To help drive culture change, we need to establish cross-functional teams of development and operations. When you operate, you are risk-averse and are naturally inclined to limit changes to systems. When you develop, you are rewarded for innovation and delivering at speed. It will take time to get dev and ops teams to trust, understand and ultimately have empathy towards each other’s needs. The primary characteristic of a DevOps culture is increased collaboration between the roles of development and operations. Important cultural shifts will need to be made within teams and at an organizational level to support this collaboration.
In order to embrace DevOps, we need to embrace more collaboration and avoid silos between teams. Silos lead to handovers. Take a step back and think about the number of teams (or departments) that must be passed through in order for an idea (business value) to go from someone’s head to be in a customer’s hands. Handover periods and associated documentation are antipatterns to DevOps culture. Handovers and sign-offs discourage people from sharing responsibility and contributes to a culture of blame. A cross-functional team combining the business, development and operations gains speed by eliminating handovers.
When the cross-functional teams deliver to production, they will also “run” the service. This is following the mantra adopted at Amazon: “You build it you run it”. Here, the team will see the day-to-day operation of their software, they’ll be in close contact with the customer and, as a result, the quality of the service improves. In addition, the likelihood of the team producing more automation tools increases, because they will feel the pain of manual delivery. They will want to get their delivery as automated as possible.
Being this close to the product also means that we should hear the end of the mantra, “well, it works on my machine”. Engineering will be directly exposed to the constraints of production, in terms of lifecycle, security, monitoring, SLA, uptime, upgrade, patching, etc. As a result, the environments that are upstream of production environments will also be operating with the production constraints. For example, adopting a docker-based deployment would allow a developer’s laptop to operate in the exact same manner as the production environment.
“In high-performing organizations, everyone within the team shares a common goal—quality, availability, and security aren’t the responsibility of individual departments, but are a part of everyone’s job, every day.” (The Phoenix Project)
Let’s face facts – it would be hard in an organization where no one has previously experienced continuous collaboration between groups. Change needs to be hands-on, so that people learn and behaviors change. As Jonathan Becher, SAP Chief Digital Officer, points out, it is better first try things ourselves, rather than go outside to consultants. Yes, this may take longer and be less successful initially, but the key thing is we learn and can improve.
In order to change behavioral patterns, there must be buy-in from our leadership. The next step is to pay attention to aligning the organization around key goals and principles associated with the change. Many organizations that have successfully adopted DevOps have introduced Objective Key Results (OKR). OKR is a popular technique for setting and communicating goals and results in organizations. Its main goal is to connect company, team and personal objectives to measurable results, making people move together in right direction. OKR has been adopted by Google, Twitter, LinkedIn, Dropbox and Oracle. OKR has two components: the Objective (What we want to achieve?) and a set of Key Results (How do we know if we are getting there?). OKRs are short-lived and normally defined per quarter, in order to enable dynamic planning and faster adaptation to change. When you looked at an Annual Performance Appraisal sheet recently, how relevant was it to the last 6 months of the year?
Organizations often fail to adopt a DevOps culture because they are too busy operating with their current process and practices. If we are truly an organization which wants to constantly improve, then we should be taking a step back and looking to see if we can start by taking small steps forward, in adopting a DevOps culture.
A company’s culture will trump any process changes, architectural changes, or organizational changes. If you’ve listened to any talks on microservices, you will no doubt have heard about “Conway’s Law”, which states that “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” So, even if we adopt agile process, we have microservice architecture, and attempt to organize appropriately, we will still produce a system based on our communicational structure, which is defined by the culture.
We need to be cognizant and proud of our heritage. We need to realize that this heritage will be driving a lot of our current behaviors. In order to make effective change, we must first recognize what needs to be changed. If we get the culture right, then anything is possible! Culture isn’t something that you build by talking about it or writing blogs ;-). Culture is like quality. You don’t build culture, or quality, by talking about it. You build it by doing things, by acting, by making things happen and making things change, and reinforcing these actions patiently and continually over time, all the time evolving it and improving to meet our needs.
Stay tuned for my next blog about Automation. And, if you missed my intro blog to this series, you can find it HERE.
Follow us on social