A rock singer once sang that love is a battlefield. As it turns out, so is IT and the need for companies to speed new technology to market. It’s a battlefield.
That’s the metaphor used by Cognitect VP Michael Nygard uses to describe tactics to meld between developers and operations staff in today’s IT shop. In an interesting Q&A with opensource.com’s Bryan Behrenshausen, Nygard previewed his talk, “Temp, Maneuverability and Initiative,” in advance of the DevOps Enterprise Summit.
Go here to read all his comments, but it was Nygard’s battlefield comparison that caught my eye and is instructive in understanding why DevOps is so critical to driving culture change in today’s IT environment.
Nygard talks about the “tempo” of DevOps transformation, not in a musical sense but in the military sense, where tempo “refers to the pace at which an engagement changes.”
“With evenly matched forces, the one [army] that operates at a higher tempo will be the one with initiative. That means they make actions and force their enemy into a reactive posture. The side that controls tempo will be able to force their opponent to accept unfavorable terrain or positioning.
Both senses of ‘tempo’ apply in the commercial setting. Some companies set the pace that others must follow. Some companies take initiative and make movements to which their competitors must respond.
To increase military tempo, it is not just a matter of buying faster trucks and tanks. It is also a matter of training and mindset. Soldiers on the line and their commanders understand the need to cooperate across functional areas for the success of the overall mission.”
Cooperation in the interest of initiative and organizational momentum. That’s what DevOps, through enabling tools and cultural change, is all about.
Ingredients for DevOps Success
DevOps guru Gene Kim summarized a recent livechat among DevOps leaders from DOES16 into a nifty 12-point tip sheet for how to know a DevOps transition is succeeding at your company.
Here’s a link to the whole thing, but we distilled the list for your clip-and-save convenience. The question: What observed pattern has led to “radically improved outcomes?” The responses, paraphrased, are definitely worth contemplating:
1. Collaboration: Ops and dev folks working problems on the same team.
2. A Customer Service Mentality: Ops folks behaving as if developers and the organization are their customers.
3. Horizontal Thinking: More talk about the “value stream,” from business concept to delivery.
4. Less time spent waiting: Engineers not waiting around on each other.
5. Fast feedback: Quick assessment and improvement on work products.
6. Relationships: People actually know each other across departments.
7. No zero-sum thinking: Developers and operations are “breathren in arms” who root for each others’ success.
8. Personal responsibility: Developers are doing their own tests, deployments and supporting their own apps in production.
9. Shifting left: Not waiting until the end of the SDLP to check security, performance, availability and other critical qualities.
10. Transparency: Staff in charge of security, compliance and legal are invited to weekly demos to gather advice earlier.
11. Automation: Automated build process and continuous integration helps instill the concept of continuous improvement.
12. Beyond tools: Not simply going out and buying DevOps but actually changing the way you work.
DevOps as a Lighthouse
Over at Forbes.com, Jason Bloomberg continues a series of interviews with top DevOps influencers (he already featured Gene Kim and Jez Humble) with an interesting piece on John Willis.
Willis, the director of ecosystem development at Docker and employee No. 9 at Chef, is among the four who wrote the recently published DevOps Handbook. The book was a five-year project among Kim, Humble, Willis and Patrick Dubois. Willis says the project was about bridging huge chasms between IT silos.
“People in operations have been lost at sea for many years,” Willis told Bloomberg. “DevOps is the lighthouse that’s bringing them in.”
Check out the piece for more on how Willis arrived at his place in the DevOps movement.