At Dealertrack, we believe that DevOps is a culture built around the idea that we are all responsible for delivering high-quality value to the customer as rapidly and iteratively as possible. No matter what your role, you must be focused on how the products and solutions you create are going to make their way to the customer and continue to deliver value every day.
8 Traits, 3 practices for a Delivery Culture
As we’ve embraced DevOps in the Dealer.com division of Dealertrack, we’ve found it so important to our success that we’ve worked to distill the things that go into creating a DevOps-based “Delivery Culture.” I have been developing some of these thoughts in presentations at New Relic User Groups, road shows, and FutureStack15 (watch the video at the bottom of this post), and I’d like to use this blog post to lay out the eight traits that we believe characterize a delivery culture—along with the three practices that we have naturally found to support those traits.
The traits are not a mission statement that someone wrote down long ago and we have been indoctrinated into. They are the results of observing dozens of talented engineers and leaders who have worked in our organization over the years. Many of these individuals enacted ideas and practices consistent with DevOps and Continuous Delivery long before those terms became popular. And we have found that these traits form the basis of a feedback loop, which is foundational to our continuous improvement.
Let’s take a look at the eight traits we have observed over time:
- Coding: This means that teams are empowered to quickly make changes to code with confidence. New developers get started fast and contribute value almost immediately, and other developers can quickly understand and contribute to the code base. Code should be seen as a tool to wield, not an impediment.
- Building: Teams continually integrate, build, test, and produce deployable packages iteratively without friction. Teams leverage environments and tools to accelerate the demoing of new ideas to stakeholders as they are developed.
- Testing: Teams engage quality with a positive attitude, and do not feel producing quality work is at odds with delivering quickly. Teams do not fear large changes to the system and see proper testing as a viable way to mitigate those risks.
- Shipping: Teams use shipping to enable learning, run experiments, and deliver value. Shipping does not have to imply releasing, and can be done with minimal friction. Shipping is seen as a tool that can be used to realize business value, not as a burden.
- Discovering: Teams are knowledgeable about and equipped to study how their applications operate and deliver value in production. They remove friction that would make it difficult to discover where and how well the applications perform.
- Monitoring: Teams actively define the performance KPIs—both operational and business—of their application and employ tools to actively detect when their applications fail to meet those criteria.
- Fortifying: Teams take ultimate responsibility for the success of their work by supporting and operating their applications in production. They actively learn how to produce more stable and flexible applications by observing and experiencing failures.
- Communicating: Teams actively make regular and frequent time, as much as an hour every week, solely for the purpose of learning, reflecting, and deciding how they will change, improve, and grow as a group. They choose tools that foster communication and visibility in every action that contributes to delivery. They share information and learning so that everyone builds like-mindedness about what techniques and practices lead to success in their environment.
Measuring the traits
We evaluate these traits using a maturity model survey, measuring each trait on a scale of 1-10 to provide the basis of a discussion with leadership and teams around each trait. We use narratives to describe qualitative feelings and sentiment about a team’s environment for each trait, providing a gauge to measure by.
The hope is that periodically we are able to measure our growth in each of the traits, and refocus our efforts to improve each area. This both helps focus our efforts internally as well as create a compelling story to dedicate additional priority and people to our growth and improvement.
Of course, these traits don’t come into being by accident. Organizations need to support them with concrete actions. We’ve found these three practices to be critical:
- Eliminating waste with DevOps. Coding, Building, Testing, and Shipping are all fundamental activities every development team does over and over again. DevOps automation practices eliminate waste and improve the reliability of the process. This isn’t just a checkbox to tick off; it requires input from the feedback loop to tailor these workflows to your business needs, which continue to evolve.
- Ownership and responsibility through the practice of “Team on Call.” The idea here is that everyone takes responsibility for a user story from inception to deployment to feedback in production. That means “It’s Done When It’s in Production”—and it’s working and not exploding. In practice, taking ownership of the quality of our work means being willing to take responsibility for it failing. Driving down failure rates becomes a matter of pride in ownership. Seeing and operating the software you build in production serves as valuable input into the design and delivery feedback loop, continually improving our craft.
- Continuous learning via ongoing roundtables and retrospectives. Roundtable sessions may take an educational format, be set up as a work session/team discussion, or surface in other forms as needed. Retrospectives aren’t just for scrum teams after a sprint. Regular, standing retrospective meetings on processes, such as releases, offer an opportunity to evaluate, internalize, iterate, and improve our ability to deliver, and for product architects to communicate their vision. This gives us the opportunity to reflect, evaluate, and consume the information coming in each feedback loop. From there we can steer and improve our practices and quality.
As New Relic users for some three years, our philosophy is to “Monitor all the things.” If it moves, monitor it. If it matters, alert on it (Hat tip: Etsy CodeAsCraft). Do that and your developers—who understandably don’t like getting woken up at 3 a.m.—will be influenced to make choices that make those middle-of-the-night incidents less likely. And with New Relic, if they do get woken up, they are more likely to have the info needed to deal with the problem.
Watch the FutureStack15 presentation “Engineering Culture, Delivery, and DevOps” in the video below: