DevOps is generally recognized as a means of driving better business outcomes via improvements in process, tools, and culture within the IT organization.  Process is immediately recognizable - it's the way you're doing business today, and everyone involved can probably identify at least a couple of tweaks they believe would improve the process overall.  Tooling is a bit more difficult, as to do it right you need to invest in tools which support your workflows, and if your process is broken or less than ideal today then selecting the right tool becomes much more complicated - the conventional wisdom is to first optimize your process and workflows, and then to select the right tool for the job.  The third aspect, however, is much harder to nail down.  "Culture" is nebulous and seemingly ephemeral, as it consists of a lot of touchy-feely sentiments which tend to be at odds with how engineers have trained themselves to think - rationally and logically.

I strongly suspect that this incongruity is why DevOps advocates for culture improvements in the first place.  Perhaps what is at the heart of this matter, so far left unsaid, is that while the work performed in IT must be logically executed, engineers must acknowledge that the interactions along the software value chain occur between humans, and thus must incorporate humanistic elements like patience and empathy in order to achieve the desired improvements.  Patience to understand, empathy to care...

That all starts to get a bit "meta," so instead of continuing to dwell on the finer aspects of DevOps philosophy, I'll move on to the real point of this article, which is to provide 10 tips to help in effecting the transformation towards a DevOps culture, inspired by an article Helen Beal wrote recently (see article here):

Trust
Trust sucks. All trusting does is leave you vulnerable to neglect or attack. Distrusting people and their motivations gives us the feeling that we're in control of both ourselves and the situation. But, unfortunately this is only an illusion. The reality is, even though it sucks, trust is a critical ingredient for any team who wants to be successful, whether that's a marriage, sports team, military unit... or the IT department. Over the decades cultural silos have been built around development and operations, signified by a distinct lack of trust in the other. DevOps requires a unified culture, so building trust between these two organizations is necessary. Organizing teams around projects, rather than tasks, can help to start building that trust, as well as both factions agreeing to a common set of goals and objectives.

Understand the motivations of others
Understanding another's motivations addresses the "why" of his or her actions. This is why we're all so fascinated by the back stories of our favorite comic book and sci-fi heroes. Take Batman for example. We know that his love for Gotham stems from his parents' philanthropy and activism. We know that his fascination with the criminal mind was sparked by the traumatic experience of witnessing his parents' murder. We know that his fear of bats stems from another traumatic childhood experience. We know that his particular brand of vigilantism, which often gets him branded as some kind of "freak," is because Batman couldn't seem to turn around as a kid without some new traumatic experience befalling him.

Understanding a co-worker's back story, or another's current work situation, or the internal politics that are at play in the organization, helps us to understand why individuals arrive at the positions they do. Learning more about our own internal lives helps us understand why we ourselves arrive at the positions we do.

Remove blame
Blame destroys trust. Refer to #1. Removing blame from postmortems allows us to remove the personal element and instead focus on improving the overall process.

Accept the risk for failure
I used to be a driver's education instructor for defensive driving skills clinics. We ran a really cool skid-pad exercise, wherein as instructors we deliberately caused a driver's vehicle to spin out of control to teach skid- and spin-correction techniques. The core theory behind this exercise is that you can't understand the limits of any given system until you push that system beyond its limits. The same is so in software - in order to innovate, you must be willing to accept some risk that a new innovation will fail. What's critical to allowing for experimentation is to fully understand the risks ahead of time, enact controls for those risks, and to have a plan in place to quickly recover in the event of a disaster.

Understand how value flows and where your bottlenecks are
Take the view that your release process is a software value chain, or one unified process, as opposed to a collection of different individual tasks. Once this is mapped out, identify where the constraints are in your system, and look to elevate those constraints so they don't restrict the flow of value. This aspect of DevOps is heavily grounded in the Theory of Constraints, as described by Eliyahu M. Goldratt in The Goal, and Gene Kim in The Phoenix Project.

Remove unplanned work
This is also heavily borrowed from The Goal and The Phoenix Project. Unplanned work comes from amassing technical debt in IT. Firefighting, remediation, regression bugs - these are all examples of unplanned work. DevOps advocates building visibility and reliability into our processes to eliminate as much unplanned work as possible, which frees up time for innovation.

Do everything continuously
Continuous Integration, automated testing, Continuous Delivery. Everything in the software value chain needs to be set up so that you can deliver software at will. This enables the business to strike while the iron is hot on fleeting market opportunities.

Embrace cross-functional teams
During my career as an Army officer, I served as a Fire Support Officer to several combat units. Essentially, the Army "loans" out artillery officers to serve as advisors and liaisons to combat units, for the purpose of integrating indirect fires into the ground unit's plan. This role is described as a "combat multiplier," as it greatly enhances the ground unit's ability to perform its mission. In order to do my job well, I had to have intimate understanding of how ground units fight. To gain this understanding, I volunteered to take on planning and operations work outside the scope of my role, so that I could learn how to think, and fight, like a cavalryman, rifleman, or tanker. This not only made me better at my job, but benefited the unit because my indirect fire plans were more tightly integrated with the maneuver plan. This is what it means to be cross-functional. This is why DevOps advocates for collaboration between development and operations, so that each gains a better understanding of the other's role, and subsequently both can support the business better.

Be transparent
Cross-functional also implies cross-training. Cross-training in skills, tools, systems and processes ensures that no one person in your organization becomes a bottleneck. It provides transparency to your process, because people have a better understanding of how things should work at each stage of the delivery process.

Align incentives to enable self-actualization
Research on work motivations has shown that employees value "autonomy, mastery, and purpose" above other economic incentives in the work place. IT professionals, like everyone else, want to feel valued for their skills and opinions, desire to be heard, and want confidence in the knowledge that they can effect change to better the organization. These qualities enable self-actualization, the pinnacle of Maslow's hierarchy of needs. A work environment that enables self-actualization will breed innovation and success.

• Ted's 'Top 10 Tips' for Traveling with Kids During the Holidays
• GridApp Systems and BEZ Systems Present "10 Tips for Successful Oracle RAC Management"
• Travelzoo Reveals Top 10 Tips for Finding the Best Family Cruise Deals