Mono-disciplinary Teams

Effects of mono-disciplinary teams

Most organizations that implement Agile start with a small pilot. Because the team is small, it rarely has more than one or two people in the same discipline, let’s say a domain expert, two developers, and a tester. In this composition, it’s only natural for multidisciplinary collaboration to take place. But, as the Agile implementation proceeds, the Agile project becomes bigger. Suddenly, the team consists of several subteams: two architects, four designers, five .NET developers, four COBOL developers, and four testers. Each has their own stand-ups.

Now, the tendency kicks in to split the team the way they always did, per discipline, especially if the project manager has a traditional background. This has unpleasant side effects. Mono-disciplinary teams have a negative effect on collaboration. Moreover, transfer moments arise again within the team. Like a designer once said, “You won’t get the design of this transaction until it is completely ready.” The fact that individual disciplines are better able to focus on their work is used as an argument. This may be true, but it also hampers crucial communication and collaboration between the different roles.