OK, I’ve lost a five-metre scrum, my pack has been overrun, and the ref has raised his arm between the sticks for a penalty try. My colleague Margy Thomas, with support of fellow rugger Billy Tilson, has convincingly argued that agile development in fact is very like rugby union. Margy cleverly fended my meager one-point case with a point-by-point list of the ways that agile projects and rugby are similar. I’ll hold on to my view that sports analogies are generally weak in describing application development, but I’ve come to observe a fundamental similarity between rugby and agile/scrum.
Often the most difficult transition for those new to agile/scrum techniques is loss of role identity. The pattern I’ve observed is that teams new to agile cook along pretty well in the first few sprints and then they hit one that challenges capacity. Perhaps testing is unexpectedly involved, or development is more complex than anticipated. Sprint goals are within reach, but only if team members take on tasks that they aren’t accustomed to. Often, one or two individuals are upset at having to take on work that’s “not my job” or having to watch others with less experience cover tasks they don’t have time for. Frequently at this point the team also becomes frustrated with sprint retrospectives and planning, perhaps nostalgic for the deceptively comforting presence of a project manager.
At that point the scrum master helps the team understand that agile/scrum is all about moving past the roles. Cross training team members expands the team’s work capacity, improves camaraderie, and improves the skills of individual members. If all members of an agile team participate in the planning then all have a personal stake in the outcome.
The challenges associated with roles remind me of the contrast between rugby and American football (which I’ll call “NFL” for short). In NFL players have specific roles that they stick to strictly: offensive linemen block, defensive linemen pass rush and defend against the run, etc. In rugby there are very specialized roles on set plays but set plays are only a very small part of the game, most of the game is continuous and fluid. Here’s how Margy put it in her post:
|Self-Organizing Teamwork||As a player, you don’t carry the ball the whole time, and you can’t be a playmaker all the time. There’s a place and time for demonstrating leadership and a time to be in support, or pass the ball. Rugby players on the pitch will read the play happening before them and will act appropriately, be it to go into the ruck or fall into the backline.||Agile team members never carry the workload alone. The Scrum Master isn’t the leader of the team, but should strive to be an aide to the team. The work involved in building software is estimated, built, and tested as a team and no one team member will be the hero for a given story. Empowered agile teams are not told how to do their work. They are self-organizing and determine what needs to be done, when, and how.|
If we equate project management activities, for example, to carrying the ball and technical work to blocking in NFL or rucking in rugby, then an NFL offensive lineman only blocks, but a rugby forward often finds him/herself in open space with the ball. For that moment this forward is like a quarterback running an option play, and must make an instant decision to either (1) take the tackle and recycle the ball to his/her team, (2) kick, or (3) pass to one of several players in support. If you are looking for examples, watch Australian number 6 Rocky Elsom in the first couple of minutes of this video.
In order for agile projects to be flexible, incremental, and highly productive, team members need to be like the rugby forward: recognize when the “ball,” AKA decision making responsibility, is laying on the ground and know to pick it up and make a decision.
Bottom line: great rugby teams consist of players who have the skills and the desire to do whatever it takes when the opportunity arises, and it often will. The same could be said of members of high performing scrum teams.
So you win Margy, the rugby analogy works!
Cross functional teams sounds great, until you get into some areas where real domain knowledge is necessary. I work in the scientific and medical arena. I recently experienced a project where the client had a software manager who insisted we use scrum methodology. We had a small team, where my specialty is image processing. No one else on the team is going to be able to just come in and start working on my code, unless they are also experts in that area. It has taken me years of study to learn what I know, and there are plenty of people who know as much or more than I do, but they aren’t usually on the same team. Likewise,there are people on the team who are knowledgable about 6dof robotics controllers. Unless its an obvious bug, such as a null pointer, unless you are familiar with quaternion math and plucker coordinates, Euler angles, etc. you aren’t going to just be able to pick up where somebody left off. So, agile schmagile. It may be fine for largely GUI based code, where the various frameworks- WPF, windows forms, Qt etc can be learned in a relately short time, but for any kind of coding where there is some real effort to become proficient in the domain area it’s not going to work to shuffle programmers around. I won’t even get into the user story vs requirements in this comment….
Rick, thanks for the comment – I’m not inclined to disagree for the types of skills/projects you are describing. I work in data management and business intelligence, and generally speaking the skills of one team member are accessible to other team members if they put in the effort to learn. Clearly your world is different, and your comments useful to those thinking about the limits and applicability of agile practices.
Pingback: Be careful with agile methods if… » Bob Lambert