We’re Scrum shop, and Scrum definitely has its share of “good fences” that are designed to make Scrum work. In fact, looking for how the boundaries of these fences are being violated can help you identify problem areas in your Scrum implementation.
There are three roles in Scrum: Product Owner, ScrumMaster, and Team Member. While lacking an officially acknowledged role, management plays an important supporting role and can be a significant factor in the success or failure of a Scrum team by either violating the boundaries or failing to support the team.
The Product Owner is responsible for defining what needs to be done along with establishing the relative priorities< of that work. An important boundary of the Product Owner’s role is that the Product Owner doesn’t dictate what the solution will be to the team. The Product Owner supplies the user stories to the team that describes what is desired and the benefit to be achieved from the user’s perspective – and the team supplies the how. Metaphorically speaking, both the team and the Product Owner should be meeting at the fence to talk (collaborate) and shape the solution.
The ScrumMaster is responsible for guiding the team in its implementation of Scrum practices, doing whatever he or she can to facilitate the productivity of the team. The ScrumMaster’s boundary is the he or she is not a project manager or a proxy for a manager who is assigning tasks or otherwise controlling the team. The ScumMaster is a facilitator, impediment-remover, and protector of the team. The ScrumMaster is the one who (keeping with the metaphor) erects a fence around the team and protects them from outside distractions while helping them orchestrate their work within that boundary.
The team is an autonomous, self-directed entity that is responsible for delivering working software at the end of every sprint and has the right to do whatever it takes – within the organizational or project constraints – to reach the sprint goal. A team cannot, for example, reach out past their “fence” to pull in other resources independently. Teams typically do not have the authority to “vote people off the island,” either. Not without working with management.
Each team member must focus his or her efforts on contributing to the team’s success over and above individual desires or goals. A team member should not be erecting a “fence” around his or her job title or specialty, but seek to contribute to the team’s success in any way possible.
Management must recognize and respect the “fence” that exists around the autonomous team. This means management must avoid doing things like assigning tasks to individuals who have already made commitments to their team, but instead seek to support the efforts of the team by doing things like working with the ScrumMaster to help remove impediments.
Management must also support teams by making sure that teams are staffed with individuals with the right knowledge and skills to make the team successful, taking care to set performance objectives that are in alignment with the Scrum team; individual performance plans should make it clear that Scrum team members have a team first mindset, calling out the technical skills, domain knowledge, and behaviors required to be a good team player. Failing to make adjustments to performance plans can place individuals in conflict – and people will choose that impact their individual performance reviews and raises over team goals every time.
Another important role of a manager is to take swift and sure action to remove non-performing or problem people from the team. The ideal size for a Scrum team is five to seven people, and one bad seed can easily bring a team of this size down. This brings me to my next point.
Management can be a big supporter when it comes to guiding the behavioral changes required to be a Scrum team member. Being a member of an autonomous team – without management breathing down your neck – generally has appeal to people. However, the behavioral changes that come with the territory are both different and uncomfortable for some people.
Some don’t want to let go of being specialists. Others – even though they have been part of project “teams” before – aren’t comfortable with taking on work without someone assigning it to them. There may be people who aren’t used to collaborating and may lack effective communication skills to participate effectively with others – or to speak up to constructively to hold others accountable. (Not everyone understands how to keep feedback depersonalized or how to constructively inquire about why something isn't getting done.)
Management should definitely play a mentoring/coaching role with people, guiding them and teams through these behavioral changes. Brining in training and outside facilitators can also be a big help. Understanding the nature and boundaries of Scrum roles is critical to a successful implementation of Scrum. Great execution is harder than it first appears, particularly as Scrum spreads and involves more than the willing, early adopters.