This discussion was triggered from considering the benefits and issues of keeping a permanent scrum team(s) versus mixing the team(s) up.
It was felt that it was important to consider what team members would like – they may want to move and gain experience of more areas of the business, or they may be bored with their current project and wish to work on something fresher. Equally they may want to stay with their established team and it’s important to communicate why any potential move is needed or why it’s not possible at the current time.
The impact of moving people around and reforming established teams (leading to a fresh bout of Storming, Norming, Performing) can form disruption to a team that is working well as the new body will need to be brought up to speed on the project, and the team may take a while to get back into the honesty and trust for effective retrospectives, both of which will have an impact on the team’s velocity. Care must be taken to ensure the apple cart isn’t upset.
One example of mixing teams was where several different contractors were used. In this case the client wanted mixed teams (each with a mix of contractors) to help prevent competition between the teams (which the client felt was unhelpful) and potential prevent the danger of a particular contractor “carrying” people (though no-one was sure that would actually happen).
When constructing a team we need to try and match the right personalities. It was put forward that team composition could be influenced by scientific methods such Belbin in order to build the teams and help avoid conflicting personalities.
One Idea would be a Pool of Resources which are assigned to teams in order to maximise their value – a UX expert may not have as much value to a back end project and so may be better utilised on another project. However this could impact the project as the teams have to stabilise (if we are regularly reorganising teams) and if the resource is “parachuted” in to an existing team the feeling from both new resource and the team that they are not really part of the team – “You weren’t there Man”.
One problem with long term projects and static teams raised was where single points of failure arose ie team members with all the ‘knowledge’ of the project. There was then some discussion of how XP techniques could help alleviate this by helping to share knowledge. One potential problem with using XP techniques such as Mob and/or Pair programming is that outside observers may not appreciate the benefits and only see two (or more in the case of mob programming) expensive resources using one computer.
If a stable team is proving to be successful – delivering its commitments and working well it would seem desirable to keep it stable and it would be wise to consider the impact of any disruption team member changes could cause on the ongoing success of the team.
So the general opinion as to which was better – Permanent Teams or Mixing them up?