Breaking Silos

Higher collaboration creates successful products

Photo by Waldemar Brandt on Unsplash

In my first job, I had no exposure to Agile.

I was part of a product development team which mostly worked on defects and enhancements on a legacy codebase. After completing development of every ticket, the ticket would move into the testing lane. If the testing team found an issue with it, the ticket would be reassigned to me and the cycle would continue. That team sat on a different floor of the building and we only communicated through these tickets. This was true with the build and deployment team as well, with whom we had very little communication.

At that time, I thought, “Alright, I guess this is how software teams work!”.

And then I joined Thoughtworks. Here, I learnt about the Agile way of working and figured out that what I saw in my first job were “silos”. I slowly realised that silos need to be broken for an effective way of working as well as for development of a robust software product.

Silos across departments or verticals affect overall business goals and value as well. In this blog, I am going to concentrate on the effect of silos on development teams and the ways to remediate it.

Symptoms of silos

Although its generally quite obvious, there are some smells and symptoms which point towards a silo-ed work environment and we need to identify them.

1. Throwing over the wall: Formally transfer a responsibility over to another team/individual and having no ownership of the work.
2. ‘I don’t know anything about that, ask X’: If someone’s answer to a question is this, it means that knowledge is not being shared.
3. ‘He/she is the expert. We can’t let them go’: There are few individuals who are considered indispensable.
4. Little or no communication between verticals/teams: Lack of connect between different teams.
5. ‘That’s not my job, ask the Y team’: Lack of collective ownership

This leads to

1. Bottlenecks: Lack of communication and collaboration leads to slow resolution of issues giving rise to unwarranted bottlenecks/blockers during development
2. Longer cycle time: Overall time taken to develop, test and release a feature increases due to slow handoffs.
3. Less-skilled individuals: Team members do not get opportunities to learn and grow. Lack of knowledge sharing across teams also leads to this.
4. Low morale: Higher number of blockers, lack of communication reduce the motivation within teams. People may be stuck doing similar work for longer times. This may lead to higher stress levels too.
5. Over dependency on certain individuals: In many cases, certain members of the organisation become indispensable due their isolated expertise. This is very dangerous for the organisation, since it’s gets harder to replace that person over time, and the knowledge is never shared.
6. Miscommunication: Due to lack of regular catch-ups and a non-collaborative environment, its highly possible that miscommunication may cause misunderstanding in team goals.
7. Blame games and conflicts: Teams working in silos often blame the others for any issues since there is a lack of collective ownership of the product.
8. Chances of rework: If teams do not understand each others’ goals, there may be chances of rework.

Solution

Photo by Cytonn Photography on Unsplash

Key changes in ways of working leading to culture change in organisation are necessary for breaking silos and bringing all the teams together.

1. Collaboration: All roles and teams working on a software product must collaborate.
2. Transparent communication: An open channel for discussions and conversation is very important for teams/individuals to connect and come up with the best technical decisions for developing high-quality software.
3. Nobody should be indispensable: No individual should have the kind of power or knowledge to create bottlenecks. Leadership must encourage knowledge sharing and rotating responsibilities.
4. Cross-functional teams: Teams with different roles like developers, QAs, devOps and BAs are very important to break silos and bring all perspectives on the table.
5. Shared knowledge and information flow: Knowledge sharing through frequent sessions, tech huddles and good documentation can help to remove dependency on certain individuals
6. Pairing on tasks: Pair programming is a way for developers to pair on developing a piece of functionality. In addition, folks can pair on other tasks too like analysis, testing, automation etc. so that context can be shared

Benefits

1. Motivated teams: Motivated teams, with clear goals and collective ownership.
2. Faster cycle time: Faster cycle time due to collaboration, and time reduced in decision making and resolving blockers.
3. Collective ownership: Being responsible for changes along with other teams gives a sense of collective ownership.
4. Shared knowledge: Slowly and steadily all teams are aware of each others work and understand the whole system, which in turn increases everyone’s confidence.
5. Low downtime: Higher the collaboration between teams and roles, lower would be the downtime in situations like deployment, bug fixes, hot fixes, roll backs etc.

Having talked about silos throughout this blog, I have no intention of saying that all teams HAVE to be cross-functional and you cannot have a testing team, or deployment team etc. Depending on the need, organisations may need to either create teams that handle specific responsibilities, or can have cross-functional teams, or a mix of both. But the important part is to avoid silos, arising due to zero collaboration.

The key is that silos are anti-collaborative and are a big hurdle in development of high-performing teams and great quality software. So break silos and gain the benefits of collaborative ways of working.

All the best!