In today’s software development environment, requirements often change during the product development life cycle to meet shifting business demands, creating endless headaches for development teams. We discuss our experience in implementing the Scrum software development process to address these concerns.
The Scrum Software Development Process for Small Teams
LindaRising and Norman S. Janoff, AG Communication Systems
t AG Communication Systems, software development teams range in size from two to several hundred individuals. Intuitively, the development process that’s appropriate for very large teams won’t work well for tiny teams and vice versa. In our organization, process diversity means adopting a flexible approach to development processes sothat each team can apply what works best. In experimenting with the Scrum software development process, we found that small teams
ing from projects at our organization that faced significant challenges. In the new telecommunications market where our company operates, change is overwhelming. Software developers have always complained about changing requirements, but in traditional approaches theyassumed they would understand the requirements before moving on to the next phase. In the current environment, however, project requirements might be unclear or unknown even as the project gets underway. Indeed, the market might not be defined—it might even be that no one clearly understands the product under development. Most development teams respond with, “Make the chaos go away! Give us betterrequirements!” Unfortunately or not, chaos is the reality in this new business environ0740-7459/00/$10.00 © 2000 IEEE
can be flexible and adaptable in defining and applying an appropriate variant of Scrum. This article describes our experience implementing this process. Why Scrum? As members of the Software Technology Group, our group is responsible for introducing new technologies and processesinto our organization at AG Communication Systems in Phoenix, Arizona. We research new approaches and sponsor their introduction and growth. We also conduct development project checkups for ongoing projects and postmortems for completed ones. In our periodic postmortems and checkups, we noticed some recurring problems for our New Business Opportunity (NBO) projects. Figure 1 lists some commentsaris-
Figure 1. Participant comments from projects facing challenges.
I I I I I I I I I
ment—as software developers we must learn how to meet customer needs and turn this chaos to our advantage. In seeing that some of our NBO projects were more successful than others, we struggled to examine the postmortem data to learn the secrets of thosesuccessful projects. Here are some comments from successful teams:
We need to do a better job of change management. We had too many outside distractions. We need customer feedback during the iterative development approach we’re taking. The users gave us a huge list of requirements. We knew we weren’t going to be able to deliver everything they wanted. Development took place in focused chaos, andthere was no one to go to with questions. We need a way to structure the chaos somehow, because all NBOs must deal with that. We have been used to thinking in terms of years for development; now we have to turn out products in months. We’re chasing an emerging market. It changes weekly. We wasted a lot of time estimating and developing test plans for features that we never developed. We shouldhave cancelled this project earlier. It took almost two years to recognize that. We need well-defined phases and someone who is close enough to see progress and determine what we can check off.
What’s a Pattern?
In the late 1970s, two books appeared, written by Christopher Alexander and his building architect colleagues. The Timeless Way of Building and A Pattern Language presented Alexander’s...