A Team Member is defined by their commitment to the goal(s) of the Scrum Team. If a person is not personally committed, they are not part of the team. Commitment cannot be imposed. A person’s manager can’t force them to be part of the Scrum Team by telling them to be committed. If all the members of the team are committed to the Sprint goal, then they will all work in whatever way is necessary to accomplish that goal. This commitment willingness to do what it takes is a key factor in creating a high-performance team. If any individual is not committed to the Sprint goal, they aren’t really part of the Scrum Team. Having someone how is not committed but is constantly interacting with Scrum Team members, who is doing work that is properly owned by the team, and who participates in team meetings as if they were a member of the team is incredibly disruptive. This “false” participation can cause morale problems if not eventually fixed either by the person becoming committed or by the person leaving the team. Having people who are on the team in name only will prevent a team from reaching a high-performance state.
A Scrum Team Member is aware of the work that other Team Members are doing, notices if others are struggling with their tasks, and if so, offers to help them. A Scrum Team Member is not just focused on their own personal tasks. This help can be offered as ideas, powerful questions, sharing the work of the task, or even offering simple encouragement. If Team Members are constantly seeking to help each other, this actively contributes to team cohesion, cross-training, and the development of a high-performance team environment. Of course, if people don’t help each other, then individual Team Members may struggle for a long time without making progress and overall productivity will be dramatically hindered.
All Scrum Team Members, including the ScrumMaster and Product Owner, should understand the high-level technical aspects of the product that is being built. As well, that understanding should be solid enough, that it can be communicated to other people. This understanding helps the team members in many situations dealing with each other and with stakeholders. Understanding the structure of the system is an aspect of Transparency. This is essential for maintaining overall quality of the product. Development in one part of the product or system should never cause problems for any other part of the product or system. If team members do not know their product in this way, it can cause significant problems in communication and in how Product Backlog Items are implemented.
All Scrum Team Members, including the ScrumMaster and Product Owner, should understand the high-level business aspects of the product that is being built. As well, that understanding should be solid enough, that it can be communicated to other people. This understanding helps the team members in many situations dealing with each other and with stakeholders. Understanding the purpose of the system is an aspect of both Focus and Transparency. This is essential for maintaining overall quality of the product. Development should always be done in a way that moves the system towards fulfillment of its intended purpose. If team members do not know their product in this way, it can cause significant problems in communication and in how Product Backlog Items are implemented. Finally, and perhaps most importantly, understanding the overall purpose of work is critical for a team to become a high-performance team. Without knowledge of this purpose, a high-performance team is impossible.
This report provides some excellent information about the state of Scrum based on a survey of over 500 professionals. I hope that the scope of this survey grows to include many more people over time so that the results are more reliable.
Here is one interesting quote from the report:
Insight #3: The long-term success of Scrum is about creating a culture and making Scrum principles and practices the “new normal.”
Lots of interesting data in the report that backs that up!
The link to the report as well as a webinar and presentation deck are available on the Scrum Alliance site.
Scrum is team-focused. Fixation on optimum (individual people) resource utilization is a major obstacles for effective Scrum implementation. Doing Scrum right and deriving the benefits of team-focus that it has to offer requires full-time dedicated membership of all team members. A Scrum team should be delivering the highest value product of an organization. Having team members assigned to other projects at the same time means that the focus on delivering the highest value is being disrupted. Furthermore, a Scrum team needs to be able to establish and maintain a constant velocity from Sprint to Sprint. This is impossible to do if team members are being shared with other projects and/or teams. Also, there is tremendous waste associated with task switching that is eliminated by this single rule. The hang-ups of resource utilization need to be left behind if an organization is to mature into one that is Scrum team-focused.
All Scrum team members must be committed 100% to the Sprint goal of their team. If people are trying to be on more than one team, then they are not able to be fully committed to the goal of either team. This means that neither team can be fully committed to the deliverables of their Sprint Plans. Failure to commit to the Sprint goal results in failure to deliver and a failed Sprint. When people are working on more than one Scrum team, the teams are being set up to fail at Scrum. This rule is often counter-intuitive to traditional project management, which tends to be obsessed with resource utilization. The problem with managed resource utilization that this rule of Scrum solves is the complete lack of commitment that it forces onto the people doing the work. Scrum creates a sense of ownership of the delivery of the whole product in each and every team member when they are allowed to work with one Team.