Skip to main content

Agile Expects More Than Scrum: A Bulletin From The World of Rugby

Are you tired of being lectured by "Pure Scrum" fanatics?  Some people are so quick to judge!  They will tell you "that's not agile!" or "that's a smell!" when:
  • you have a defined Software Development Life Cycle (SDLC)
  • team members are distributed to different rooms, cities, or time zones
  • you write anything down on paper larger than a 3x5 card
  • you spend more than a few days planning your work, even for a large project
  • you don't release to production at the end of every sprint
  • you start requirements an iteration ahead of development
  • you have a management structure more than one level deep
  • you use MS Project to do resource planning
  • you work on fixed cost projects
  • you have a PMP certification on your resume (even if it's the PMI-ACP)
  • you advocate use of HP Quality Center, which is Kryptonite to legions of agilists world-wide
  • you perform end-of-year performance reviews
Agile friends, let's take a look at ourselves.  Am I right?  Are we quick to form a howling mob when we see a blogger or speaker promote any of these ideas?  In a recent blog post I suggested that in an enterprise context, it is a good idea to have both a requirements workshop AND an iteration 0 period, and one responder pointed out that this suggestion was in and of itself, "a smell."  I got a very unhappy reaction to another post even for suggesting that it is good to use a checklist.

Mike Cohn's official catalog of agile smells does not include any of the bulleted points I just listed.  (Cohn's list is really helpful, and I suggest you all take his points seriously).  And if one of the leading thought leaders in world of agile scrum can be flexible on matters of scrum deployment, perhaps those of us who are less eminent could back off a little bit too.  Context matters a lot, and enterprise agile is significantly different than start-up agile, or even agile as practiced in small or medium businesses.

So let's take some perspective today from the world of rugby, an original context for the use of the world "scrum."  As a random example from the blogosphere suggests, we non-athletes quickly think we see an analogy between agile development and rugby scrum.  It's "the whole team going together as a unit, passing the ball back and forth," we say.  "There's No 'I' in 'Team!'"

But there is also no "we" in team, a rugby-playing software architect friend pointed out to me.  Or "halibut."  Rugby scrum is a great analogy for a set of techniques that contribute to a good strategy, but not an analogy for the whole strategy to win the game.  In software development, as in rugby, scrum may be necessary, but it is not sufficient.

In rugby, scrum is not the only technique or even the main technique.

Those of you who share my lack of first-hand experience with rugby may picture a scrum in terms of a stock photo of athletes on a field.

We like to think of ourselves as gladiators, even though some of us don't even lift.  But let's do a quick, rudimentary fact check.

In rugby, scrum enables play, but it doesn't advance the ball.

As wikipedia says officiously, a scrum "is a method of re-starting play in all codes of rugby football." (emphasis mine)  It is an elaborate version of a hockey "face-off" or a basketball "jump ball." As best answerer "John D" says, a scrum is:
generally summoned when an error of play occurs according to the law book. E.g. forward pass, knock on/ lost forward, free kick and any other play that is an infringement but falls short of the straight arm penalty.
In rugby, in fact, the scrum moves the ball backwards, relatively speaking.

Scrum is a very technical component of a rugby match, but it is not the part of the game in which the team moves the ball forward.  In fact, the team that wins the scrum does so by moving the ball backwards, relative to the pack.  As Rugby SideKick Central explains, the goal of the scrum is to gain control:
Once the ball is in the tunnel the hookers use their feet and legs to 'hook' the ball backwards and so win possession of the ball which moves back through the scrum and exits at the rear.
Scrum is a small part of rugby in the scheme of things.  

In the "Laws of Rugby," "Scrum" is defined as Law 20 of 22.  The Laws themselves are divided into three sections as follows:
Part 1 - Before The Match (Laws 1-6)
Part 2 - During Play (Laws 7-22)
Part 3 - Appendices: 7-a-side; Under-19; Rule Variations; Administration History
Within this structure, Law 20 comes at the end of Part 2, and the scrum is only one of several techniques described for putting the ball into play.  Before you ever get to "Scrum," you take a tour through all of the things it takes to hold a rugby match in the first place, starting with preparing the ground, rules for measuring team success (in terms of scoring), overall governance structure (how to select a referree), team staffing (who gets to enter the field of play, and when), and so on.  And then you get into rules around actually advancing the ball.

Just as professional basketball players allocate significant time to practicing free-throws, professional rugby teams spend significant time developing scrum techniques.  But no professional sports team considers itself ready to play based solely on its ability to handle a penalty situation.   And note that a successful free-throw in basketball, unlike a successful rugby scrum, is a guaranteed score for the team.

In rugby as in full lifecycle software development, winning or losing may depend on doing scrum right--but first you have to be able to position the scrum on the field and know when to force it to happen.

ISport Rugby puts it this way:
Many games have been won or lost based on a team’s scrumming abilities — or lack thereof. Though the structure of the scrum remains unchanged from one to the next (unless a forward is sent off), there are several strategy-specific elements that should be figured out prior to a game. One such element is the pack’s ability to move the scrum around the field.
Agile software project management is much bigger than team coordination during specific points of delivery.  You need all the fundamentals, not just one skill set.  You still need to start with a business case and executive sponsorship.  You still need to bring in the right workers with the right skills.  You need to set up a governance structure to measure whether the team is winning or losing your company's fight against time or the competition.  You need to know what you want to do, and you need to know how to do it.

Mike Tindall is probably the world's most famous rugby player, partly because he married Zara Phillips, the eldest grand-daughter of England's Queen Elizabeth II.  He is also well known by readers of tabloids because he always seems to be drunkenly cavorting with blondes to whom he is not married on camera and off the field.  Even I have heard of him.
Tindall has had a long history as a successful rugby player.  What's his secret to success?  He told The Telegraph in 2010:
I'm always trying to become a more complete package. Through my early years I was more of a physical player than anything else, but what I'm trying to do now is work on the other side, whether that is footwork or speed, or improving my handling. I'm lucky in the sense that I have the physical side to fall back on, but I want to get better at the other stuff.
And that's the bottom line, isn't it?  Agile software development, when defined as a philosophy which values "working software" as the ultimate goal, doesn't solely require Scrum.  It requires the complete package.  It requires "the other stuff."


  1. This comment has been removed by a blog administrator.

  2. This comment has been removed by a blog administrator.

  3. This comment has been removed by the author.

  4. This comment has been removed by a blog administrator.

  5. I am going to go ahead and block ad hominem attacks here. If you disagree with me, that's fine, but speculating about my experience is just silly.


Post a Comment

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …