Agile is not just about speed

Without doubt, Scrum has become a household name in Software Development arenas. Scrum as we all know it today, is not an acronym but derives from the game of rugby. A Scrum in Rugby is a loose formation of forwards designed to bring the rugby ball back into play. It was Hirotaka Takeuchi and Ikujiro Nonaka in their revolutionizing article The New New Product Development Game for the Harvard Business Review who first used Rugby as the best analogy to describe new product development. Although at the time I am sure they did not realize how much of an impact their research would have on new Software development.

It is interesting to try to understand why Takeuchi and Nonaka picked Rugby as the best analogy for describing the characteristics of competitive companies engaged in new product development. 

In my opinion, it wasn't for the "scrum" or the "sprint" terminology which most people tend to accept, but rather because of a Rugby team's ability to self organize and adapt on the fly as the game play changes from second to second. And as a self organized team be able to move the play forward effectively and efficiently without a predetermined plan. 

This is evidenced in Nonaka and Takeuchi's paper that reads: 

"Instead, a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements."1 and that "Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish. Rather than moving in defined, highly structured stages, the process is born out of the team members’ interplay"2

This incidentally also represents the source for the concept of cross-functional teams required to build complex software products.

Further, comparing traditional waterfall processes to an agile process is like comparing American Football to the game of Rugby. In American Football, game-play is predetermined, and players execute a carefully crafted plan to outwit the opposition. Rugby on the other hand may have some overarching plan, but the play itself really determines the outcome. Players need to figure out how to outwit the opponent as the game proceeds. Rugby players think on their feet.

Scrum founders Ken Schwabber and Jeff Sutherland most likely chose to continue the Rugby analogy as they adapted and applied the learnings from this paper to new software development. I am sure a lot of thought went into choosing the Scrum terminology and here's my take on it.

The Sprint in my opinion was chosen for two reasons:

1. To denote UN-INTERRUPTED time for the team to focus on getting the job done. The Sprint is the phase in the game of Rugby where the team is left to their own devices to get "the ball" to the goal line.

I have seen many software projects fail in my 20 year career in software development, and in most cases it was because of the continuous churn. Developers not given the time to devote their attention to detail, to technical excellence and to get something done. Typically these projects are so chaotic that it's almost impossible for any forward momentum. The Sprint in Scrum is designed to give software development teams this time to shape the software and bake the architecture for the for future iterations. In this way, Scrum helps to contain the chaos that surrounds the Sprint.

2. To denote agility. When Rugby teams sprint for the goal line they have to execute multiple phases, sometimes going from side to side but constantly figuring out how to outwit the opponent and move the ball forward.

It is this characteristic of agility that I believe gives teams the greatest chance for success. Being agile allows teams to be flexible and adaptable. After all, this is the real world - technology is constantly changing, competitors are constantly breathing down our necks releasing new product, employees leave and new ones start.

Many of my colleagues however mistakenly think that the reason the "Sprint" was chosen to denote an iteration is because of speed. 

My belief however is that yes, speed is an important consideration but it's not the bee-all and end-all. One must not fall into the trap that Sprint = Speed  and therefore adopting Agile means you'll ship faster, as this will surely lead to failure.

Continuing the Rugby analogy then, what is the significance of the Scrum?

The Scrum in my opinion signifies the notion of servant leadership where the team decides the course of action, not the coach. A Scrum is a relatively loosely coupled temporary formation of players during which the team bands together to form a coherent single thrust of energy focused toward one goal - getting the ball back. Scrum teams once in the groove build up significant forward momentum where the total output of the team is much greater than the sum of each individuals output. I call this being in the zone. Scrum guru's refer to this as hyper-productivity.

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com
_______________________
1. Takeuchi, H. and I. Nonaka, The New New Product Development Game. Harvard Business Review, 1986(January-February): 2.
2. Takeuchi, H. and I. Nonaka, The New New Product Development Game. Harvard Business Review, 1986(January-February): 3.

Comments

[Carlton]

I think another sports analogy is tennis - it is up the players to figure out how to beat each other. There is no coach in tennis.

As I think about it - Scrum's emphasis on generalists might fall down with the rugby analogy and might be a deviation from Takeuchi & Nonaka original idea. In rugby, each player has a position with a long history of how it is played and players tend to be an expert in their position. There was a recent Six Nations match where Italy tried out a new player, Mauro Bergamasco, as Scrum Half and it was a disaster. Even in rugby, people specialize. However, every player needs to know how to tackle, pass, catch and block.

[Jack Milunsky]

Thanks for the post. Much appreciated.

I agree that you need specialists in Rugby. But you do need specialists in software development as well. Even though Scrum doesn't specifically distinguish the "PIGs" one from another, it definitely requires each specialty to get the product out the door, i.e. software developers, dba's, testers, tech writers etc.

My 2 cents
Jack

[Tathagat Varma]

Interesting article, but let me present a contrarian view. In a game of Rugby, there are two teams pitted against each other, and both teams use similar strategy of close-knit teams, sprints, etc. This makes sure that one team wins.....but, one team always loses despite using the very same strategy! The strategy that is leading one team to win is also leading another team to lose at the same time! So, taking a very neutral view of the Rugby analogy, the success rate of Scrum strategy is just about 50% (assuming there are no drawn games in Rugby, which, of course, is a wrong assumption). Would you adopt a process, any process, whose chances of success were just about 50% ? Obviously we are missing something here.

Here is my take on this: all sports teams have a gameplan which is made before the match depending on the opponent, ground conditions, weather conditions, level of play, next fixture, and so on. Extend the Rugby analogy. It is not that they have no plan and just adjust on the fly (that would be pretty ad-hoc, I think). I believe they have a solid plan to begin with (surely the winning teams have to have a winning gameplan). During the game, when things don't go as per that gameplan (as they eventually will), it is then that they adjust and try to come back to the gameplan. So, the team that wins the match has a solid gameplan and a strong sense of agility to adapt as per the rapidly changing conditions.

I am writing a more detailed blog post on this topic. Look up managewell.net in a few days and let me know if it makes sense or not :)

[Raul Xavier]

Very interesting idea. I have implemented SCRUM in my company and we´re loving it. My director asked me to translate SCRUM concepts, because not all employees speak English. When we came to Sprint, he said he did not like the Sprint word for the speed idea associated (he does not like to put more stress/pressure to the team). I told him exactly what you said here, that the idea of sprint was the time to actually do things, to develop. There´s planning when you´re not on sprint, when you have the meeting on sprint end, when the sprint backlog is chosen, etc.

As for the Rugby analogy, which I think is great, you don´t have a 50% chance, since in development, you don´t have an opponent using SCRUM to beat you. Development is not an opposing game, it´s a cooperative one, where every player has the same goal, to deliver software.

One could say that the opponents are the competition, but the goal of SCRUM is to deliver good software on a time efficient and controlled way, that can easily adopt to changes as needed, so the company can realize its strategy.

If two competing companies use SCRUM to develop, the winner will be, as it is on Rugby, the one with best skills, such as seeing the product´s features that fit the market, the appearance, the marketing strategy, etc.

[Raul Xavier]

Quoting Bill Gates:
"The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency."

[Jack Milunsky]

Thanks for your insights on this topic Raul. Much appreciated.

Jack

[Jack Milunsky]

Thanks for your interesting take on this subject Tathagat. The question I have I guess is how far one can go to stretch the analogy. My sense is that one can think of the opponent as the either competitor or the customer. In the competitor's case, it is possible for a win win situation. i.e. you can both succeed but one is less successful. Think of Hertz and Avis. So in the game of software coming in second place may not necessarily be a bad thing. Of course you want top spot. In the case of the opponent being the customer. Here you have to get the product right, if you don't you lose. In this case however the customer is just a recipient of the software and not playing against you in the game of software development.

My 2 cents
Jack

[Markus Gärtner]

Elisabeth Hendrickson put this up in a nice term on her HeuristicsCheatSheet (http://testobsessed.com/wordpress/wp-content/uploads/2007/02/testheuristicscheatsheetv1.pdf):

Don’t confuse speed with progress.

Most teams seem to just do this. Even shorter iterations, hasting through the project etc. just shows me this.

[pariul zilei]

Interesting info, do you know where I can find similar information? I’ve been trying to find out a little more about this kind of stuff, thanks for sharing it.