Since the beginning of time, organizations doing software development have leveraged the “divide and conquer” approach, breaking down their workloads into 5 main positions: Developers, QA testers, IT administrators, Managers & Operations Engineers. All of these teams have their own role to play and focus on doing their particular job to the best of their ability.
This approach creates silos, which is any system within an organization that is closed off to other systems. Silos tend to construct themselves inadvertently, as different managers take on various priorities and responsibilities within the organization. Although silo’d environments never intend for this to happen, they run the risk of hindering collaboration within your business, thus restricting the flow of information and breaking down communication.
From my experience, silo’d teams typically experience more misunderstandings, problems with coordination, unproductive meetings/email chains and worst of all, members of one group feel less responsible for issues in other parts of the organization because they don’t feel that it’s “their” problem to solve.
The introduction of DevOps principles in organizations aims to reduce the time to market for features. In order to deliver software faster, it has to be designed to be testable – you can not sacrifice quality for speed of delivery. Quality gates enable automated go/no-go decision for deployments.
In the era of digital transformation, many businesses have started to realize the disadvantages to silo’d environments and more and more companies are turning to DevOps as a means of producing active collaboration across traditional business divisions.
As a side effect, software quality will almost always increase. In order to enable quick rollouts or rollbacks, business and management logic need to support feature switches: allowing a set amount of people to test the feature in the environment it runs in.
DevOps requires developers, QA testers, operations engineers, and product managers to work closely together from the very beginning, which means that any existing silos will have to disappear quickly, if done the right way.
Organizations often start breaking down silos and migrating to DevOps by removing barriers between development and testing. According to the waterfall model, testing should occur only after the software’s development is finished. However, this can present serious disadvantages when a major issue with the software is identified during testing, requiring developers to go back and make drastic changes. By requiring developers and testers to cooperate earlier in the process more closely, teams can incorporate feedback sooner, thereby making themselves and their application more agile.
In particular, one of the key elements of DevOps is the automation of processes and workflows, wherever possible. By increasing the use of automation, colleagues can share information more efficiently and make other people’s jobs easier at the same time, without requiring a series of conference calls to get everyone on the same page.
Breaking down silos has a variety of advantages for software development teams: they’ll deploy applications faster with fewer errors, react more quickly to external changes and be more efficient and productive. If your organization is struggling with silos, consider migrating to DevOps to see how you can become more agile and produce better-quality software.
Tackling organizational problems take empathy, a lot of reflection, and the will to get rid of bad habits. Furthermore, cemented hierarchies and the unwillingness to share responsibilities will prevent a successful adoption of DevOps methodologies. An organization where employees are not encouraged to experiment, adapt, and improve is destined to fail.