There are three roles on a Scrum Team, no more and no less. These roles are: ScrumMaster, Product Owner, and the Team Members. It is critical to have all three roles present on the Scrum Team to get all needed responsibilities taken care of in an effective way. The Product Owner is responsible for the product and how the team connects with that product. The ScrumMaster is responsible for improving the use of Scrum in the organization and team, as well as removing any obstacles that slow the team down. The Team Members are responsible for getting the work done by self-organizing and finding ways to improve their own process and work. Without one of these key roles, the team would be missing a key focus and job. As well, Scrum specifically disallows any other roles on the Scrum Team. A person who has an official role of Tester cannot be on a Scrum Team. However, the same person, if given the official role of Team Member can be on a Scrum Team. If people have their official titles, performance evaluations etc. done in their traditional roles, it hinders self-organizing and causes conflicts of interest. A team is not a Scrum Team until those old roles are eliminated.
A very effective learning that has come out of many fields of research is that we function well in small groups, specifically groups that range from five to seven people in total. Scrum allows for a slight expansion of that range up to eleven people. This allows for enough people to be together to discuss issues and solve complex software problems with a diversity of skills and experience. As well as avoiding the problem of having too many people that the lines of communication become overwhelming. If the Scrum Team is only four people, then that means that you only have two people doing the tasks in the Sprint Backlog (since the others are the ScrumMaster and the Product Owner). If the team is thirteen or more people then trying to discuss issues, having a focused Daily Scrum meeting, and even building an effective Scrum Team becomes that much harder. The larger the team, the longer it takes to get to a high-performance state.
The Product Owner brings Product Backlog Items to the Scrum Team to estimate their effort (cost). In order to create the right environment of safety and accountability, no Product Backlog Item is estimated by a single member of the Scrum Team, or even a subset of the team membership. By having all the members of the Scrum Team participate in the estimation work for every Product Backlog item, it becomes impossible to blame a single Team Member for a poor estimate. At a practical level, it is should be very rare that a single Product Backlog Item is fully implemented by a single Team Member. Therefore, estimates should consider the collective effort of the Scrum Team, and this can only be determined by having all the Team Members participate in the estimation work. If the team delegates estimation to a single person, or if one person dominates the estimation work, the other Team Members will not have ownership of the estimates and will be able to deny accountability. The pressure on the team from collective estimation encourages teamwork, cross-training and these behaviours in turn promote the development of a high-performance team.
The ScrumMaster organizes and facilitates the Scrum meetings, including the Sprint Review. The ScrumMaster ensures that all the stakeholders of the Scrum Team and its product are invited to the Sprint Review. The list of stakeholders invited should include, most importantly, end users of the product and / or actual external customers who would buy the product. The Scrum Team presents the product increment during the demo portion of the Sprint Review. This presentation allows the stakeholders to give immediate feedback on the product increment including new functionality, quality, and desired future direction. If the stakeholders are not universally invited, then it is possible that important feedback will be lacking and the Product Owner will create a sub-optimal Product Backlog. One significant benefit of having a broad group of stakeholders attend is that it is highly motivating to the Scrum Team to receive direct feedback every Sprint. This feedback is only possible if all the stakeholders are invited every Sprint.
The Scrum Team plans their work in the Sprint Planning meeting and that planned scope (Product Backlog Items) is meant to be respected… it is a commitment by the team. In exchange for that commitment, the rest of the organization commits to leaving the team alone to focus on its work. Focus and commitment are both important values of Scrum. Any interruption to any individual Team Member except the ScrumMaster and Product Owner is considered a cause for relieving the Team of its commitment. This rule of Scrum is designed to put pressure on the organization to leave the team to focus on the most valuable work. If the organization allows interruptions to the team’s work during the Sprint, then the team will not meet its commitments and this will diminish trust between the team and its stakeholders. That lack of trust will lead to onerous control mechanisms that reduce the team’s ability to self-organize which, in turn, will prevent the team from becoming a high-performance team.
The Daily Scrum meeting is a critical method for creating transparency between Team Members. Every day, each Team Member in turn answers the three questions of the Daily Scrum: what tasks have I completed, what tasks will I complete before the next Daily Scrum, and what obstacles do I have to doing my work? These questions are designed to ensure that all team members know what everyone else is doing regardless of if one or another team member thinks something is “important” to know. This transparency gives the team a regular rhythm of “Inspect and Adapt”. Since the Daily Scrum is meant to be short, any discussion of the work should be held until after the Daily Scrum is complete. To be clear: the Daily Scrum is not meant to be a problem solving meeting and treating it so can lead to people failing to be as transparent as needed (or to breaking the timebox for the Daily Scrum which leads to other problems).