Ten years on since Kent Beck encouraged us all to embrace change and most in the IT industry now have a good understanding of the concepts behind the agile movement. However, despite the huge publicity and the wealth of information published on lightweight processes, many would argue that agile methods have still to achieve the status of a mainstream paradigm. For most projects, Royce’s waterfall model, or flavours thereof, still dominates.

I was therefore intrigued to discover that several companies around the region were independently returning to the agile fold. This time around, rather than going down the XP path, all were adopting Scrum. This begs the question as to why Scrum should suddenly be proving so popular?

Scrum emerged back at the start of the agile movement in the mid-nineties and has all the familiar concepts of an agile process, with the method relying on time-boxed iterations to incrementally evolve the solution. Daily meetings, or scrums, plan the day’s activities for the team and help maintain project momentum. The team size on a Scrum development is kept to 5 to 9 members, as this size is seen as optimal for creative work.

The Scrum terminology is undeniably cool. We have thirty-day sprints instead of iterations and the entire Scrum team keeps a close on eye on the burn down chart to monitor progress. Scrum roles are similarly intriguing; the Scrum Master mentors the team while the Product Owner provides business input and administers the product back-log. Beyond these roles we have the pigs, who “have their bacon on the line”, and chickens, who sit on the fringes – wonderful stuff!

So is cool terminology enough to explain the renewed interest in Scrum? Certainly working your way through the burn down chart sounds far more exciting than plain old coding but it is unlikely to be the main reason for Scrum’s upsurge in popularity.

One reason so many companies are jumping on-board with Scrum could be due to the method’s concise nature. Unlike XP, Scrum lacks the detailed practices teams must apply in order to develop software. For example, there is no mention of pair programming, test-driven development or continuous integration in the Scrum world.

Scrum’s apparent lack of meat might sound alarming to some. Indeed, you could argue Scrum is nothing more than a cut-down, low discipline version of XP, made palatable for mainstream consumption by removing the controversial practices. Few of us would argue that practices such as pair programming made many companies distinctly uncomfortable with agile methods.

The argument that Scrum’s success is attributable to the method’s perception as a slimmed-down and sexed up agile process could cause some concern. However, when evaluating Scrum against XP we are not comparing apples with apples. Scrum focuses on the planning and organisation of projects, and unlike XP, the method does not dictate what practices to apply when constructing software. Consequently, Scrum is applicable to a wide variety of projects outside of the software development profession.

Scrum’s concise, consumer-friendly nature is both its strength and Achilles’ heel. To prove successful, teams must understand the limitations of the method and possess the expertise to augment Scrum’s planning and organisational capabilities with the appropriate best practice software engineering techniques.

In the early days of the agile movement, many XP adopters ran into trouble by dropping many of the process’s controversial practices. These teams then failed to instigate alternative disciplines to fill the gaps. A similar danger exists with Scrum in that teams failing to incorporate appropriate development practices run the risk of jeopardising delivery timeframes and software quality.

Plaudits of Scrum will likely react to this criticism by pointing out that Scrum is an empirical method and actively relies on staff bringing their experience and skills to the project. Nevertheless, the fact remains that even with such a consumer friendly agile method as Scrum, project teams must ensure they embrace any new development processes with their eyes wide open.

Alan Monnox, April 2008.