How To Improve Collaboration with Development and Operations

15.08.2011
IT managers have long bemoaned the tension between "change-the-business" (development) and "run-the-business" (operations) IT teams and their activities. In fact, most organizations suffer this curse, and stereotypes that reflect this animosity abound. Ops people, for example, envision dev people sitting in their ivory towers cranking out code all day and wanting to release applications oblivious to real-world constraints. On the other hand, dev sees ops as cog-turners ensuring that the IT infrastructure doesn't break under the strain of poorly written code. These stereotypes exist because organizational behaviors do exaggerate genuine conflicts, and both parties must act quickly to change.

As IT organizations struggle to deal with the changing IT and business landscapes, the concept of DevOps (i.e. development and operations) has been singled out by many as the way in which infrastructure and operations (I&O) can work more efficiently with other IT silos to benefit the business. More specifically, Forrester defines DevOps as:

A set of processes, methods, and systems for communication, collaboration, and integration among the IT functions responsible for application development, infrastructure and operations, and quality assurance; with the functions working together to produce fit-for-purpose and timely software products and services.

For DevOps to work -- and it must -- I&O teams must accept that 1) the sibling rivalry between app dev and IT ops ultimately hurts the business and 2) IT is now a business expense rather than a business function. While both parties must transform their behaviors, I&O leaders can begin to build a tighter relationship with dev groups by considering the following six actions:

Ops has a reputation for resisting change because everyone -- ops, dev, and the customers themselves -- have come to believe that change is bad. Service failures are often attributed to changes, so if fewer changes are executed, fewer failures will occur. This ridiculous association only tells us that our change management process is flawed, often profoundly.

However, if you can prove the seemingly contradictory goals of discipline and speed, dev professionals will come to respect your ops group as their partner, not an annoying impediment. As noted, many ops groups have change management in place. Ensure that the process is being executed consistently. Any changes performed outside the process should be identified and rectified immediately. Without execution compliance at or very near 100 percent, changes will continue to be risky and dev discontent with ops will persist.

To improve understanding, reduce prejudice, and improve perceptions, IT teams need to get better at communicating successes to the business and to other IT groups. Aim to adapt work practices to ensure greater exposure between IT silos and greater collaboration on new IT initiatives. This collaboration not only helps gain buy-in, but also improves the quality of the solution. App dev to IT ops integration benefits, but so does the business because delivered IT services are far better.

I&O leaders should extend ITIL and IT service management education and training to app dev and enterprise architecture in the context of why it's important to them and to the business service life cycle as a whole. With the 2007 introduction of ITIL v3, the framework is no longer ops-centric. It explicitly accounts for all phases of the service life cycle, including those driven and fulfilled by dev. This isn't intended to be brainwashing, but more of an introduction into modern thinking around IT delivery to meet business needs. The right approach will compel dev to desire a role in ITIL and not feel they're being forced into it.

While a shocking and likely offensive statement from some app dev perspectives, the development of applications is ultimately a subcomponent of the overall IT service. Sitting alongside service design activities, any written code is ultimately part of a more broadly defined IT service that gets delivered to the rightful consumers of that service. I&O execs should therefore build on the aforementioned educational activities to position the somewhat isolated app dev role into a more central service dev role. Instead of isolating dev group members as the narcissistic "them" who look down on "us," embrace this team as partners in providing relevant services to your joint customers. Key service metric monitoring and liberal use of feedback mechanisms will need to be in place to ensure that mindsets, and resulting behaviors, are actually changing.

There are reasons why some of us love to work in app dev and why others gravitate to the logical demands of programming. However, this isn't an excuse for not working together for the good of the business. Senior management needs to ensure that there is a better mix of skills and personality types within IT functional groups. Review people management and development processes and frameworks in conjunction with HR. This will identify issues and gaps in IT people and their knowledge, skills, and development.

Stop repeating the IT-to-business alignment mantra and get on with making IT a crucial business enabler and a valued strategic partner. IT doesn't align with the business; IT is the business! To this point, IT functional groups need to explicitly understand how their work fits in with the broader goals of the business. Start by abandoning the nebulous and ill-conceived alignment and become integrated. Revisiting the original 20-year-old mission statements (if you still have them) will also be an eye opener in terms of how far I&O has evolved in the last two decades. There should be no I&O employees, just employees of and contractors to the business that provide technology-enabled capabilities to the business.

and are senior analysts at Forrester Research, where they serve Infrastructure and Operations Professionals. They will both be speaking at Forrester's upcoming , November 9-10, in Miami, FL.