How much of a scrum is SCRUM?

When I was given my ScrumMaster training, the course leader put forward their opinion that, whilst rugby works as a good analogy for Agile, a rugby scrum is less effective when compared to Agile Scrum.

To bring any newbies up to speed, the rugby–Agile analogy is as follows:

Team members work together as cogs in a larger machine, with lots of small exchanges and interactions helping to achieve the wider target of going the distance, despite obstacles. The team delivers a successful outcome, not just for the individual, but for the team and all parties invested in the success of the team.

In fact, the rugby scrum was not even used as a point of reference in the original article that inspired Agile Scrum (“The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka), so it does feel a bit like the rugby analogy was stretched a little in adopting Scrum as the name for this particular framework.

My course leader’s opinion was that the scrummage, in rugby terms, goes against the imagery of a free-flowing rugby move, where the team retains possession to gain territory and traverse the entire pitch. A scrum does not flow; it occurs after a stoppage in play; it has three set stages (more like Waterfall than Agile); it can collapse.

Of course, this opinion and variations on it are more widespread than that, and, whilst I agree to an extent that the rugby analogy works best to describe Agile and Scrum at high level, I also argue that there are valid synergies between the components of a rugby scrummage and a good Agile Scrum team, as follows:

1. Scrum Half

For scrum half, read Product Owner.

This is the person who has possession of the ball, or in Agile terms, knowledge of the requirements at the start of the scrum. In both cases, they feed these into the scrum and rely on the team members in the scrum to give them something that they can use at the end of it. For the scrum half, this is the ball at the end of the scrum, still in their team’s possession, ready to play on and attack the opponent. For the Product Owner, this is the functional increment of the product, ready for further iteration or release to market.

2. Hooker

The hooker is much like a servant leader.

A hooker has to strike early to get control of the ball and help gain their team an advantage in a scrum. As they use their feet as well as their upper body and neck strength in a scrum they need good technique, agility, co-ordination and flexibility.

If your Agile Scrum team is there at the start of a sprint, ready and raring to get out of the blocks, then that will put you in good stead for a successful sprint. You will need members of the team with good co-ordination to help guide the requirements back into the arms of the waiting (and grateful) Product Owner, and those with good technique and flair will be integral to producing an increment that is not just functional, but stylish.

3. Props

Props make the hooker’s life easier; they bind on tightly on both sides of the hooker and attempt to stabilise the scrum when the ball is in possession. As a prop, putting your head where it hurts is non-negotiable. You need to have strength, endurance and pride.

Likewise, a team that has reliable members, taking pride in their work and willing to stay the distance will be able to deliver. However, that said, you will also need members of your Agile scrum team to put their strong necks on the line and not shy away from accounting for any lack of success with a sprint.

The prop to the left of the hooker is called the loose-head and the prop to the right is called the tight-head because they slot in between the hooker and the opposition loose-head. I liken this to the benefits of having both left and right brained representation (left = logical, analytical and objective, right = creative, thoughtful and subjective) in your Agile Scrum team.

4. Second Row/Locks

The second row, or locks, bind tightly together and pack down behind the front row, putting their heads in the gaps between the hooker and the props. Their objective is to push, and guard against opposition pressure in the scrum.

In Agile Scrum, you need your team to drive and push on throughout the duration of a sprint. They need stamina, dedication, and an awareness of their team mates. Like the second row, you need people who will muck in and knuckle down, supporting their colleagues to collectively deliver the sprint. An Agile Scrum team missing this component will know about it, as they will consistently lose momentum and fail to deliver sprints.

As with rugby though, it’s not all about pushing on and looking ahead; you need to be mindful of your surroundings. You sometimes need to withstand and safeguard against external pressures. In a software development environment, there might be live issues, expectations and requirements imposed by the business, or maybe even in some environments, other roles and responsibilities to carry out alongside your Scrum commitments. The team needs to be able work with the Scrum Master to protect the sprint from these outside factors as much as possible.

5. Flankers

The Flankers are in the back row and bind onto the props and second rows on either side of the scrum. They are quick to break away, both in defence, to limit the damage that the opposition can do to their team, and following a successful scrum, to support the scrum half.

Like losing the scrum and having to defend your team from the opposition, an Agile Scrum team needs people who are quick to get out and address any external problems, like live issues, to limit the impact on their team. Similarly, following a successful sprint where the Product Owner is safely in possession of the increment that the sprint produced, that Product Owner may need support and it is important that the Agile Scrum team has the temperament to provide that support, both to their Product Owner and the increment of the product that they have produced.

As well as sharing traits with the other positions in the scrum, such as strength and endurance, Flankers also possess speed and a competitive edge. Any Agile Scrum team will testify that the quicker members of the team are a real asset, and harnessing friendly competition amongst a team (to the right degree) can also bring out the best in them.

6. Number 8

The Number 8 has the responsibility of securing possession at the base of the scrum and ensuring that the ball is available for the scrum half to pick up cleanly. As such, the Number 8 has good awareness and knows where their team-mates are.

The Agile Scrum team needs to take responsibility for ensuring that the increment of their product is ready to be handed back to the Product Owner in an acceptable and useable state.

Throughout a sprint, there are a lot of ‘moving parts’ and the team needs to have an element of being aware of each other, both in terms of progress and morale. If the team is not doing this, then it is arguably not self-managing.

Another key feature of the Number 8 is their size: they are big. You may be familiar with the term ‘heavyweight developer’; having one of these in your Agile Scrum team certainly doesn’t go amiss.

But what about the Scrum Master?

I think any Scrum professional will agree that, when we talk about a Scrum Master, we are talking about a referee. They are concerned with overseeing that the rules of Scrum are observed, like a referee only cares about the rules of the game.

A Scrum Master should be able to do their job in any industry with any team. A referee will be working with different sets of people from week to week, and this variation does not impact on their ability to do their job.

For both the Scrum Master and the referee, the constant is the rules that they are governing and facilitating.


The first point of the Agile manifesto calls for “Individuals and interactions”. Whilst, on first glance, rugby in open play seems to be a much more suited metaphor for this than the rugby scrum, on closer inspection there are actually several similarities between the traits, temperaments and characters of a successful rugby scrum and Agile Scrum team. Without individuals interacting as outlined in this blog, either type of scrum team could fall apart, and nobody wants a collapsed scum.

Share this post

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email