WHITE PAPER

Managing self-organizing Scrum teams

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 selforganized, 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 April 2012

Managing self-organizing Scrum teams

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

Managing self-organizing Scrum teams

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 persons 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.

Managing self-organizing Scrum teams

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 peopleloners, who prefer to work on their keyboards all day without surfacing for meetings or other interactions with colleaguesand 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

Managing self-organizing Scrum teams 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.

Managing self-organizing Scrum teams 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.

Managing self-organizing Scrum teams

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.

Managing self-organizing Scrum teams

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 teams success as their individual success and the teams 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
8

Managing self-organizing Scrum teams 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.

Managing self-organizing Scrum teams 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 Technologies offers Product Engineering and Technology R&D services for software product development. With ongoing investments in research and application of emerging technology areas, innovative business models, and an agile approach, we partner with our client base comprising large scale ISVs and technology innovators to deliver cutting-edge software products. Our expertise spans the domains of Big Data, SaaS, Cloud Computing, Mobility Solutions, Test Engineering, Performance Engineering, and Social Media among others. Impetus Technologies, Inc. 5300 Stevens Creek Boulevard, Suite 450, San Jose, CA 95129, USA Tel: 408.213.3310 | Email: inquiry@impetus.com Regional Development Centers - INDIA: New Delhi Bangalore Indore Hyderabad Visit: www.impetus.com

Disclaimers
The information contained in this document is the proprietary and exclusive property of Impetus Technologies Inc. except as otherwise indicated. No part of this document, in whole or in part, may be reproduced, stored, transmitted, or used for design purposes without the prior written permission of Impetus Technologies Inc.

10