Clear the Barriers to DevTestOps

Much has been said and written in the last few years regarding barriers to effective collaboration between development teams and operations teams. The entire concept of DevOps as a cultural set of practices, principles, and values has sprung up exactly because of this lack of collaboration.

As a result, development takes a far better look at the process of getting their software to production, and how it behaves once it’s there. Operations, on the other hand, has been successfully brought into the beginning of the process and has a far better view of what’s involved with building the software that’s eventually pushed out to their servers.

The same sorts of barriers exist regarding test and operations. Broadly speaking, these barriers can be sorted into three high-level categories: goals, tooling, and teams and process.

Goals

Goals that are common across all aspects of the organization are critical for delivering high-quality, high-value features to customers. It’s impossible for organizations to meet business and customer expectations unless those goals are clearly understood Too often major goals have been focused on one particular group versus the entire organization.

Quality as a goal? That’s often seen as the responsibility of the “quality assurance” testers, despite the fact they don’t write specifications or the software. Immature, old-school organizations fail to bring both development and operations into the quality domain as effectively as they should.

Reliability as a goal? Operations nearly always has this as their purview, despite the fact they’ve not built the systems, nor were they involved in creating the “non-functional specifications” that directly impact scalability, disaster recovery, and other mission-critical aspects of the system.

It’s difficult, if not outright impossible, for organizations to move quickly in the same direction without common goals and clearly understood expectations.

Tools

Tooling is regularly a major impediment to effective collaboration. Development teams will center their engineering processes on an orchestration engine such as Jenkins, TeamCity, or other continuous integration/continuous delivery servers. Only the most mature organizations extend this automated pipeline all the way to production. Instead, operations teams will work deployment and quality check steps manually, or with their own set of tools and scripts.

Development teams frequently set up their own environments for development and testing. These environments habitually run on different platforms than operations’ production environments. This leads to significant challenges and wasted effort duplicating configuration, deployment, and verification scripts.

System monitoring tooling is routinely hosted on vastly different platforms. Jenkins’ dashboards might be the favored tool of choice for developers. Testers might live in Team Foundation Server or Quality Center for test status, while operations prefers New Relic or its ilk for production monitoring.

Teams and process

Great strides have been made over the last decade at moving to whole team implementation. Even immature organizations are bringing product owners and user proxies closer to the delivery teams, process-wise, if not geographically. Most organizations have started to embrace having testers, program/project managers, and developers co-located whenever possible, or at least working as one team, even if they’re geographically separated.

Unfortunately, while processes like Scrum, Scaled Agile Framework for enterprise (SAFe), and others have emphasized pushing critical communication and collaboration to the left (earlier in the cycle), this collaboration still regularly leaves out critical groups from the discussions. As an example, operations rarely is aware of non-functional requirements such as performance specifications, disaster recovery expectations, or other critical service level agreements (SLAs).

Eliminating the barriers

None of these barriers are insurmountable. To the contrary, the success of teams maturing in their process from basic agile to CI/CD to DevOps proves these barriers can be overcome!

Establishing common goals across an organization is a critical first step. The high-level goals must be business-oriented and clearly communicated across the entire delivery team — from the business owner/stakeholder through operations. Those teams must then ensure they have  clear goals for their individual projects/systems/lines of business. Moreover, the entire team must be involved from the start to ensure those goals and expectations are well-understood.

Software tooling has been both a wonderful boon and a terrible bane for all delivery teams. Organizations need to avoid overly restrictive “standardization” lists while exercising some modicum of sanity to avoid an insane sprawl of one-off solutions that meet a developer’s/tester’s/admin’s favorite need. Establishing a common source control system is one step, as is settling on a narrowed set of supported tools selected to empower delivery teams to effectively meet business requirements.

Moving away from separate functional teams (“the development team” handing off to “those testers” etc.) and creating an delivery team that represents the entire chain from business owner through the end user, with product owners, developers, operations, testers, support, training, and others as appropriate.

DevOps has been a crucial evolution for our industry. Broadening it out to ensure it’s inclusive of testing is the next step in our industry’s maturity.

Lubos Parobek leads product management and user interaction at Sauce Labs. His previous experience includes product leadership positions at organizations including KACE, Sybase iAnywhere, AvantGo and 3Com. Parobek holds a Masters in Business Administration from the University of California, Berkeley.