Cross-functional team collaboration - how to make it work

Implementing complex IT projects successfully requires the co-operation of all teammates and roles. It’s like a football match where each player has a specific role in the team, and they come together to support critical situations, taking responsibility on the pitch. It is precisely this synergy that creates a good team, pursuing a common goal.

Unique and complex projects require the co-operation of different people and roles to achieve success. This is especially true in software development, where different disciplines converge, which are highly specialized and also highly interdependent.

Here’s how a typical collaboration workflow unfolds:

• Developers require professional and technical specifications from analysts, departments, or architects.
• Testers build on the technical requirements and the developed program status, i.e., the results of all the roles mentioned above.
• The client and the user are particularly interested in the overall result. Therefore a successful collaboration within the team is a prerequisite.

The previously-used waterfall model of software development, with teams structured according to main disciplines, is no longer good enough to establish the co-operation necessary for project success. Teams create added value by combining different personalities and skills. In cross-functional teams, the strengths of different professional groups can be used to achieve a better result more quickly. In this blog, I would like to share my experiences regarding software development with cross-functional teams.

How can different roles benefit from each other?

Analysts and developers

The most typical co-operation is between analysts and developers – this collaboration has always existed. Developers benefit from the business knowledge of the analysts, who can teach them the larger context of the code to be created, its goals, and its purpose. From their end, developers give feedback to the analysts on the situations to be considered, and whether the planned solution is technically feasible.

In agile teams, this co-operation is even closer than ever. Epics and user stories record requirements in lesser detail than in a Requirement Specifications Document. The focus is on developing an executable version to receive feedback as quickly as possible, through a lot of direct communication.

Analysts and testers

Analysts and testers also often work closely together. In my last project - development of apps for Android and iOS - the testers in our team made everything very smooth. They used to create test cases at an early stage, sometimes even before the start of development. This was done not once, but as often as possible. This helped the analysts in receiving quick feedback about whether the defined user stories were understandable from a technical perspective and whether the acceptance criteria were comprehensible and practicable. Remember, all this was often done even before the developers started to work on the stories.

Consequently, the testers were able to develop a professional understanding of the new functions during this phase. During the tests, the analysts helped in determining the severity or relevance of errors. For the critical topics, they tested together to clarify any issues that arose.

Developers and testers

The collaboration between developers and testers can be mutually beneficial. For example, our developers supported the testers in creating test classes to support developmental test automation. To achieve better joint test coverage, they wrote unit tests to ensure that the correct interfaces had been handed over. The testers, in turn, often drew the attention of their fellow developers to the missing or misunderstood functionalities or used their systematic approach to ensure that the creatively implemented code was given the right finishing touches.

Does everybody do everything?

Yes and no. The smaller a mixed team is, the more naturally the fixed roles become blurred. In such a situation, more and more other tasks have to be taken up, which are urgent and need to be mastered due to a lack of other free capacities - to achieve common team goals. It is great for internal teamwork if everyone takes on a different role, thereby also being able to understand the perspective of other colleagues.

For example, it doesn't hurt a developer to see how testers are doing when they discover that basic functions should have reached Feature Complete status don't work at all and have proven that the developer hasn't tried them out even once. Such examples of gaining real knowledge can be found between all disciplines. Putting them into a different role in practice enables a better understanding of each other's difficulties. Such understanding and empathy can be a catalyst towards improved collaboration, which helps improve the overall quality levels within the team.

As is often the case in practice, in a larger team (beyond the ideal size of seven), all individuals will remain more involved in their work because trying out a different role is distributed among more potential candidates. That's not a big deal and leads to my next point.

Does everyone have to change roles?

Yes and no! Anyone who thinks that each team member should change his or her basic area of responsibility on a constant basis has scant respect for the skills, knowledge, training, and experience of the different roles that come together to run a successful software project. They are valuable capital that should earn interest and not be squandered. It is also about getting their best possible contribution and performance for the project! A good developer should dedicate himself mainly to the task he knows something about, like writing good program code and solving technical problems. Looking outside the box would be good and helpful, but you should not arbitrarily target someone on topics where the performance will be worse in the long run.

As mentioned earlier, you can compare it to a football game: Everyone helps, supports critical situations, and assumes responsibility on the other side of the pitch. And in the ninetieth minute of a penalty kick and a red card for the goalkeeper, a field player can go into the goal to save the game. But it won't be a permanent solution. An experienced goalkeeper holds more balls, as he has the appropriate talent, training, and experience.

If someone is involved in a project for four weeks in an activity that is alien to that individual, it can make sense in the direction of personal development. In the same way, you need to check whether an additional person can support the team for this period. It is not about making a virtue out of a necessity, but about enabling the most suitable solution in each case.

The leadership of cross-functional teams

An exciting topic! Different characters, talents, and ideas of working are reflected in a common team. How can this work in the long run? Only through a balance between different roles and people, where the manager is jointly responsible. To a certain extent, the leadership task also includes a mediation function - the ability to allow differences and to make role-related perspectives accessible to others.

In a flawlessly agile team, this manager does not exist as in the classical form. The scrum master pays attention to processes; one (or more) personnel manager takes care of the employee development, and the team is more strongly focused towards task ownership. Depending on the situation, the management tasks are distributively shared by different people.

But even in a more classical structure, the team leader is not the only actual leader; there is always an informal organization, unofficial alphas, who take the initiative and assume responsibility for others. Likewise, even in an agile team, somebody hits the table and says, that's how we do it, whether formally entitled or not. The ideas described below are, in reality, always shared by several people, regardless of their environment.

The JOHARI window

There is a term JOHARI window. It refers to conscious and unconscious personality, and behavior characteristics between oneself and the others in a group, differences between self-perception, and perception by others.

When working with teams, I repeatedly encounter typical role patterns that cannot be generalized across individuals, but which I often perceive as significant in practical experience. The communication levels between software developers or the accuracy of analysts or testers are characteristics that result in friction when interacting with others, are often, necessary. Without these conflicts, productive cooperation is not possible.

As a team leader, you can contribute to widening these windows by trying to bring person A closer to the perspectives of person B. If not through practical role changes (which is the more sustainable one), then through dialogue. This, of course, does not always meet with approval in the very first attempt, as it does not immediately solve the difficulties in co-operation. As a manager, you need to withstand such criticism. Such discussions are more to be understood as a building block in the chain from which approaches to solutions emerge - sometimes with a time lag.

For non-cross-functional teams, it is, of course, also true that getting to know and assessing each other better helps in the cooperation. However, in a group comprising different professional groups, the differences will usually be even greater, which is particularly important when working with the team.

It is not the task of the team leader to solve all conflicts; it cannot be possible at all. But you need to make sure that processes are adhered to or improved accordingly. If the employees in the team do not find a solution among themselves, you must be the catalyst for finding one - if appropriate, also with authority, words, and decision.

In any case, you need to make sure that no role in the team is perceived as more important than others - both within and outside the team. All roles are equally important. Ultimately, it doesn't matter whether a Formula 1 car drops out of the race because of a badly pulled bolt or a faulty tire, the overall performance, is decided by the complete package.

Bottom line

Each role requires certain skills, training, experience, and often typical behavior patterns. To keep this flea circus in good order is above all a matter of respect; respect for the different skills that make up a great team. Allowing these differences and still forming a whole out of them (something that is even more difficult in cross-functional teams because of the diverse roles within them) is the exciting challenge in leading such a team.