Review By: Sid Snook
02/20/2008For those on the western side of the Atlantic unfamiliar with the term "Scrum," it comes from rugby-a game vaguely similar to American football. When a team has the ball, they're in a position to dictate tactics that will utilize their own particular talents to score a touchdown. This is similar to how using scrum to develop software is presented in this book. Depicted is an organized team of software professionals independently managed, left alone, and not interrupted long enough to implement an increment of software functionality...a touchdown!

This book focuses on the pragmatic Scrum software development philosophy and associated techniques, processes, and rules.

This empirical Scrum approach to software development is based in manufacturing process control theory. The book contrasts the approach against a host of more classically defined and widely accepted software engineering methodologies, disciplines, and techniques. Scrum summarily abandons such classic project management techniques as PERT charts, Gantt charts, project plans, and even the well-known CMM processes.

While the set of techniques and practices seem simple to implement, the authors frequently state that the reason why and how Scrum works is perhaps not so simple to understand. It may in fact only be fully understood by actually implementing Scrum.

The book is easy to read and is enhanced by applicable examples and anecdotes. The authors present an empirical approach to controlling software development that is difficult, complex, and/or contains requirements. Occasionally some statements are made that seem Scrum-biased and outlandish, but other statements cause reader epiphanies that might make you say, "Of course, why didn't I think of this before!"

Potential implementers and new "Scrum Masters" are warned repeatedly that it is absolutely necessary to follow the Scrum Rules to assure success and to realize the potential productivity gains. The author also point to the importance of business managers accepting less project control then they would typically enforce through business and reporting standards. Managers might find it difficult "to take the risk of giving the team autonomy for the defined period," known as "sprint development cycles".

Scrum has its own unique set of procedures including user-directed prioritized planning, and team self-monitoring, -disciplining, and -organizing. These procedures are visible to anyone who wishes to observe, but not interfere for at least the duration of a time-boxed sprint.

Scrum has essentially no applicability in small organizations with limited resources committed to multiple projects, and with staff essentially working on independent projects. That is, the productivity gains promised by Scrum are acquired through the synergism of a team effort. A person working independently on a project obviously cannot expect any of the productivity gains claimed for Scrum teams. The book suggests "the size of the team should be seven people, plus or minus two. Teams as small as three can benefit, but the small size limits the amount of interaction that can occur and reduces the productivity gains."

The elements of Scrum are simple to understand, but perhaps not so simple to accept and implement in an organization using more classic plan-driven developments with standardized processes designed to make each software development highly controlled with results that are intended to be "predictable."

The book states: "Scrum isn't for everyone. But it is for those who need to wrestle working systems from the complexity of emerging and unstable technology...Scrum is about deep social interactions that build trust among team members...a kind of social engineering." Overall the elements of "Scrum" presented in this book promote truths about making productivity gains.