Linking Collaboration to the DevOps Chain

Source – itbusinessedge.com

Much of the focus surrounding DevOps is on the tools, technologies and platforms that strive to produce better products in a shorter timeframe. But at its heart, DevOps is about getting people to work together more effectively and efficiently.

This is easier said than done, however, especially considering that DevOps replaces the linear “waterfall” style of development with a more chaotic workflow that stresses continuous change over the creation of a “finished” product.

This is why some leading DevOps practitioners are starting to view collaboration on an equal footing as automation and scale when devising new working environments. BMC’s Chriss Scruggs, for one, argues that, just as an orchestrated piece of music creates order out of chaos by coordinating the “job” of each individual note, collaboration ensures that each step in a complex application lifecycle meets the needs of the larger business model. Even something as simple as moving a legacy application to the cloud requires careful coordination between multiple systems, platforms and managers.

Make no mistake, however. This is probably the most challenging aspect of devising a working DevOps culture. When trying to unite cross-functional teams, each of which has its own biases, histories and ingrained approaches to key problems, success is rarely total – in part because few people have a real understanding of what success means. CA Technologies’ Mick Adcock espouses establishing collaboration along the lines of the Japanese philosophical concept called ba, which stresses the importance of things like trust, knowledge sharing and functional cross-pollination. In this approach, organizations will adopt guidelines in which the business itself is considered the system to be developed around a culture that stresses shared responsibility and encouragement of experimentation.

Regardless of whether a project is implemented through DevOps or in a traditional manner, collaboration is often the key factor in its success, says Mendix technology evangelist Nick Ford. IDC estimates that about a third of all IT projects fail, and many more are salvaged only through massive effort. The key disconnect often arises between the expectations of the business team and what development and operations can actually accomplish. Bringing these two groups together on the same page is one of the primary ways to implement a business-focused DevOps environment, or what he calls BizDevOps.

Still, the tendency for the enterprise to look at DevOps as a magic bullet that will save IT from itself is probably the biggest threat to an effective transition. Patrick Turner, CTO of tech consulting firm Small Footprint, notes that the long-standing conflicts between dev, test, QA and others in the production chain often inhibit collaboration even after the most advanced sharing tools are deployed into the work environment. Even standardizing collaborative practices is not enough if it leads to stasis and redundancy. The essence of DevOps is to continually strive for best practices, in part by breaking the standard ways of doing things.

Proper collaboration is an ill-defined concept. It can’t be measured or quantified, so you won’t ever know if you’ve truly achieved it beyond the results of satisfaction surveys among workers, users and other stakeholders.

But it’s fair to say that you can’t do DevOps effectively without it. However difficult it may be, the process only works when team members start talking to one another rather than at one another.