DevOps Explained

Most DevOps advocates rarely think about the movement’s drawbacks and unique challenges. For these advocates, the benefits of DevOps are so compelling that even the most common challenges are left unaddressed.

One very common challenge when creating a DevOps culture is knowing when to leave a certain discipline — like product design, engineering or QA — with enough autonomy to operate properly. The challenge is to strike a balance between enforcing boundaries between these disciplines, on the one hand, and encouraging them to work closely with one another, on the other hand.

In practice, this is very hard to get right. In most SaaS companies, the product organization and the QA organization operate separately. In a DevOps shop, however, product and QA should be closely aligned in the sense that QA and product need to agree on key commercial decisions when it comes to product development and deployment. For instance, if a company is releasing smartphone apps for iOS and Android, the product and QA teams have to be closely aligned on how often those apps should be deployed and how many features should be included in each new distribution.

In a genuine DevOps shop, these commercial decisions are easier to make because product and QA leaders communicate transparently. In practice, this means that QA leaders have to be honest about how long a QA process should take for a major software release. But transparent communication is only part of the equation for successful collaboration across teams; the other part of the equation is that QA needs to be able to take the time to properly evaluate and test new product features.

Why does QA need to determine how much time is necessary? Can’t the product and QA team huddle together and jointly determine how much time QA should take? Well, the answer to that question is easy: No, QA should be responsible for determining how much testing time is necessary. After all, QA professionals are subject matter experts when it comes to determining how long software testing should take.

This example illustrates an important general point about the relationship between disciplines in a DevOps shop: While DevOps requires a high level of cooperation between different disciplines, DevOps also recognizes that subject matter expertise must be respected. In the specific case of QA, we recommend that our clients always defer to the specific views of QA veterans when it comes to software testing timelines.

More broadly, Particle 41 recommends that our clients take proactive steps to respect subject matter expertise when adopting DevOps principles, methodologies and tools. We do so because DevOps is only truly valuable when a balance is struck between (1) encouraging disciplines like engineering, operations and QA to collaborate more effectively and (2) recognizing the value of domain-specific knowledge and know how. When this balance is struck, our clients tend to ship better products much more efficiently than they did prior to adopting DevOps.