Agile Development: Rugby Analogy Considered Harmful

Recently my friend Mark Hudson posted about the inappropriateness of the term “sprint” for an agile project phase, preferring the cycling term “interval.” That post really struck a chord with me.

As a rugby union fan and former wing/fullback I’ve always thought the whole rugby analogy was wrong. Agile development is continuous and fluid, yet the agile originators chose the word “scrum” for its daily standup meetings.  In rugby union a scrum is a set play resulting from a minor penalty, like offside in American football or a foot fault in tennis.  If you like the rugby analogy the right term would have been “ruck,” which is kind of like a scrum but part of the continuous run of play (in the other kind of rugby, called rugby league, the scrum has devolved into an almost meaningless stylized ritual – which I guess happens on some agile projects).

But if you think about it, rugby, or almost any team sport for that matter, is a poor symbol for application development.   The action occurs over a set time and is controlled by an ever-present referee.  A rugby match is a direct competition between two teams.  A scrum in rugby is an activity engaged by eight specialists and if incorrectly done can result in a snapped spine.  The agile method assumes some interchangeability of skills and is generally perfectly safe.  An application development project is a single team working together to achieve something.  It is egalitarian: the scrum master is a facilitator, not an umpire. When other teams are involved they are working together, not competing with each other. And on and on.

I don’t know much about cycling, but it seems a much more apt analogy.  As Mark spells out, “interval” is a much better term than “sprint”.  Cycling involves a journey by a team or an individual, there are obstacles like hills and traffic lights to navigate, fitness and training are prerequisites.  The team takes breaks between intervals, and might huddle up at breaks to talk about plans for the next interval.

But most importantly, cycling requires a map.  No one just starts on a 50 mile ride without either a map or previous knowledge of the territory. Imagine a group of cyclists on vacation in San Francisco for the very first time starting out on such a ride with a very general plan and no map.  Would you bet on them arriving on time?

In the business world, as I’ve written, the roadmap for a custom application development project is an executive-approved business case and clear definition of business objectives. I’ve seen many agile efforts start with a business case that’s non-existent, cursory, or hopelessly optimistic, and similar business requirements. The result is like the project played out in this article: the team constantly runs to catch up with ever evolving scope and business objectives, and at the end is blamed for being late and overbudget!

The agile method calls for a team effort among all project participants, and stresses business involvement as a key success factor. However, in the real world business people are often too busy to participate meaningfully and developers are all too willing to bypass the boring business stuff and start slinging code. A cycling analogy might help the team stop and say “Wait a minute, we don’t know where we’re going!” before there’s a decent business roadmap.  Maybe then the team starting with insufficient business definition would put proper emphasis on answering these key questions before riding out:

• Where are we going?
• Is it worth going there?
• What do you expect to get out of this trip?

My point depends a lot on the difference between business and technical requirements.  I go into it a bit in the post linked above, but I’ll save a detailed look for another post.  I’ve gotta go now, I’ve got the Saracens versus Racing Metro 92 Heineken Cup match on the DVR.