Alan Shimel of DevOps.com recently sat down with Sam Guckenheimer of Microsoft for an interview on the seven habits of successful DevOps. Below is an overview. Check out the full podcast here.

1. Team Autonomy and Enterprise Alignment
   Scrum teams should autonomously pull items from a common product backlog, and at the same time, align to enterprise goals on a six month planning cycle. In that time frame it should be clear what needles you’re trying to move for the business. You can then measure, how you’re doing against that. They may move forward, they may move backward, they may decide, based on the data they’re collecting to do more or do something else. But you know, what’s in their control based on the things they’ve agreed for the six months.
2. Rigorous Management of Technical Debt
   When you’re running a service, you really can’t afford to let any debt creep in, and you have to stay clean all the time. To do that, you must constantly monitor both what’s happening in the production service and what’s happening in the development process. So for example, if there’s anything happening in the development process, like a feature crew is letting its bug count start to ride up, they have to stop immediately, fix the bugs, and you can’t do any new work until they get them down to zero, so that you remain clean on tech debt as you’re go.
3. Focus on the Flow of Customer Value
   Look at how people use your software, both quantitatively; that is – actually observe what gets used, what doesn’t get used, what the scenarios are – and reach out to customers qualitatively; engage with the high usage accounts and encourage your engineers to buddy up and find out what’s gone well, what’s gone not so well and what they would like you to do. 
   
   Download our latest white paper: Pitfalls to avoid while evaluating DevOps for database solutions.
4. Hypothesis Driven Development
   The backlog is a set of hypotheses or beliefs. The hypotheses must be turned into experiments, and you have to collect data against those experiments so that you can substantiate or diminish the hypothesis.
5. Evidence Gathered in Production
   Everything is evidence that is needed in order to build up or draw down against those hypotheses. You can use instrumentation and telemetry and measure it against what’s important. So, for example, run the new against the old in parallel, and see what the evidence shows you about how much better the new is than the old – if indeed it is at all.
6. Live Site Culture
   The idea of a live site culture is that the site status is always first priority. If there is a live site incident, you want to, as quickly as possible, remediate so that customers aren’t affected, and you want to drive to a root cause analysis. Getting to the root cause allows you to identify the actions that you need to take in order to prevent a recurrence of such an incident or something similar. Learn from live site incidents so that you’re always getting better.
7. Manage Infrastructure as a Flexible Resource
   Start each Sprintly deployment with a canary instance, so that you know from the canary if there’s anything wrong with the deployment, and if there is, you can then restart at the canary before you roll out to the subsequent deployment rings. This practice of canary-ing, is part of the deployment pipeline. You can then use the automation to roll out in subsequent rings in order to harden the service and get to a global scale on a regular basis.