DevOps Journal

Four Essential Cultural Hacks for DevOps Newbies

So congratulations, somehow you've managed to wangle your way onto one of the many DevOps conferences being held around the world. Why not you might say? DevOps is not only hot it's the approach many enterprises are now exploring as the means to help accelerate the delivery of high quality software.  And with 2014 marking the 5^th year for DevOps, maybe that's double cause for celebration; you're once again hooked on an new exciting trend (well newish) and its tailor made for your organization, right?

Now you're ready to rock and roll; eager to impress your boss, colleagues (and really anyone who cares listen) on how DevOps is the next best thing for IT and the business since sliced bread. And, just like any five year old, you're ready to charm your way into conversations; using funky terms like anti-fragile, anti-patterns, feedback loops, learning from failure, Lean IT, Kanban boards and continuous delivery.

But there's a problem. Back at castle enterprise you hit a brick wall. Perhaps folks will politely listen, but you really suspect that they're just paying lip-service to your fresh-faced ideas. Worse still some of your suggestions are greeted with stony silence or gasps of incredulity, or in extreme cases (and just like many five year olds) you're scolded and admonished for your new found dash. So it's off to the micro-management naughty room or back to putting covers on your TPS reports (ala Office Space) - how dare you question a culture based on "when it's not broken, we don't fix it."

So with your youthful hand firmly slapped for daring to approach the parental enterprise cultural cookie jar, is there really anything you can do to infuse the organization with a DevOps vision?

Perhaps, but it won't be easy. Organizational culture and workforce transformation are major initiatives usually mandated and driven from the very top, meaning there's probably no immediate magic pill. Especially if your enterprise structure is swamped with senior managers whose job titles should really reflect the atmosphere of friction prevailing within the organization - like VP of Insidious Bureaucracy or Senior Director of B.O.G.S. (Blaming the Other Guy and Saving the Day).

But rather than immediately throwing a tantrum, collecting your toys and leaving the organization, what practical steps can you take and what should you avoid when trying to endear the value of DevOps upon the business?

Here are four examples, which like those in early development are based on taking small but important steps:

Speak slowly and take that food out of your mouth - Ok, so you know lots of DevOps, Lean and Agile terms, like Value Stream analysis, cycle times, retrospective and continuous improvement. You might even be bold enough to "Genba walk" your way into another team's processes; pointing out all the wasteful activities and casually proposing some practical improvements. Of course this might be fine if your language and actions represent standard vernacular of the business (e.g. lean manufacturing), or if agile is used in development - but be careful.

Terms like Minimum Viable Product, Failing Fast and Technical Debt might connote something really bad and unpalatable to business users, so my advice is to be prepared moderate all the DevOps jargon by demonstrating value with user-centric stories.

You show me yours and I'll show you mine - we're taught to share our toys at an early age, so why do we crave ownership of the toys in the workplace - toolsets? Sadly, some have been architected that way to singularly support functional silos and technology fiefdoms. Now, however, tools and methods are being designed to support and stimulate cross-functional collaboration and feedback. Like for example modern application performance management, which when established within non-functional testing can help development meet both speed and quality objectives.

Hold some parties and play nice - you don't have to wait for the next DevOps conference to convince like-minded colleagues on the value of DevOps - you can start your own. With a smattering of management sponsorship you can perhaps develop internal mini-conferences or cross-team hacks. Failing that if you work in operations go ahead and crash the next agile stand-up meeting or retrospective. Remember too you'll most likely work in a "multi-cultural" setting, so don't decry any established best practices like ITIL, COBIT, CMMI and balanced scorecard. At best you'll just tick off a number of folks and at worst you'll be on your way to establishing a separate, siloed thought practice - that's an anti-pattern and not what you should be striving for - collaboration and co-existence.

Show off all those awesome gold stars - it's easy to get carried away with impressive sounding metrics like time-to-value and market share, but I'd caution anyone against initially setting your goals too high. A better approach is to look for performance indicators that drive change and incentivise behaviors, especially those that can be shared across teams. These can include metrics to demonstrate service quality (e.g. deployment success rates), service velocity (e.g. deployment frequency/cycle times), and customer value (e.g. response times, lead times and netpromoter scores).

Once you've had some wins don't rest on your laurels. Start tracking immediately to demonstrate the value of DevOps behaviors, tools and processes, never forgetting to share the credit and celebrate any successes, however minor they might be.

Influencing organizational culture is a tough nut to track, but not impossible since it's based on sets of behaviour -- which can be influenced. This may start with small baby steps in collaboration and DevOps style experiments or with executive sponsorship. Never forget, however, that there will be setbacks, so start honing the next "C" word in your DevOps dictionary - Courage!