Agile and Scrum usage has skyrocketed in the last 15 years, especially in the software industry. One of the key reasons managers around the world have adopted it is because it encourages forming small cross-functional teams which in turn promotes holistic cross-team communication.
It is crucial to recognize the reason behind the popularity of the concept of cross-functional teams so that the best can be derived from the understanding of the practice. The cross-functional team concept suggested by Scrum encourages testers, requirements specialists and developers to work together as one small team. This takes the team away from the narrow minded territorial approach of doing work. Instead, the teams work more holistically.
The Scrum framework has daily sync up huddles to have the various cross-functional team members such as business analysts, developers, architects and testers communicate every day. In addition to that, Agile encourages all team members to be collocated in an open cubicle style seating area, which almost forces them to have face to face communication more often. More goal oriented cross-team communication means less misunderstandings and tension.
Agile recommends transparency within the team and when dealing with the customer. This overall culture of transparency helps team members feel free to open up communication channels and stop working in silos.
Traditionally software development has followed a structural approach in developing products which means that the schedule, budget, and timeline drive the product development more than anything. The teams are formed based on the timeline and may be hired at different times in the product development lifecycle. This phenomenon results in requirement specialists, developers, testers and other project members working in the project without communicating much with each other.
It’s not that the different teams don’t talk to each other. They do have planning meetings, analysis meetings, status meetings, lessons learned meetings where they meet, however the big problem is that they only speak for their own teams, and never holistically for the product.
Each requirements analyst, tester and developer report to their respective team leads. This culture creates a further divide between the requirements analysts, testers and developers. Even if they are communicating, it is more for formal reasons and less for the betterment of the product.
At the end of the day, the customer is the one who suffers due to lack of cross-team communication. The customers and management constantly have to go on a wild goose chase to even get the simplest of answers from the project teams. It is hard to get answers because the test manager gives answers from a testing perspective, the developers give answers from development perspective but no one knows the holistic answer. Not many people can give an answer from an all-inclusive standpoint. The problem is systemic and this gap is created because of the culture of having separate functional teams which leads to lack of effective communication.
Scrum has a framework which enables communication to happen naturally between developers, testers, requirements analysts and other team members. The reason for that being, unlike waterfall style projects, Scrum has cross-functional teams which have a common goal. Scrum works in increments and it’s daily standup meetings reminds everyone everyday about their common goal.
Rather than forming teams around the master schedule, if you form teams based on what expertise is needed to build the product, the communication can’t help but happen. To build a software product you would obviously need a developer, a tester, a requirements analyst. Probably you need a database administrator and a system administrator to manage deployments as well. All these folks could be a part of the same team, working on a common goal. This model will encourage more open communication between team members with different skillsets.
If you are test manager, you need to encourage your testers to go beyond testing so that they may learn how to code or learn a bit about requirements gathering. Of course, testing will be their primary skillset but it does not hurt to help the requirements analysts with a little requirements gathering or make some cosmetic code changes while working with developers. This in turn makes it comfortable for testers to speak the language of developers, and developers to speak the language of testers and so on.
One way to break down cross domain communication is by having too many meetings for everyone to attend. Too many unnecessary meetings take away the criticality of meetings in general, resulting in zombie-like communication without any enthusiasm. Cut down on the non critical meetings, and only leave the ones that bring out the most value. The communication that happens in the remaining meetings will be more meaningful.
Managers need to avoid command and control style of work. Beyond a certain level, monetary incentives don’t matter to employees. What matters to them is to find purpose in the work they do. Think of all the softwares that are operated by volunteers, for e.g. Wikipedia, Linux, StackOverflow, etc. Why would they want to work for free to build or support these products? The reason is that people are looking for purpose. As a manager it’s your responsibility to empower your employees to make their own decisions. This encourages a culture of open communication even with people outside their team.
When solving a project problem, tossing the ball over the wall does not help much. It is important to instill a culture of collectively swarming around a problem. Keep a conference room handy for teams to swarm together and speed up the cross team communication cycle. Relying on email to solve problems results in significant wastage of time and resources. All team managers should have an agreement to provide resources from their respective areas when needed for problem solving.
There will always be people who will play the blame game. If you see someone doing that, politely call them out on it. The blame game between developers and testers is a common occurrence. This causes unnecessary bitterness and breaks down open cross-team communication channels. As a manager, remind everyone that they are all on the same team anytime this happens.
- Team members are more productive when working cross-functionally. Agile and Scrum encourages cross-functionality. Scrum encourages daily cross functional communication.
- The customer suffers the most when cross-team communication fails. Even seeking answers to simple questions turns into a wild goose chase.
- A few solutions to this problem are: Adopt a framework like Scrum, form product based teams, embrace cross-functional team culture, cut down on useless formal meetings, empower your subordinates, swarm around problems to solve them, and call out people who play the blame game.
Lack of cross-team communication is a two-fold problem. Firstly, a framework must be provided for developers, testers and requirements analysts to communicate freely. Secondly, they should be assigned a common goal and location so that they can’t help but communicate.
Communication problems cannot be solved by merely adding more meetings because it does not solve the root cause, which is the lack of common purpose!