I am not a big soccer fan, but I know a lot of people who are. Any soccer fan can tell you that if you add the best soccer players of the world in one team and just let them play against FC Barcelona, they would definitely loose. Not because they are not the best soccer players, or because all the best soccer players in the world happen to play for FC Barcelona, but because FC Barcelona can actually function as a (winning) team and random players put together can’t. Seems rather simple logic, years of playing together, developing winning tactics and gaining each other’s trust pays off! So, why should this be any different for teams developing software products? It is not!

Agile software development depends heavily on highly cooperative, multidisciplinary, self-managing teams. Since each team member is equally responsible for the end result , people in an agile team cannot hide behind a specialist role and a pile of documentation, but need to understand the complete impact of their work on that of the other team members and help each other out where necessary. That makes clear communication necessary and the team will function best if the members know what they can expect of each other. This is not just theory – in agile projects the velocity of any good-functioning team increases over time. Continuous improvement is intrinsic to agile teams, because after each development cycle the team gathers to reflect and makes adjustments where necessary to improve their quality and speed. The velocity of the team is measured constantly so this improvement can indeed be seen.

People are unique, because each person has his own strengths and weaknesses and unique experiences. In the same way, each team also has its own unique identity that makes it successful. It is not possible to reproduce the same team result by just putting together random individuals, because these will not have had the same experiences as a high-performance team has had together. A team represents certain knowledge and skills that cannot be found in any individual, making it a very valuable asset for any organization. The great thing is: a team can be kept alive, so that the knowledge and skills represented by it are preserved, whereas individuals can fall ill or leave. It is not necessary to never make any changes in the composition of the team, as long as these changes are rare and small. A high-performance team can even function as a learning environment for new team members and acquire new skills by occasionally exchanging (not adding!) a member, thereby increasing the knowledge of the team. 

Unfortunately, most teams are still formed around projects that end after a certain time, after which the team is broken up. The team members get to work for new customers on new projects and the skills and knowledge that the team had built up together is lost. Whenever a new project needs to start, a new team forms and the cycle of learning and improving starts again. There is no guarantee that this new team will get to the same level as the old team. Time is wasted and valuable resources are destroyed in this way of working.

Don’t break up a winning team!

NB: this blogpost was published before on the Dutch Capgemini agile blog, since that blog is closed, I’ve republished it here.