This document summarizes some of the key challenges in building and managing self-organizing Scrum teams. It discusses challenges such as dealing with team member inertia, personality clashes, and the time-consuming nature of Scrum events. It also addresses managing issues like lack of traditional reporting systems, low accountability of Scrum Masters, and stakeholders feeling a loss of control over teams. The document recommends selecting the right Scrum Masters and ensuring collective team participation and transparency to help address these challenges.

1. Managing Self-Organizing
Scrum Teams
W H I T E P A P E R
Abstract
This white paper from Impetus Technologies talks about self-
organization in Scrum, one of the most popular and widely used
Agile methodologies.
It discusses how Scrum encourages the creation of self-
organized, empowered teams where the team members have
more freedom vis-à-vis the traditional environment. At the same
time, the white paper also focuses on how with Scrum, leaders at
all levels have a challenge to balance this freedom with the need
for predictable outcomes.
The white paper introduces self-organizing teams and highlights
the problems and solutions for building and sustaining these
teams.
Impetus Technologies Inc.
www.impetus.com

2. Managing self-organizing Scrum teams
2
Table of Contents
Introduction...........................................................................................................3
Challenges associated with building self-organizing teams...................................3
Inertia.................................................................................................................4
Different personality types................................................................................4
Personality clashes within the team..................................................................4
Distributed teams ..............................................................................................5
Multi-organizational teams................................................................................5
Challenges associated with managing self-organizing teams...............................7
Participation of all team members in Scrum events is time consuming ...........7
Scrum has no traditional measurement and reporting systems .......................8
Low accountability of Team Masters.................................................................8
Loss of control of stakeholders and key executives over the team...................9
Selecting the right Scrum Masters.....................................................................9
Summary..............................................................................................................10

3. Managing self-organizing Scrum teams
3
Introduction
Scrum advocates self-managed teams. The team members of Scrum projects
expect autonomy and a higher degree of freedom. The self-organizing team is
one of the challenging concepts in Scrum. All the practices/events that Scrum
mandates need to be run by the team members themselves, rather than by the
leader, and this can prove to be problematical.
The Scrum teams are empowered and participate actively and collectively in all
activities. The Product Owners usually explain to the Scrum teams what is
required in the next sprint, and the teams work out details such as who will
work on what, as well as, how much time is needed, and consequentially, how
much work can be taken up in a particular sprint.
The detailing, and planning is undertaken by the teams, and the Scrum Masters
are there to help them, if required. In that sense, technically, the Scrum teams
are ‘self-directed,’ as opposed to ‘controlled from the top.’
The biggest factor responsible for building and maintaining self-organizing
teams is a sharing and learning environment and there is more learning here
than in a traditional scenario. Scrum recommends that people within the team
interact and share their learning and knowledge with each other. This way, they
continue to learn from peers and seniors account of the proximity and bonding.
Scrum brings together a team with different exposure levels, experience and
backgrounds and encourages bonding through frequent interactions. In a
situation for instance, where one member is unavailable due to an emergency,
another is likely to come forward and volunteer to do that person’s tasks on
account of the team bond and the shared commitment to the sprint goals. This
is made easy by the fact that team members are aware of the tasks assigned to
their peers.

4. Managing self-organizing Scrum teams
4
Challenges Associated with Building
Self-Organizing Teams
There are several difficulties related to building self-organizing Scrum teams.
These are:
Inertia
Organizations may be tempted to decide not to let go off the practices they
followed in the traditional methodology; thereby, adopting a watered-down
version of Scrum.
Our recommendation
Impetus recommends that the leaders and decision makers do not give in to
such temptation, and instead understand the reasons why Scrum is insisting
on these rules and explain them to all concerned. They also need to
mandate that all the rules and guidelines be followed consistently.
Different personality types
In the workplace, there are different kinds of people—loners, who prefer to
work on their keyboards all day without surfacing for meetings or other
interactions with colleagues—and the social team members, who can spend
endless hours interacting, discussing and comparing notes with co-workers.
Similarly it is possible to have aggressive people, as well as passive people in
one single team.
Our recommendation
Therefore, while building the team, leaders should pay attention to the
personality types they are bringing into the mix. They must avoid having
similar kind of people, but at the same time, also look at how they can bring
together people with different dispositions.
At the same time, bringing together people with extreme temperaments
may have an adverse effect on team productivity and morale. According to
Impetus, leaders may need to shuffle teams multiple times to find the best
team composition.
Personality clashes within the team
The Scrum teams are cross-functional, which implies that the developers,
testers, technical writers, etc. have to work closely. In this scenario, team
members who have previously worked on non-Scrum projects may bring
with them their old prejudices and notions. This can potentially create
clashes. Sometimes, developers and testers in a Scrum team find it difficult
to work with each other as they still expect the work to be handed over to

5. Managing self-organizing Scrum teams
5
them in a formal manner. The intimacy and speed that Scrum insists on just
does not leave room for such luxuries.
Another issue is that in Scrum, all the team members are called developers,
irrespective of their roles. Therefore, though there are test engineers for
testing the code or technical writers for documentation, there is no
demarcation by way of separate titles. Everyone is treated the same and is
called by the same name. Though this is a good practice for creating bonds
within the team, it may also challenge the identity of some roles.
Our recommendation
In order to overcome personality clashes, Scrum itself insists on doing away
with the numerous hierarchical layers within the organization, and adopting
a relatively flat structure.
Distributed teams
In an ideal scenario, the Scrum teams get the maximum benefit of a close
interaction if they are co-located. However multi-location teams are a
reality today. While they pose special challenges, it is possible to overcome
them and encourage smooth and transparent interactions within the teams.
In case of multi-location teams within the same organization, the problems
are easily addressed as the organization culture, practices and management
is the same across the locations.
Our recommendation
However, to facilitate seamless interaction within multi-locational teams,
organizations must provide for high-quality communication infrastructure. It
would also make sense to have people travel and spend time with their
team-members at other locations.
The situation can be further improved by encouraging informal interaction
among team members that go beyond task discussions. They can just chat
about common interests over and above work, such as sports, families,
children, etc. This practice actually facilitates the building of rapport and
empathy. The more Scrum Masters encourage a common shared language,
the easier becomes the flow of communication.
Multi-organizational teams
In offshore software development, occasionally the Scrum teams may be
constituted by multiple service vendors. In this case, the teams are
distributed not only across locations but also through organizations,
cultures and time zones, therefore increasing the problems.

6. Managing self-organizing Scrum teams
6
Scrum says that the Product Owners are the only people accountable and
responsible for managing the product backlogs. This of course, necessitates
their close interaction with the teams. The challenge comes in when the
Product Owners and the teams belong to different organizations or cultures.
Since the Product Owners are the ones sharing the project requirements
and the priorities with the teams, they need to be available as and when
required. In addition, when there are people from multiple organizations
and different work cultures involved in projects, facilitating proper
communication is of prime importance.
Our recommendation
Apart from following all the Best Practices of inter-cultural communication,
it is imperative to encourage openness and tolerance to different ways of
working. Impetus suggests that the Scrum Masters act as proxy Product
Owners as they are close to the teams and well aware of their needs.
This does not mean however, that the Scrum Masters will have the
authority to prioritize the product backlog items. It just implies that these
people will act as bridges between the teams and the Product Owners.
Impetus has seen this solution work in many of its projects.

7. Managing self-organizing Scrum teams
7
Challenges Associated with Managing
Self-Organizing Teams
While building self-organizing teams is difficult, sustaining them is even tougher.
Some of the typical challenges cited in managing such teams are as follows:
Participation of all team members in Scrum events is time consuming
One of the most common arguments against having all team members
participating in important Scrum events are that it can be time consuming,
thereby impacting the productivity of individual team members. However,
experience shows that collective participation in sprint planning meetings
can actually help team productivity.
Sprint planning meetings are the time when the teams go into the details of
the product backlog items proposed by the Product Owners for the coming
sprint. Though it may appear that it would be more efficient to carry out this
activity in a smaller group, the collective participation of all team-members
facilitates enhanced knowledge sharing. The teams can eventually come up
with much better estimations and plans.
Our recommendation
According to Impetus, preparing for the sprint planning meetings, where the
teams can start their orientation process by gathering pertinent information
and requirements from the Product Owners or business analysts is a must.
The planning meetings get everyone on the same page and facilitate
awareness and understanding. Furthermore, having all people present and
aware about the tasks they have to achieve can be useful in case a particular
team-member is not available.
Another factor is that user stories are very rarely independent. There is
some connection, some dependency, and some interrelation all the time. In
such cases, having a bigger picture of what other people have to do, and the
ideal outcome of the user story, helps immensely.
The learning and exposure that team members get by actively participating
in all the events considerably reduces the rework and delays. It also enables
them to take proactive decisions and actions. This results in higher
productivity.

8. Managing self-organizing Scrum teams
8
Scrum has no traditional measurement and reporting systems
Scrum does not require status reports or measurements. It says that the
work remaining and date of review are the only variables of interest but
they must be religiously updated every day. However, leaders coming in
from non-Scrum backgrounds tend to be uncomfortable with the absence of
exhaustive measurement systems and detailed status reports. This does not
mean that there is a lack of information pertaining to the current project
status. It is just that it is not available in the format that leaders are
accustomed to. Rather than the information coming to the leaders as status
reports, they have to go and actively seek it out.
Our recommendation
Scrum encourages a high level of visibility and transparency. The daily
updated sprint backlog contains the current status, whereas the burn-down
chart gives out the early warning signals. Incidentally, it can also be used to
ensure that the team completes the tasks within the stipulated time frame.
The intermediate review of deliverables as and when they are available also
helps in gauging whether the project is on the right track.
Low accountability of Team Masters
Scrum says that the selection of product backlogs for the sprint is solely the
work of the development team, and not an individual or any external
stakeholder. It also mandates that Scrum Masters ensure that the
development teams have a daily standup meeting, though they do not
conduct the same. Essentially, the role of the Scrum Masters is very limited
in terms of accountability.
Scrum states that it is the team that is accountable for any mistakes, and
not a single individual. This can potentially develop into a very serious
problem.
Our recommendation
The solution to this lies in ensuring that team members identify with the
team and consider themselves as part of a unit. They must consider the
team’s success as their individual success and the team’s failure as their
own failure.
Active and collective participation by all members in all the team events is
critical to create this bonding. Though the team is likely to forego this very
important practice, the management should firmly support it.
The daily standup meetings and the sprint-end reviews and retrospective
meetings should be effectively used to curb the practice of passing the buck.
Blame-games should be discouraged in order to build the right culture from

9. Managing self-organizing Scrum teams
9
the start itself.
Also, the Scrum Masters need to identify the weakest links within the teams
and get them in line with the other team members. If required, they can
even rotate them outside the team.
Loss of control of stakeholders and key executives over the team
Scrum provides a well-protected and secure environment for the team to
work in. It says that self-organizing teams must choose the best ways to
work. And though people outside the team may share their well-meaning
advice, the teams ultimately have to decide what makes sense to them and
why.
Though this can be highly empowering for the team members, it may also
lead to external stakeholders feeling a loss of control over the teams as they
are accustomed to telling the project teams what to do, and by when.
The problems arise when the external stakeholders are comparatively
senior in terms of experience and designation vis-à-vis the Scrum team
members and do not take well to their suggestions getting bypassed.
Our recommendation
The solution lies in bringing about a mindset change among the external
stakeholders by explaining to them how freeing and empowering the teams
can pay rich dividends in the long run. They are likely to feel more
comfortable when they know that there are no risks on the way to sprint
success. They can refer to the daily updated sprint backlogs and the
accompanying burn-down charts. Armed with this information, they can
carry out intermediate reviews with the Product Owners.
Selecting the right Scrum Masters
Scrum Masters are considered servant leaders by Scrum. Scrum places low
importance on the top down hierarchy, giving greater autonomy and
freedom to the team. Scrum Masters no longer have the benefit of their
status and respect that automatically comes in with their position. They
have to earn it by serving the team, and that completely changes the focus
of their work. A self-organized team takes over a lot of their traditional
work of planning and monitoring, whether it relates to the tasks or people.
They are now free to use their time to help team members develop
themselves. They can also contribute to the progress of the projects by
using their experience and reaching out to team members and solving the
problems that hold up their work. They can enjoy the close bonds that they
build with team members, not because of their status, but rather due to
their role as guides and facilitators.

10. Managing self-organizing Scrum teams
10
It is important to point out that this does not mean that the position of the
Scrum Masters is any less important. They can now add a lot more value,
not just to the team and the Product Owners, but also to their
organizations.
Our recommendation
The challenge emerges if the people chosen to be Scrum Masters are
uncomfortable with their new role and have different expectations from the
people around. If the people come from a command and control culture,
they will find it quite tough to adjust in the Scrum project. As a result, the
whole project can suffer.
Therefore, it is very important to choose the right people to be the Scrum
Masters.
Summary
The Scrum practice has defined the rules for Scrum teams to follow and allowed
them to choose their own operational strategies. Following prescribed Scrum
rules makes things more efficient and disciplined. Altering these rules may
provide short-term gains, but may result in disadvantages in the longer run.
About Impetus
Impetus is a Software Solutions and Services Company with deep
technical maturity that brings you thought leadership, proactive
innovation, and a track record of success. Our Services and Solutions
portfolio includes Carrier grade large systems, Big Data, Cloud,
Enterprise Mobility, and Test and Performance Engineering.
Website: www.impetus.com | Email: inquiry@impetus.com
© 2013 Impetus Technologies, Inc.
All rights reserved. Product and
company names mentioned herein
may be trademarks of their
respective companies. May 2013