Collaboration (or lack thereof) between IT teams

DevOps is an idea / philosophy that has been gaining mainstream adoption over the last two to three years. As you might have guessed from the name it relates to bringing together development and operational teams. In reality it's not just limited to Dev and Ops, more generally it's about methods, processes and tools to enable IT teams to work more collaboratively with each other and other parts of the business (at least that's my take on it).

In many organisations there is seemingly a conflict in the goals and objectives of development and operational teams. Development teams usually have goals relating to the development of new features on time and to budget. The operational teams, especially those that deal with infrastructure are more focused on ensuring the availability and manageability of systems.

Operational teams sometimes distrust the developers believing that they just want to push out changes as fast as possible to meet their deadlines and don't adequately test their changes. They are weary of any proposed changes and therefore can be reluctant to approve or support them and may even seek to endlessly raise queries about the changes. They may feel that changes are thrust upon them and that they are not consulted on the best way to achieve a particular goal or that they don't have the necessary tools to support the changes to the system or the financial backing to procure those tools.

Development teams on the other hand that their expertise and professionalism is being questioned and that the operational teams only know how to say no to changes. They may resent the fact that the Ops team deny or provide limited access to production systems and therefore make it harder for them to do their job.

However, this isn't limited to just Dev and Ops, unfortunately this sense of distrust can manifest it self between all parties from development, operations / support, service management through to enterprise / technical architects. How many of you have come across organisations where there was a discord between dev and ops? How about organisations where service management’s take on providing a service was almost exclusively focused on maintaining the status quo and incremental improvements if that because of the fear of change because they may impact service KPIs and therefore reflect badly on them.  Perhaps you’ve seen first hand what happens when technical architects / enterprise architects define enterprise architecture artifacts (standards, policies, guidelines, principles etc) but do not engage with all areas in developing them and therefore do not get the buy-in necessary for widespread adoption. Some organisations may involve the business and technical architects but fail to consult operational teams. In such circumstances, the operational teams may feel the EA artifacts were developed from an ivory tower and do not reflect what can actually be supported.

In my personal experience, these problems are largely driven by the fact that the performance of these teams areas measured on different factors that can be diametrically opposed, a tendency for these teams to work in silos and lack of collaboration at an architectural and daily operational level. If you work in for a relatively new organisation it is in some ways easier to avoid these problems or to alter the way these teams behave and work together. In contrast for established organisations, getting people to change can be very difficult.

So how do you deal with these problems and get these teams to work as a cohesive whole?

Identify the root causes

Well, firstly you need to understand what the root cause is and what each team’s complaint is, what issues they face in doing their job. This needs to be conducted in a fair, objective and independent manner, people are unlikely to tell you their real thoughts if this exercise is facilitated by a member of a team with which they do not trust. For this reason you really need an external mediator that is not affiliated with any of the teams and it must be made clear from the outset that the objective is not to apportion blame for the problems.

Develop a plan

Once you have identified the causes you need to determine how to resolve these issues. Often asking the teams what can be done differently to avoid the problems is a good start for identifying options.

Align the objectives and goals of teams

As mentioned, you need to find a way to align the goals and objectives of your teams and ensure that you’re not measuring them on things that will lead to conflict rather than collaboration on achieving a common goal. 

If your development team is working on new features, have members of the operational teams allocated as SMEs to help them to understand a plan for the impact the changes will have on infrastructure. This way the operational team understand the changes and having provided input into at the design stage they are more likely to be supportive of changes because they will understand how the changes will impact the availability of systems.

If you are developing EA artefacts, yes you should involve the business but also involve technical architects, development and operations. If you don’t they are likely to be ignored or sidestepped even if they are endorsed by senior management – believe me I’ve seen it happen.

Foster / Encourage Trust

Developing trust between teams can be difficult but you can start with encouraging teams to share knowledge. For example, the operations team can share information on the infrastructure that their applications will run on, best practices – this approach means the operations team can have more confidence that the application is appropriately designed to make best use of the infrastructure.

A complementary approach that I like very much is the idea of Joint Architecture Design described in book The Art ofScalability (the book also has a website http://theartofscalability.com). To paraphrase from the book the idea of the JAD is that for an application/solution you have a software engineer, an architect and operations engineer work collaboratively to develop the design. This incentivises teams to carry the solution through the various stages of its life cycle.