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.

From http://chrisdixon.net/?tag=scrum
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 Ask.com 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.
From http://www.dailymail.co.uk/femail/article-2020540/Zara-Phillips-wedding-Mike-Tindall-Canongate-Kirk-Royal-princess-marries-rugby-ace.html
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."

Comments

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

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

    ReplyDelete
  3. This comment has been removed by the author.

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

    ReplyDelete
  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.

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

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. From http://www.yogawithjohn.com/tag/yoga-class/ 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 a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica