A Scrum Team is not just a set of random people that work in the same company. It is a specific group that meets a bunch of conditions. Rules and guidelines of Scrum Teams creation are well described by Scrum methodology. I have talked to different people about it over the years and I noticed that there is a set of common misunderstandings regarding Scrum Teams. If you look around, you may notice some of them.
Sin #1 - silos of competencies
It happens when a company wants to be Agile but does not understand the philosophy yet.
Symptoms:
- if you notice a team of DBAs, a team of Java developers, a team of business analysts, this is the case,
- employees with the same competencies are grouped together so they could work on the same set of tasks.
It is a sin because a Scrum Team does not work on tasks. It works on user stories which require various competencies not just one set. A Scrum Team must be cross-functional which means that it should include people with different competencies so they could cope with any user story without engaging specialists from outside the team.
Sin #2 - too small team
Symptoms:
- work cannot be peer reviewed as there is no second person in the team with similar competencies,
- even when one person takes a day off, completing user stories becomes problematic not because of reduced team capacity but lack of competencies.
The latest Scrum Guide recommends to have a team with 3 to 9 members. Although 3 is not prohibited in Scrum, it does not make sense in some cases. It may work fine when user stories do not require a wide spectrum of competencies, for example the application uses Java without any sophisticated database. Hiring real full stack developers also justifies 3 as a team size. But if you observe above symptoms, profoundly think about expanding the team.
Sin #3 - too big team
Symptoms:
- it is hard to finish Daily Scrum meetings in 15 minutes,
- team members get bored and check emails on their phones during Daily Scrum meetings,
- people do not feel they have a common sprint goal,
- sprint planning is difficult as the team is not sure how many stories they can handle.
Maximum team size allowed in Scrum Guide is 9. If your team is larger, you should definitely try splitting it. Even if it fits the range but you observe the symptoms, consider splitting it. Connections between members in big teams are weaker. It is more difficult to self organize in a big group so you loose efficiency.
Sin #4 - multiple Product Owners
Symptoms:
- arguments about priorities on Spring Planning meetings,
- last minute changes in the backlog made by one Product Owner that surprise the other one,
- inability to order the backlog because it is difficult to say which of these items are less important.
A team must always has one and only one Product Owner. Scrum Team with a proper size is able to work on items from only one Product Owner. If you think differently, you are probably missing a business analyst not the second Product Owner. It is important to have only one PO to avoid conflicts in priorities.
Sin #5 - no Product Owner
Symptoms:
- the backlog is a mess,
- the product has no vision, the team does not understand it's business value,
- nothing important to show on Sprint Review meeting; people are constantly dissatisfied with the product increment produced in each sprint.
Product Owner is necessary to assure that sprints are invested in the right place. Without a strong PO role, a team may work for a long time, making unnecessary and minor changes to the application without increasing it's business value.
Sin #6 - remote team members
Symptoms:
- waiting on a Daily Scrum meeting to discuss topics instead of reaching out a person,
- a lot of misunderstandings and forgotten actions,
- some decisions and arrangements do not reach all team members.
Remote team members makes team communication harder even if you try as much as you can to prevent it. Discussing everyday work over a phone or a video conference can be effective but not as effective as a face to face conversation. On the other hand, it does not mean that the whole company must be collocated. If employees are spread over the world for some reasons, teams may be formed locally so each group has local members. For example. Team A, B and C are located in Germany, Team D is located in Brazil. Avoid mixing members from different locations.
Although, a Scrum Team can be created with a minimum amount of effort, it is crucial to do it wisely. I hope the above anti-patterns will help you avoid common mistakes in following Scrum. Good luck!
Check also other anti-patterns in Scrum: