How To Fix Your Fragmented Scrum Team
Updated: Jul 14, 2019
In a previous post, I outlined how dividing a team of developers into arbitrary sub-teams can trigger discrimination between those sub-teams. This is because of a bias referred to in psychology as the minimal group paradigm which predicts that people will favour their own group at the expense of others.
This bias has been shown to occur even when the identity of people in other groups are unknown so it cannot be explained just by interpersonal favouritism. Even when a person is excluded from any benefits that are allocated to their group that individual still favours their own group. So simply being assigned to a group is enough to spark in-group favouritism and discriminatory behaviour towards other groups.
I think this is an important pattern to be aware of when managing a software project because sub-teams need to work together to be successful. What can be done to minimize this bias?
In Patterns of Enterprise Application Architecture, Martin Fowler states that the First Law of Distributed Object Design is “don’t distribute your objects”. Since, I would argue, the most important proposition in the Agile Manifesto states that individuals and interactions should be favoured over processes and tools (because people build software), I propose that the First Law of Scrum is “don’t distribute your development team”.
Clearly, this is not always possible or practical. Most development teams are larger than the maximum recommended team size of 5 to 9 people so some form of distribution into sub-teams is necessary to make the rituals of the Scrum more efficient.
Here are two simple ways that the effect of the minimal group paradigm can be dampened:
Enlightening your team on the existence of this bias is an important way of minimising its effect on their behaviour and morale. Knowledge is power as they say. Perhaps, to start with, just give your team a link to this blog post!
More importantly, it's essential to remind your team that, despite being divided into separate groups, they are in fact all part of one team. Ultimately, all members are chasing the same goal: success of the project / product / business.
2. Encourage collaboration between teams
Collaboration is the antidote to fragmentation and isolation. Collaboration needs to happen within teams but it also needs to happen between teams. The Scrum of Scrum meeting should not be the only formal interaction that Team A has with Team B because that creates a divisive development culture that is bad for morale and productivity.
Collaboration can come in many forms. The most important form, however, is pair programming or in this case inter-team pair programming. During a pair programming session two developers sit at a computer and take it in turns to either be the author of the code or the observer of the code. In this manner one developer always acts as the driver and the other acts as the navigator. The two developers swap roles frequently. The benefits of this software development practice are impressive and influence not just the individuals and the team but also the project.
Pair programming can:
encourage collective code ownership
cultivate a mentoring culture
help developer’s get to know each other better
result in better code
While there is a development-time cost to pair programming (estimated to be about 15%), it is repaid by these benefits.
I believe that if developers regularly pair with developers in other teams on solving particular problems and transferring specific knowledge then there will be greater cohesion and less in-group favouritism.
This would need to happen on a rotational basis so everybody gets the chance to ‘visit’ other teams and would need to be planned carefully. However, the benefits of doing so will soon pay dividends in terms of improved morale, inter-team cohesion and of course the sharing of knowledge.