Almost two decades after the creation of the manifesto, agile has become one of the most discussed software development methodologies, if not the most commonly implemented. But even with such broad adoption, many attempts to implement agile practices fail within just a few months.
While there are many reasons any major process change can fail, my experience on multiple teams—both successful and failed—have provided insight into one of the most common stumbling blocks that prevent teams from benefiting from agile practices: work silos.
Here's how you can tackle the problem of silos in your organization.
Common causes of silos
Agile methodologies are about communication, so the existence of silos within a team or around individual teams is a major obstacle to an effective implementation. Before you can focus on removing or preventing silos, however, you must understand how silos get built—or build themselves.
Grouping specialists into teams
Due to the standard breakdown of departments and responsibilities, specialists are often grouped into teams so they can accept requests and execute plans according to their disciplines. On the surface, this appears to be an efficient method of using resources. In practice, however, this results in creating silos around key functions required by teams across an organization.
Establishing teams by function—such as DevOps, developers, and quality assurance (QA)—may be a good idea from a human resources perspective, but it reduces the effectiveness of agile teams by breaking their cohesion and ability to interact. Dominica DeGrandis provides an excellent example of this in her article on how one team ended dependency delays.
The most effective teams can be self-directed as well as self-contained. That means the members possess the skills to perform all of the tasks necessary to take a feature from concept to product without relying on outside resources.
It does not mean that individuals must be exclusive to a particular team, just that they have an appropriate amount of time slated for performing their required tasks. Having designated resources, even if shared, improves the viability of the team and enables communication across disciplines.
Assigning roles to development phases
The software development lifecycle (SDLC) has been a longstanding part of many organizations' processes, because it outlines the main phases and deliverables required to produce a product.
An SDLC process typically consists of planning, development, testing, and release phases. Within each, specific roles take the lead for providing the deliverable. This is where silos often develop within a team.
The product owner and business analysts focus on defining the product. Developers write the code to fulfill the requirements. Once development is complete, testers verify functionality and confirm adherence to the acceptance criteria. At the end of the process, the application is handed off to DevOps for deployment.
While this is a normal progression and an efficient use of a team's skills, the practice promotes a separation of duties within the team and ignores the benefits gained from including the whole team in each of the stages.
Conflicts among roles
Many struggling agile teams suffer from conflicts between defined roles. This manifests itself through statements such as "that isn't my job" or "if Joe had not missed this then it wouldn't have been an issue" or through the mentality of throwing the product over a wall to the next group. This ruins the cadence and cohesion necessary to maintain a true team atmosphere.
Each team member brings specific skills and perspectives to an agile team that add value beyond the phase in which they are predominantly involved. For example, a product owner, or business or business analyst, typically represents the business or end users' desire for a product. They can define the need, but often are unaware of the technical difficulty and requirements.
By including developers in the planning phase, you can receive rapid feedback on functionality and set realistic expectations. The same is true for including testers, since they will be able to supply an understanding of how the product will be tested. In this way the team avoids missing validations and requirements.
These include reducing test time by pairing developers and testers, and increasing the amount of in-sprint automation completed. Finally, this approach ensures a smooth release as a result of DevOps having prior knowledge of requirements as well as input on how the product should be developed for the given deployment environment.
Report it and forget it: Over-reliance on asynchronous communication
While collaboration tools themselves do not directly form silos, those that provide asynchronous (one-way) communications can encourage behaviors that result in silos. The most common example is when reporting bugs and defects.
When testers find an issue, they document it within a bug tracker for review, prioritization, and correction. Development and tester silos can develop if the product team relies on the bug-tracking system to handle notification and communication between team members. By replacing direct interaction and collaboration between team members, the tool encourages a mindset of tossing information over the wall, with no feeling of responsibility to follow up.
To avoid developing walls, establish a process that requires documentation and discussion. For a defect—an issue directly related to a story—the tester should alert the developer and the product owner and ask for a brief description of the issue. The tester can then schedule a more in-depth discussion, if necessary.
Through discussions like this you may discover that what you thought was an issue was intentional, or something you can deal with quickly, reducing the need to document, track, and confirm the defect. Any reduction of bureaucracy within a team that can be achieved through a short conversation will result in improved morale and faster turnarounds.
Go forth and deconstruct your silos
There's a common theme that runs throughout all of the examples I've discussed in terms of how silos derail agile teams and how to solve those problems.
To break down your own silos, start with effective communication and timely input from all roles and team members throughout the development process to maintain productivity, product quality, and team morale.
When you emphasize direct team member collaboration and involvement at each development phase, you'll reduce, if not eliminate, the silos that hinder the progress of so many agile implementations.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
