Software development is a complex process, and few organizations manage to handle it properly from the outset. It’s no surprise to anyone in the IT industry that software project failure rates still hover near the 40 percent mark even after more than 60 years of industry experience in the field.
To outsiders, though, not only is that failure rate remarkable, but so is the fact that it has come down to that still-atrocious level from a high closer to 60 percent in the late 1990s. That decrease is no accident, and many industry experts attribute it primarily to one thing: agile software development practices.
The most popular of these, hands-down, is called “Scrum.” Forrester Research has determined that more than 90 percent of organizations that identity as “agile” practitioners use Scrum as their methodology of choice. And Scrum’s appeal extends beyond software development, these days, finding a home in lean organizations in roles as diverse as developing new radio programs (at National Public Radio) or building a new hyper fuel-efficient car (at Wikispeed).
The principles behind Scrum will not be foreign to any student of business familiar with conventional lean manufacturing or development practices. By using loosely coupled iterations of rapid development, Scrum seeks to manage risk by reducing wasted effort and maximize value by delivering working software rapidly. Whenever the details of the process start to look obtuse or confusing, return to those basic precepts: they are the heart of the practice.
You can use Scrum to manage almost any sort of project.
The heart of Scrum is the sprint. A sprint is simply a predefined segment of time, during which a subset of product features (called backlog items) will be built by the development team. The most common length for a sprint is about two weeks, although it can be as short as a day or as long as a month. You’ll have to determine the appropriate window for your team and project.
The sprint is part of a loop, a continuing set of iterations of feature definition, development, and acceptance which continue until the product is complete. The goal of each sprint, however, is to have a working piece of software at the end-even if not all desirable features are in place, those that are in place should function correctly and provide value to the user.
The trick to achieving this feat lies in the definition of the backlog items. The product backlog is the master list, created, maintained, and organized in order of priority by the product owner. The owner is the customer or customer surrogate, and is the only person allowed to add or remove items from the product backlog. Each item, however, must be discrete enough to be built entirely within the sprint timeline and valuable enough to make it worth finishing.