Deep Thought: 2 heads are better than 1

Collaboration is something that has been cited as a demand of the software industry for what seems forever. No matter what new framework or technology, the need to work in a collaborative manner has always been an absolute requirement. So why do we have to keep repeating it? Possibly because it really is that important. It is strange because it is possibly the easiest thing to implement in any transformation, and yet it is also so very easy to get it wrong.

I often ask people to give me a definition of collaboration, immediately explaining that I expect everyone to provide me with the first part, but nine out of tem people will then miss the second part. Everyone understands that collaboration is about “working together”, but that means nothing unless you include the second elements, “towards a common, agreed goal”.

I have spoken in previous articles about the reasons for failure in transformations being down to culture, and in particular, that in that culture, people will judge situations based on their own perspectives. However, people will have many perspectives, influenced by their role, their nature, their environment, so many different things. These differing perspectives can mean that although two people may be given the same task to work upon, or separate tasks that have a dependency, unless there is an agreement to a common goal, they will work together, but produce differing results.

In a DevOps environment, we are requiring teams of differing perspectives to work towards a common goal. Development are wanting to make as many changes as possible, as quickly as possible, to deliver on the requirements of the customer. Operations are wanting to reduce risk and maintain stability. Change introduces risk and potential instability and so they want to limit the amount of change. In what seems to be an opposing ethos, a common direction must be found, a collaborative way of working that allows a rapid mechanism for stable change deployment.

Automation using tools can provide the rapid mechanism, along with a lean process, whilst a stable deployment can be provided through correct Quality Assurance, which should also be as automated with tools as much as possible. So whilst we are discussing the need for Development and Operations teams to work in a collaborative manner, so must our processes and our tools. Too often, tools are selected because they are preferred by those selecting them, or because they appear first in a search engine. It is important to maintain a relative distance when selecting your tools and ensure that they will collaborate with your process. This means ensuring that you select a tool based upon the one that best fits the way you intend to operate, not the way a tool dictates to you. Having a tool that works the way you want your process to work means they have a common goal, they will properly collaborate.

This is often the reason that collaboration has to be repeated as a requirement. Frameworks change, processes change and so, also, should your teams and your tools. Unless there is a flexibility within both to work together towards that common goal, invariably your transformation will prove difficult and, potentially, fail completely. Two heads are better than one, but only when “working together towards a common, agreed goal”.