Introducing Scrum to Service Teams
Considerations for introducing Scrum to service teams
I work in an area composed of teams that support production applications, processes, and services. Most of the analysts on those teams have a long tenure. The team I work on also provides support however; we worked on a project in 2007 using Scrum to enhance our systems. After that project completed, my team continued the use and benefit from Scrum for service work (i.e. periodic and preventative maintenance, minor enhancement requests, problem management, knowledge transfer and transition of services).
It is my intention to introduce Scrum to the other teams in my area for the management of their service work. I believe they can benefit from it as my team has. I have been warned, however, that this may be hard for the other teams accept since it is not being introduced to them through a project. This Open Session discussed challenges and recommendations related to introducing Scrum to other Service Teams.
Challenges to Introducing Scrum to Service Teams
- Scrum makes the work of individuals visible to others. Individuals may take the added visibility as micro-management of their work or a threat to their long-standing duties, way of thinking, and working.
- Some may not want to be bothered with the change Scrum introduces for personal reasons, for example, being close to retirement.
- For the individual that has just been doing "their job" and keeping to themselves, they might find Scrum and the stand-up meetings boring because they don't care what others on the team are doing.
- Management and teams will most likely see this as yet another process being added to an already long list of processes and procedures they have to follow.
- Scrum cannot be forced; a team must have a reason for wanting to use it.
- Management must be sold on it first and be willing to let the team self-direct.
- Approach management and their teams to identify the problems and pain points they face. Ask the "why" questions (5 times) to help them start thinking.
- Discuss how Scrum can address their problems, how it can make them more effective as a team, how it offers less pain or pain avoidance compared to what they are experiencing now.
- Give success stories as examples of how this has already worked in your organization.
- Introduce the practices slowly. For example, start by making problems visible (i.e. problem board), then move to meeting regularly, etc. These can be introduced without mentioning Scrum.
- Scrum will not be applicable to some team situations, for example where all a team does is fix bugs as calls come in.
- A team’s situation/scenario will help the team determine the frequency of stand-up meetings however, it is recommended they be daily at least initially.
- Sprint planning must account for unplanned work (i.e. incidents, emergency fixes).
- Having multiple teams where a team can be dedicated to taking production problem calls can insulate other teams using Scrum from unplanned noise. This works best when the expertise needed to handle a call resides in the team receiving the call.
Benefits of Using Scrum in Service
- The work of the team is visible; all team members know what the other members are working on, where other team members are having trouble, and are more immediately responsive to assisting other members in need.
- They prioritize and work together on common theme/mission instead of disparate products based on individual priorities. The team is more accountable to sticking with the prioritized work; individuals cannot as easily work on informal enhancement requests sent directly to them on the side.
- Scrum makes needed work visible/available and helps service organizations having people who would otherwise not know what to do next. People can go to the task board if they need work.
- Individuals that traditional work on unrelated features related to a given product can still work and think collectively, for example, in testing.