Senior Application Development Manager, Dave Harrison, gives us his perspective on how DevOps can round out your application lifecycle management (ALM) process by bringing together developers and operations teams to simplify and streamline deployment and production support.

A few years ago I remember leaning back in my office chair and feeling very smug. My .NET development team had just killed themselves producing an entire footwear website in just under a month. Now I could kick back and relax, basking in the accolades of my business partners and the envy of my colleagues.

Things did not go as planned, however – two months later we were still trying to get it out the door to production. Operations was taking months to spin up VMs, and there were all kinds of issues in getting development code deployed out to production and have it work consistently. What had gone wrong?

Without knowing it, I was stumbling up against a major shortcoming of ALM. Ken Schwaber said the purpose of Agile was to produce potentially releasable software as quickly as possible. But what does that mean exactly? Without having those bits out the door in production – in the eyes of my customers, we weren’t really “done”. As a manager, I had failed to treat Operations and infrastructure as equal partners in the process – and we missed an opportunity that cost the business valuable time to market.

DevOps means replacing what WAS a vicious, nasty cycle of recriminations and backbiting with a virtuous cycle. As developers work closely with IT early on, stability improves. As stability improves, IT performance improves, and you start getting some meaningful feedback and metrics to prime your backlog. As one architect said, DevOps is not about developers and IT operations “hugging each other” – it’s pragmatic, focusing on getting as much feedback as possible so you are delivering real value.

For business and metrics-focused people out there who want to see the real business value behind DevOps, the statistics below (from a recent survey in 2013) say it all:

*2014 State of DevOps Report available here

So here’s some thoughts on how to make your journey to DevOps as smooth as possible:

Go slow to go fast. Recognize IT as an investment, and secure management support as a precursor. Start small and grow – gather data, and iterate. Gauge user response, collect metrics on things like MTTR/MTTD, and rinse and repeat.

Encourage experimentation. Propose a change and promise to reevaluate in six months or some other time limit. Make postmortems blameless. Practice root cause analysis (think of the “Five why’s”), and keep a detailed log of events without fear of punishment. Don’t level personal criticism at anyone, and don’t take feedback personally. Managers, it’s up to you to create a culture where it’s safe to fail.

Choose your tools wisely. Everyone seems to drill into tooling almost immediately –there’s a variety of RM and infrastructure tooling out there, and each have pros and cons. Whatever you do, make sure the entire group has input on the tool of choice so you have their buy-in. You’ll want an integrated toolset based on loosely coupled platforms – one that can automate all those formerly painful manual steps, and where you can provide visibility and transparency through application monitoring. My personal take – any of the tools out there will likely meet most if not all of your needs. The biggest obstacle you’ll face has to do with people and process – changing culture. Which brings us to…

Take that Ops handshake seriously. We need to think as developers about how Operations will monitor and support the software we produce. (As one architect said, “Ops needs to be more involved in the beginning of the project – and Devs need to care more about the outcome!”) And pay attention to the little things – keep your promises, foster open communication. I have seen in multiple war rooms good and bad examples of how to act when things go wrong. If you behave predictably and calmly when the wheels come off, your Ops team will begin to take your words of partnership seriously.

Don’t go it alone. Incubate your DevOps movement with a Center of Excellence. Fold in your business analyst and business owner, and track metrics. Hold seminars or DevOps awareness brownbags. For more on this and facing challenging cultures, please see the Phoenix Project book by Gene Kim, and the book Continuous Delivery by Jez Humble.

Microsoft Premier to the Rescue! If you’re having trouble being taken seriously, think about bringing in some help. I worked at one organization for several years as a development lead and became very frustrated at our slow rate of adoption of ALM and DevOps. Once we brought in some Microsoft resources, they were able to hold workshops and chart out a clear path for us that was reasonable in scope and fit our business and cultural background. Within 18 months, you wouldn’t have recognized the changes in the development teams – we had an integrated set of tools and processes that the developers loved, and got our releases out the door much more quickly to the delight of our customers. Having that independent third voice in the room really made all the difference for us in getting our dev maturity level off the ground.

Good luck!

Contact us to learn more about how Premier Support for Developers can help you.