“May your adventures bring you closer together, even as they take you far away from home.”
Trenton Lee Stewart.
During years of working on international project teams I’ve been lucky enough to have observed some fascinating group dynamics. OSS project teams form an interesting ecosystem from a group dynamic perspective, especially when there is a core project team of 10-20 people with various other occasional resources.
In fact, I’ve yet to see an OSS project that was implemented by an individual rather than a team, so group dynamics certainly come into play. It is essential for a team to work together cohesively to be able to pull the diverse pieces of the OSS jigsaw together. However, team building and group dynamics aren’t always considered as part of a project initiation.
Tuckman’s model, as shown below, certainly provides an interesting counterpoint to the formation of OSS project teams.
- Forming – A group comes together with unclear personal roles / responsibilities or knowledge of the strengths / weaknesses of the other team members
- Storming – The team identifies the project objectives and their different perspectives and ideas have the potential to create tension / conflict
- Norming – The team stabilises and forms a mutually agreed approach to resolving project objectives and
- Performing – The team functions as a cohesive unit to resolve project objectives.
When a newly formed OSS team comes together, no matter how experienced the team members are individually, there is always a ramp-up period that seems to follow Tuckman’s four phases. Not all OSS teams develop the maturity to get through to the norming and performing phases though.
I’ve been lucky to have worked on a number of high-functioning OSS teams where the core team has established a strong performing culture over time. But those OSS projects have always had short-term “interlopers” too (eg a testers, developers, etc with short-term objectives) that have had unpredictable impacts on the group dynamic.
From what I’ve seen, these fly-in team members rarely have the time to get to the “performing” stage with the core team and they should be minimised wherever possible. A management team that throws resources at problematic OSS projects will often create a detrimental effect. A constant stream of short-termers definitely detracts from the team’s ability to perform together consistently.
The one exception to this rule is where the interlopers already have past experience with members of the core team (ie they have been through the norming process together previously).
Are your OSS teams in a constant state of flux?