The Scrum software development process for small teams

Author(s): L. Rising, N.S. Janoff
Venue: IEEE Software, Volume 17 Issue 4
Date: 2000


AG Communications develops software and needs to be able to adapt to meet the needs of their new clients. AG Communications has determined the following problems are currently impacting their ability to serve their clients: unclear ownership of problems, not enough user feedback, too many features, and inability to accurately measure progress. Three teams adopted Scrum and will be labeled as A, B, and C.
Team A was responsible for developing a multi-platform simulator for the companies switching system. Team A decided to utilize one month sprints and minimize daily meetings to once every other week day. The team saw immediate success completing their first sprint on time. They were able to unite together to solve an individuals current problem they were stuck on with the frequent meetings. The meetings are meant to be short so it was important to identify the problem at the meeting so that people could volunteer to share their experience after the meeting. With small tasks constantly being completed team members had a way of measuring their own progress.
Team B developed a new product in a small call center market. Team B created a backlog of items to work on that had to be changed very early on because the company decided to make a major strategic change. This is important because changing the backlog in the middle of a sprint is not part of the Scrum development process. The team learned that a process should never get in the way of making good decisions for a project. Team B encountered further trouble as they had many responsibilities outside of the sprint. There were varying levels of success completing the tasks assigned to each individual with some completing the whole task and others only partial completion.
Team C worked on testing and bug testing for a new product feature. Team C chose to have 30 minute meetings on a daily basis. The daily meetings helped with load balancing allowing people to volunteer to pick up additional work based on their free time. The meetings also allowed the Scrum Master to share any information that needs to be circulated around the entire team to keep them on the same page.
This study did a good job of addressing both the successes of using Scrum as well as the failures. It demonstrated that it is not a good idea to have a member of a Scrum team that is working on additional tasks outside of what they are assigned during a sprint. Sprints are intended to be quick and adaptive to strike a workload balance that keeps all team members busy. Another possible reason for Team B's difficulties could be a poor breakdown of the backlog into tasks that someone can accomplish in one sprint. This study would have been more useful if it had contained more data about the skill level of members working on each team or a larger number of teams to create a more diverse sample.