Before we start though, a bit of clarification. Throughout this article I will continually refer to 2 types of scrum - the rugby scrum and an agile SCRUM. To avoid confusion, I have used 'scrum' (in lower or mixed case) to refer to a rugby scrum and SCRUM (in uppercase) to refer to the agile development process. The capitalisation is purely a means to distinguish between the two words. The SCRUM process is not capitalised by convention.
The Purpose
The main reason for the SCRUM metaphor was for the progression of a scrum, when you put eight, typically large, individuals tightly together, moving in harmony, supporting and pushing against the incoming forces of eight other individuals. Together you hope to find your team edging forwards and winning the current contest.
This is the goal in software development too, the team working together, against a problem, boldly making progress inch by inch. But can we delve into the metaphor deeper and see the wider picture of SCRUM, both in the sport and in the methodology?
The Law
Rugby Union has a Law Book which all players, officials and even supporters must follow to a tee. Law 19, focussing on the rules of the scrum, says that:
The purpose of a scrum is to restart play with a contest for possession after a minor infringement or stoppage.
In other words, the scrum's primary reason for existence is to get the game going again after a pause, either because of a (relatively) small error or human-related need. And this could lead to a flaw in our metaphor if we see SCRUM as a short-term, temporary fix to an error or human-factor.
Typically, SCRUM is used over long and short projects, an actively positive choice rather than a response to a negative or delaying factor. The time of use is not dictated to us by another person or persons, a circumstance or a gap in development, but rather should be a choice embraced by the team, understood for what its purpose is and implemented as a cyclic and recurrent strategy to make progress in software development.
See Beyond
A scrum, in the wider picture, creates space. And depending on what team you are on, that either gives you a fantastic opportunity to attack, to be creative and move forward at pace and make the most of the new options and spaces that appear or, contrarily, a dreaded time to double down and defend against these things in the hope of covering the space and trying to turn the tide in your favour.
For those working in SCRUM, what we do and work towards and create should really revolutionise the horizon of where we are working, leading to opportunities for other groups to take our advancements and progress and run with them in areas and environments that we maybe never saw coming.
Equally, the awareness needs to be there that the space could work against us, that we need to be ready to see the bigger picture and go with the flow, because if we are too focussed only on exactly what is happening in front of us, we might get left behind - and in a world of ever advancing technology, resting on our laurels is always going to lead us to losing.
But back to the scrum…
Winning against who?
However, a scrum is about a contest. Eight versus eight (let's not talk about exceptions yet), a battle of strength, technique, mindset and heavyweight physicality. The aim is to win possession of the ball and to remind the other side that you are above and beyond them. The struggle, assuming all other factors balance, is that as the key player lifts their foot to hook the ball back into their possession, the opposition has an extra foot on the ground which means they have more grip, more balance, more driving ability.
The solution to this is to ensure the team gets their timings sync'ed, to communicate perfectly, to support this weakness and to use momentum to get through it. With SCRUM, who, or what, is the opposition?
Let me say not the business competition, but rather the opposition is our problem that we aim to solve. We are constantly wrestling against it and aim to dominate it, to take control, to lead the attack and let it know we can't be beaten. And to do that, we need to have a team that's able to be in sync, that communicates even the tiniest detail, that supports each other wholly and builds an unstoppable momentum in spite of challenges arising. We contest against problems, and we aim to win.
And when we win the ball, scrum or SCRUM, we're left with a decision. When do we stop? In domestic rugby, there is a limit on the drive to protect the players from dangerous play that may ensue from limited experience. This doesn't exist at a professional level, you can drive for as long as the scrum stays legal and intact.
How far
Regardless of experience, the scope and end point of our projects should be clear for SCRUM teams and most projects come to a natural end or natural evolution point that should cause teams and targets to disband and regather for good reasons. And so on this part of the metaphor, I prefer the domestic rules.
But, in spite of that variation, when the ball reaches the back of the scrum after the team have made their progress, the choice is there to drive a little more, to pick up the ball and run, or to pass the ball to the other half of the team and see what new approach they take.
Three clear approaches, one doing what we know is working, one keeping it within the team and re-creating a similar product and one entirely changing the strategy and coming up with something new. SCRUM should give us that choice, clear progress markers as we go through the burndown charts, new opportunities as we delve deeper into the problem domain and understand it better, or brand new places to take our technology advancements and transform other areas of industry. Is that what you think of when you think of SCRUM?
The Pack
To the untrained eye, you see a large group of large, bulky, scary, often scarred individuals - I'll let you decide whether that bit is metaphorical or not. But what you actually have is a team, who eat, sleep, train and study together. Each uses their physical traits, personal talents and shared goals to contribute to the success of what they are about to try to achieve.
Whilst they support each other in other aspects of the game and can often interchange, this does not happen at the scrum. A hooker and a second row would never dream of changing jobs, and yet they are joined in their success and failures and rely on each other to make the progress. Each side forward knows what they are looking for, knows when to push in the straighten the scrum, knows when to loosen up to put the flanks under pressure and head off oncoming charges. An injury to a loose-head prop cannot be substituted by a No.8 without significant penalisation or complete change of the scrum purpose.
It's tactical, it's carefully planned, it's family. Is your SCRUM like that?
Murphy's Law
Of course, like unplanned injuries, life does happen. Ideally, we don't want our SCRUM team to change, certainly not mid-sprint. But where specialist skills are needed and essential, do we have plan B? Even in scrums, Law 3:10 forces us to declare the special skillsets in advance of the game - it's too late when we only think about them after bad things happen mid-flow and we need to save our scrum.
If we don't plan, if we don't anticipate, the whole plan changes. When Agile was first announced, it was vented by some as a recipe for chaos, often due to the ignoring of the last line of the manifesto that stated prioritising rather than choosing certain techniques.
In SCRUM, this is no different, we prioritise, but we are prepared for what could still go wrong. Maybe we should have our own Laws 3:13-34, so that we don't lose out on the contest against our problem domain, so we don't stall, so our strategies aren't thwarted and the team can always be allowed to edge forwards.
The Question of Leadership
SCRUM, by the textbook, has a SCRUM Coach, a Product Owner and the SCRUM itself.
The SCRUM is meant to consist of individuals all treated equally regardless of experience with mechanisms in place to allow experience to be shared and to support the decisions of those with less of it. This translates perfectly well into the scrum, veterans of the game will be role models for novices as they work together on the same team to achieve the same goal. You can't sideline inexperience, or ignore calls made in reading the game, but you integrate, support and go forward together.
The Captain and the Coach
Scrums tend to have a forwards captain. This may also be the team captain as a whole, but due to the disparency between the forwards' and backs' skillsets in communicating with officials, you need to have someone who can speak up for what the forwards are experiencing, what they need to and to motivate them from the front.
And this is where I cannot settle in my metaphor - by my experience, this is similar to a SCRUM coach (old textbooks will refer to SCRUM masters). However, the forward captain will play, whereas a SCRUM coach will not. The natural mapping would be to compare a SCRUM coach to a scrum coach - they identify plays, work on weaknesses, encourage and support throughout, but is missing that key characteristic of advocacy.
Whistle Watch
As noted at the beginning, the purpose of the scrum is to restart after an infringement. This means a monitoring and application of law, which means… a referee! And in my metaphorical extension, where the opposition is the problem domain, then the project manager should be the referee. The referee decides what should happen and when, isn't directly involved in the play itself, but ensures time is kept, rules are followed, and that everyone fairly pulls their weight. You could have a quick game without a referee - it wouldn't go wonderfully, but you'd probably get the job done.
SCRUM doesn't have project managers in its definition, and yet from a business aspect, they're needed to ensure staff get holidays, that all staff are performing and meeting a satisfactory standard, that deadlines are outlined and that rules are followed within a budget. You could do it without one, but that puts an onus of responsibility, and a likely drop in quality, elsewhere…
Out the Back
And how does the scrum connect with the product, the movement of the ball? The scrum half feeds the ball in, communicates between the two interfaces of fronts and backs as to what's coming next, reads the game, changes course. That sounds like a product owner doesn't? A single entity, feeding the priorities, communicating the whole time, knowing and watching the game, ready to pick and pass or hold off or go again. Typically not a powerhouse of strength that a forward (/developer) might show, but key to the whole game flowing and a whole other skillset that we connect with and admire.
I think it's key to point out the scrums will not function without some form of leadership. And often multiple leaders will grow out of scrums and excel at different times. No leadership is not a thing as personalities always mix and grow leaders, and the loudest voice won't always work as it's support, synchronicity and experience that echo through the game.
The same converts to SCRUM, and we should celebrate and embrace that fact whilst still using the mechanisms for sharing and developing experience throughout the team to stop an unnecessary hierarchy dominating decisions and possibly segregating the team rather than bringing them together.
Ideal Setup and Perfect Execution
The key to a scrum working is the set up.
At the Mark
A mark is made in the ground. The hooker will take their stance a few inches to the side of this mark, allowing the opposition to take a few inches to their same side. This allows head spaces to align later. Distance is important, too far apart and the scrum will collapse, too close together and the scrum won't get the right shape. All the other players take their positions from this and form together.
For SCRUM to work, the initial ground work and building up around the team is important. We need feedback! We need to know that we are responding correctly to change and that we understand where we're going and what comes next.
Clear!
Before that even happens though, it's important to prepare your boots! On a muddy pitch, your studs will start to build up and clog with pieces of wet grass. Clear your studs. If you don't, you won't have grip and you, with your team, will end up sliding which will either cause you to go uncontrollably backwards or dangerously collapse the scrum.
So before you start a project, prepare yourself! Read a little, practice a little, share a little in the codebases and technologies you are about to use. And whether you're there from the beginning of the game, or coming off the bench, warm up and stretching appropriately is important, and regular routine checks will change the game (the SCRUM coach should remind you of that!)
The Finer Details
The bind is inch perfect. Connecting with the opposition in the right spot will give either give you an advantage or neutralise theirs. You want to keep the scrum upright, driving forwards. You don't want it getting driven into the ground, or crumpled and pushed backwards. In SCRUM, understanding your problem domain is key - know the words, know the terminology, know the people. Use that to your advantage, or use it so it doesn't push you back. Making those connections and maintaining them will prove to be the success of your project.
The timing and the communication is key. Crouch, bind, set. The wait for the feed. The flow of the team, like clockwork, advancing at the right time. The squeeze of the flankers, the control of the No.8, the back pedal of the hooker. Extending to SCRUM, follow the cermonies. They are there for a reason, the timing is key, it needs to be followed. Everyone plays their part, everyone talks, everyone contributes on the timeline. One step at a time, no mad leaps. The team will advance, but only through regular, appropriate communication in standups, demos and retros.
Where it comes from
And then the feed. Back to the scrum half comparison. The product owner needs to be involved, connected, knowing what the forwards are about to do and delivering what they need as they need it. And sure, to open controversy, a straight feed… do we really mind if it comes slightly more our way to give us an advantage for going forward? I'm not going any further with this one, if you know, you know.
The Other Plays
There are other plays in rugby that we could learn from. A brief allusion to them here, such as:
The Ruck
The ruck is a fast paced attempt to maintain possession of the ball and control for the next phase of play. Clear goals, quickly in and out, ball comes out and move on. Metaphorically, Rapid Application Development (RAD) has a lot of similarities here, and we could expand even more as research based projects produce their own difficulties, as does a Jackal in rugby…
Open Play
As my Granda once told me whilst watching, “that looks like chaos but I can see structure somewhere”. Open play gives teams free reign to be creative, to work together, to try, fail and refine, to deliver at velocity and combine various skills and processes. I smell a metaphorical connection to Dev Ops…
Penalty Kick
One person lines up to kick the ball between the posts after a larger infringement of the laws and that person is often well known by the crowd watching. However, they are a smaller part of a bigger team. And whilst they might get 3 points more often from that, the team could work better together and get 7 points. But sometimes, 3 points makes the difference. In translation, celebrate individuals, but celebrate the team more.
In Conclusion
SCRUM is more than just edging forwards. Scrum has a huge number of factors and considerations that we can learn from and apply. Scrum isn't the only play in the game. As a metaphor, it started well, but there's much further to go with it. And maybe rugby as a whole is an allegory for software that we could explore more. But in the mean time, I'll be enjoying Instil SCRUMs and RWC scrums.
