The Scrum Team

Table of Contents

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.)

Tags

Related Posts

Natural Order of Refactoring Explored Part 2: Compose Method

Compose Method

Analyzing methods, such as the one presented in Part 1, often leads us to understand the main points of the algorithm contained in them. This insight paves the way for the next step: try to split a large method into smaller steps by extracting them into separate methods (refactoring using the Extract Method). Thus, the original method will consist of a sequence of calls to these new methods. With the right naming conventions, you can achieve code that reads like a book.

Read More

Natural Course of Refactoring online on InfoQ

I am so delighted that the article about Natural Course of Refactoring is live. It is a very simple, yet powerful idea about refactoring (but not easy after all) and I hope this way it will reach more people than ever before. So please retweet it and share it wherever you can.

Read More

Code Cleanliness: More Than Just Refactoring Part 1

Initially, my intention was to create an article about refactoring. However, the more I pondered the subject, the clearer it became that I would not be writing solely about refactoring. It’s about something much more significant—conveying a vast amount of knowledge, essentially experience, related to code creation. Code that not only works or is well-designed but is most importantly easy to read. When we achieve this skill, we stand on the threshold of professionalism. Programming professionalism.

Read More