DevOps’ aim is to create efficiencies in the software delivery process. But, it doesn’t always work out that way. Sometimes DevOps initiatives lead to mistakes—something we lovingly call a “DevOoops.” CloudBees recently polled some colleagues and came up with five examples of a DevOoops in action. Following is a discussion submitted by consultant Viktor Farcic about siloed departments.
A real obstacle is cultural and caused by having siloed departments. When we start looking at a system as a whole and detecting areas of improvements, the answer tends to be, “This is not our department; we don’t know them, they won’t speak with us.” Those siloes are the main argument in favor of DevOps; it tries to remove them. But, in reality, most companies fake it by creating yet another silo called the “DevOps Department.” DevOps in practice directly contradicts DevOps ideas.
More than a half century ago, while working on compilers, Melvin Conway nailed what is now the crux of the problem we are seeking to solve with modern software development and DevOps practices: “Organizations which design systems,” he stated, “are constrained to produce designs which are copies of the communication structures of these organizations.”
This concept, known as Conway’s Law, suggests how failure to break down silos and organize cross-functional, collaborative teams lingers today as one of the most overlooked steps to implementing DevOps and, despite all best intentions, results in dysfunctional software.
Most companies are organized by function—with business, project management, project owners, developers, quality assurance, app deployment, infrastructure and security groups all focusing on their own areas of expertise.
DevOps initiatives attempt to break down these silos. But it’s easier said than done. Most organizations embarking on DevOps journeys have to deal with an “us versus them” mentality.
Organizational issues create tension, resulting in difficult, friction-laden handoffs between teams. The problems often show up in the software delivery process and in the software itself in the form of quality gaps, inconsistent user experiences and other issues.
Picture this: Input to the application is coming from multiple nonaligned sources, each with its own particular variant on the user experience. If a business analyst and a developer interpret a customer requirement for the customer differently, the end product won’t meet expectations. If you have one team responsible for login and authentication and another responsible for the primary landing page, you can have a login identification that looks and feels different than the core landing page does.
Organizations need to acknowledge that culture will have a direct bearing on DevOps success and commit to taking on those challenges. It won’t be easy. It won’t happen right away. But, with some work, it can get done.
Here are three strategies for removing organizational blockers and avoiding this particular DevOoops.
- Alignment – Think about how to best align real or virtual teams organized around products, product functionality or features instead of skills sets or functional groups. For example, construct a small agile team around middleware that includes representatives from the business, developers, quality and operations input.
- Communication – Continually encourage communication, trust and transparency. This can be done by using real-time communication tools such as Slack and by centralizing and sharing data using tools such as Jira. Teams need to break down the lingering feelings of distrust. It’s OK to not be perfect. Organizations should set up reporting mechanisms that include successes and failures—all in the name of creating a better final product.
- Inclusion – Involve key stakeholders early and continuously. Once you have built these teams, as you embark on your DevOps journey, make sure all stakeholders in the software have a voice. You need to create a common understanding of what their individual needs are and align those around team needs, which sets the stage for ongoing collaboration and communication.
- Organize your teams around subjects such as product and functionality and include all the stakeholders in the software development process in these product or feature teams.
- Culture in DevOps is just as important as process, practices, tools and technology, yet it’s one of the most difficult things to change.