DEVOPSdigest

As with anything new (or relatively new) as is the case with DevOps, enterprises are clamoring to embrace it. Why not you might say? With surveys showing impressive results and business sounding benefits, analysts giving it their blessing, and vendors touting their wares, this newest best practice is at the top of the new year’s enterprise shopping list – the top “must do” item on the 2015 list of must do’s.

But like shoppers who dive feet first into a holiday or clearance sale looking for a great deal, enterprises should think carefully about what they’re actually investing in. Sure, DevOps is a great way to accelerate all the benefits from digital transformation, but there are also many pitfalls, hurdles and gotchas that could quickly turn your DevOps business “bargain” into yet another IT white elephant.

Here are just a few to chew over as you look to take the wrapping off and open up the DevOps gift to your enterprise:

Dogma and best practice paralysis

DevOps isn’t the first movement to hit the enterprise. Think ITIL, PRINCE2, Agile, and it’s just the next in line of what’s been a steady stream of best practices working their way into enterprise IT. Now, and just like in the past, the current ‘purists’ view of what came before is that they’re rigid, inefficient and just out of touch with reality. This might be true of course, when each best practice is considered some kind of “holy shrine” that cannot be modified (I’ve seen this a lot with ITIL).

Any movement (including DevOps) can quickly become rigid and bureaucratic if dogma replaces practicality, so always consider adopting (and adapting) those elements that’ll work best in your enterprise and have the courage to discard the “noise”.

Slave to the name syndrome

Would you get sucked into (forgive the pun) buying a vacuum cleaner if it was called a cyclonic extraction device? Sure you would, and you’d probably pay a premium price for it. However, unlike those clever marketers in the home appliance game, IT often sucks at selling business value to the enterprise. Too often we become slaves to a name, throwing in technical sounding terms like anti-fragility and feedback loops -- all in the hope that our business stakeholders get where we’re coming from.

In my experience and from working with my clients, many real DevOps practitioners demonstrate the value in clear, unambiguous business terms without being fixated on the name. Indeed, many high performance IT teams go further and don’t even call it DevOps; concentrating instead on showing how highly collaborative teams are the catalyst for what really turns business on – time to value and improved customer engagement.

Fire … aim … ready, now where’s the target?

Ok, so you’re organization has bought into DevOps. Now you’re ready to apply all the great principles and perhaps even retool your teams. Great, but before diving feet first into murky waters, my advice is to take a step back and survey the landscape. This starts by reviewing your software lifecycle end-to-end; pinpointing each element that contributes to technical debt or waste and why it occurs. This can include exposing plain old bad habits like incentivizing developers for quantity over quality (function points or lines of code produced), or identifying manual and error prone practices that result in release bottlenecks.

Remember too that technical debt doesn’t just start with development and flow through to operations. It can originate in ops, where for example poor insights into capacity and performance can compromise development efforts, or worse still the profitability of a project due to acquiring additional computing when it isn’t needed.

Cultural tap dancing

Your organization might have embarked upon some ambitious workforce transformation program to improve cross-team communication, but is it really working? Perhaps if it’s mandated by the CIO, but in my experience any cultural change initiative lacks bite unless supported by proactive methods to ensure teams collaborate towards supporting common business goals (e.g. more frequent and reliable deployments).

This could be as simple as encouraging operations and security staffers to attend stand-up meetings and retrospectives, or dictating that the organization is aligned in such a way as to match the technology architecture of the software applications you are looking to develop. So, if for example you’re embarking on a critical API strategy, the new architecture and management becomes the catalyst for improved interaction across previously silo’d teams.

Green lights spell danger

in terms of measuring DevOps performance, traditional inwardly looking IT-vanity metrics are generally a no, no. With DevOps’ overarching focus on business value, metrics should at a minimum be developed to gauge velocity, productivity and quality. These can include deployment frequency, defect rates and compliance successes, but don’t get caught up with impressive sounding metrics that are never actionable. In this context, red lights are perfectly acceptable, providing your automated tool chain can quickly drive improvements.

Remember too that the mobile and API driven nature of service delivery will bring into play a new set of customer-centric variables (e.g. how and when app functionality is being used), which when analytically exposed will prove invaluable in directing development efforts – sort of like DevOps feedback loops, only on steroids.

As we move into the New Year, make sure your resolution to adopt DevOps is baked in practicality and a hype free assessment of how it can and should work for your business. There are many pitfalls lurking in blind spots, so be prepared to anticipate anything that can quickly derail your efforts.