Composition of the scrum team

1 Comment

In the environment of the agile method „Scrum“ I would like to contemplate more closely one important aspect of the project management: The composition of the project team. In the conventional project management this is one of the basic tasks of the project manager. The ideal case is that he can assemble his project team on his own and that he can change the composition during the ongoing project. In the real daily routine he naturally is subject to many external conditions, like for example a limited choice of potential team members or competition through other projects and budget limits. However this does not affect that the project manager should have this authority.

In connection with “Scrum”, the role of the project manager does not exist any longer. Most of the capacities and responsibilities have been distributed to the three roles “product owner”, “scrum master” and “team”. How does this happen regarding the composition of the team? The following subtasks have to be considered:

  • initial team composition
  • missing skills within the team
  • enlargement of the team (in order to increase velocity)
  • diminishment of the team
  • indentify and exclude “low performers” and “troublemakers”

Initial team composition

The composition of the team at the project’s start can not be made by the team itself because it does not exist at this time. By means of his budget responsibility the product owner of course has a very strong influence, but the detailed decision certainly lies with the scrum master. He shall pay attention that the team works, especially in the beginning, both related to the professional and the social skills of the team members.

I think it is a fascinating question, how a good composition of the project team during the whole course of the project would look like. However, dealing with this question would go beyond the scope. I am going to illuminate this topic in a future article.

Missing skills

Should the team lack skills, which are important for the project, this will be regarded as an impediment very soon. Mostly, this will happen in the daily scrums already, but latest in the retrospectives. Then it will be the task of the scrum master to fit the team with the missing skills. The scrum master has different options:

  • changing the composition of the team
  • training / coaching of team members
  • access to specialists outside the team

Enlargement of the team

The decision is to enlarge the team to increase the velocity in the long run. The reason for this can be a decreasing (or stagnating) velocity, an increasing deadline pressure from the outside or simply free full-time equivalents, which shall be integrated in current projects.

In the first place, this case occupies the product owner and the team. The product owner always has to trade an increasing velocity against the higher costs (caused by the larger team). On the other side, the team is able to judge, to which extent further team members would reasonably help.

Diminishment of the team

In the project business, there is “idling” from time to time. The reasons are very different, for example, all further tasks are dependant on a specialist task, so that they are blocked. At the sprint end, the sprint-backlog is empty or even the project end is characterized by an empty product-backlog. Moreover, in most cases projects only allow a limited parallelization. This can vary in the course of a project and in this way it can cause “idling”. The “idling” can be a spontaneous phenomenon, or it is of systematic nature.

The first task is to recognize that there is a systematic “idling”. This is the turn of the team and scrum master. Then, a suitable solution has to be found, preferably (and in most cases, this is also possible) in the current team, for example by reshaping of the tasks, in order to by-pass the specialist shortage.

But especially when the end of a project is near or a high parallelization, which has been used so far, is not applicable, it makes sense to diminish a large team.

Maybe the team can decide, which new team size would be suitable, but I think it is not clear, who will define the team members, who have to leave, and in which way.

Low Performers and troublemakers

In my view, one of the more difficult tasks in the project management is dealing with team members, who do not show the required proficiency level or who disturb the teamwork vehemently and constantly. One advantage of scrum can be the self regulation within the group. However this would require according social skills and a good standing of the other team members. But you can not assume that this alone is going to save the situation. Then it is the turn of the scrum master to recognize such things, to bring them up and to press for a solution. In such situations, the last resort will be to exclude the according team member, but it is not clear, who will be allowed to make this (very hard and final) decision.

Conclusion

Also in this area the tasks are divided to the new roles. Especially for difficult decisions, but also in the initial phase of projects, the “conventional project leader” can be missed despite it all.

Author

Marc Clemens

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Good post.

    Scrum is a flat organization. The three roles are responsible (and thus have authority) for different aspects of development. The Product Owner decides what features to build and in what order, the team decides how to implement those features, and the Scrum Master is responsible for the development process. But no one is “above” the other.

    This is both a strength and a disadvantage of Scrum. When things get rough and members have to be excluded, there’s no formal authority to handle it.

    Thus, Scrum is heavily dependent upon strong informal leadership. Often, this leadership can be found with the Scrum Master — coaches are generally good leaders — but leadership could be provided by any of the three roles.

Comment

Your email address will not be published. Required fields are marked *