The Scrum Team

Team, team, team… It’s time to delve into the subject of the team, after discussing the topics of Product Owner and Scrum Master. This subject can be explored from many different angles. However, that is not the point.

Key Points

• The team should be small - because communication is simpler and it’s easier to organize.

• The team is not a mix (“In project X I am 30%, in project Y 50%…”), this doesn’t work, people are disengaged and frustrated. It’s better to organize one team that does two projects.

• The team forms over months - if the so-called team is formed for 2-3 month projects, and then dissolved, there is no real team. Just a group of people. Team mechanisms do not work then.

• Distributed teams are a big challenge and do not often work well. International distributed teams (especially in different time zones) never work well. NEVER. I have not seen such a team, and I’ve seen quite a few. It’s not a matter of the ability to organize such a team. Mixing different nationalities working remotely is not a good idea - the spatial barrier is greatly amplified by the language and cultural barrier.

• The team must have a clear majority of experienced and competent people over inexperienced ones. Although even with students, it’s possible to create a great team, it takes a lot of effort (so much that it becomes unprofitable).

• Should the team be self-organizing? Many factors are needed to have a good base to lead to such a form of team operation, and this rarely happens. Therefore, the key thing is that:

Conclusion

People co-creating the team, should at least co-decide on what happens during the implementation of features (including what can be done, in what time, how, and how to organize their work).

Amen.

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)