This is in response to an article by Klint Finley (@klintron):Devs vs. Ops: Sushi vs. Meat and Potatoes.
“J. Wolfgang Goerlich … led his IT ops team to adopt agile operations practices before the Dev team adopted agile development practices.”
My DevOps story is a bit of an exception, stemming from a two year lead up to the team integration.
My organization first made the shift from traditional IT to highly virtualized and highly automated IT. From there, we made the shift to private Infrastructure-as-a-Service IT. The transition entailed high degree of infrastructure rationalization. This put tremendous strain on the network operations staff. We could not take a waterfall project approach to implementing these changes.
From 2008 to 2010, the team became good at agile. We got good at change, and continuous change, and repeatable change, and seamless non-impact change. We changed things daily. On a good day, the community noticed and appreciated the change. On a typical day, the change went unnoticed. On a bad day, the change broke something. And we learned how to quickly and quietly recover and fix things. It was very much a DevOps success story without the Dev.
We addressed that in mid-2010 when the application development folks joined our team. Their organization was still very much projected and followed the standard waterfall model. Cycle times were long and rework was high. Technical debt was also high, stemming from ten years of ad hoc projects in a variety of languages and on a variety of systems. We integrated the two teams and began a process of software rationalization.
“Are there any less obvious solutions to the Dev/Ops divide?”
A successful DevOps team works from the same playbook, has a shared understanding of the system, and is measured by the same metrics.
A core component of this is cross training. Developers, who have been very successful at adding functionality, need to step up their game on providing operational excellence. Operations, who have been very successful at up-time and response, need to step up on providing a service to the organization. My team regularly holds knowledge sharing meetings where a person explains their latest work in terms of the impact to the business and the requirements from the system.
The next integration point is support. My team integrated support on the front-end through one telephone support hotline, and one support email address, and one ticketing system. One person from development and one person from operations are on-call at all times. This creates a partnership when responding to incidents and implementing new functionality.
To complement these integration points, a single set of metrics are applied to both development and operations. The metrics track features delivered, rework, and up-time. This encourages development to adopt rugged techniques. (See the Rugged Software Manifesto, which perfectly captures our mentality towards new code.) The metrics also encourages network operations to deliver new features via configuring existing software.
In the end, our “one team, one system” approach addressed the divide by improving the team’s shared skill-set and by measuring both specialties with a common set of metrics.
Posted by