The Scrum Software Dev for Small Teams
focus
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.
process diversity
The Scrum Software Development Process for Small Teams
Linda Rising and Norman S. Janoff, AG Communication Systems
A
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 so that 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 they assumed 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 better requirements!” 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 processes
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.
process diversity
The Scrum Software Development Process for Small Teams
Linda Rising and Norman S. Janoff, AG Communication Systems
A
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 so that 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 they assumed 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 better requirements!” 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 processes
References: 1. M. Beedle et al., “SCRUM: An Extension Pattern Language for Hyperproductive Software Development,” Pattern Languages of Program Design 4, N. Harrison, B. Foote, and H. Rohnert, eds., Addison-Wesley, Reading, Mass., 2000, pp. 637–651. 2. B. Goldfedder and L. Rising, “A Training Experience with Patterns,” Comm. ACM, Vol. 39, No. 10, Oct. 1996, pp. 60–64. 3. N.S. Janoff, “Organizational Patterns at AG Communication Systems,” The Patterns Handbook, L. Rising, ed., Cambridge Univ. Press, New York, 1998, pp. 131–138. 4. J.O. Coplien, “A Generative Development-Process Pattern Language,” Pattern Languages of Program Design, J.O. Coplien and D.C. Schmidt, eds., Addison-Wesley, New York, 1995, pp. 184–237. 5. F.P. Brooks, The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, New York, 1995. 6. L. Fried, “When Bigger Is Not Better: Productivity and Team Size in Software Development,” Software Engineering Tools, Techniques, Practice, Vol. 2, No. 1, pp. 15–25. 7. B.W. Boehm, “A Spiral Model of Software Development and Enhancement,” Computer, Vol. 21, No. 5, May 1988, pp. 61–72. About the Authors Linda Rising is the editor of The Pattern Almanac 2000 (Addison-Wesley) and A Patterns Handbook (Cambridge Univ. Press) and was also the feature editor for a special issue of IEEE Communications on design patterns in communications software, which appeared in April 1999. She is interested in patterns and processes for software development and has worked in the telecommunications, avionics, and strategic weapons systems industries. She has a PhD from Arizona State University in the area of object-based design metrics and is a member of the ACM and IEEE Computer Society. Contact her at risingl@acm.org. Norman S. Janoff is a software project engineer at AG Communication Systems in Phoenix, Arizona. He has worked as a software manager on a large telecommunication switching system and as a software engineer. His current research interests include software processes and software metrics. He received a BS in electrical engineering from the University of Michigan, an MS in electrical engineering from the University of Illinois, and an MBA from the University of Chicago. Contact him at AG Communication Systems, 2500 W. Utopia Rd., Phoenix, AZ, 85027; janoffn@agcs.com. 32 IEEE SOFTWARE July/August 2000 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.