These days, the development of nearly all non-trivial software is a team game, and it comes in a large variety of shapes and sizes. We can say the same of the different sports that are called football around the world. Comparing software development with the various forms of football is both interesting and informative.
- The Rules of the Game
- Playing Well
- Good Coaches, Managers and Players
- Ability, Experience, and Discipline
- Team Composition
The Rules of the Game
The various forms of football from around the world include:
- American Football (or just football if you are American)
- Association Football (or just football if you are not American, and Soccer if you are American)
- Rugby Union (my personal favourite)
- Rugby League
- Gaelic Football
- Australian Rules Football
- and so on ...
Each of the different kinds of football has its own set of rules or laws that govern how the game is played. Some of those sets of rules are relatively simple, such as those for soccer. Others like those for American Football and Rugby Union are complex and include numerous different set pieces or ceremonies such as first downs, huddles, time-outs, scrums, line-outs, twenty-two meter drop-outs, and so on.
Similarly, we have different ways for playing the game of software development. Each different approach or process describes a different set of rules, laws, or guidelines for playing the game. Some like Scrum are elegant in their simplicity. Others like some of the waterfall and structured approaches of the 1980's, especially if they had anything to do with defence departments or ministeries, are comprehensive in their complexity.
Nevertheless, in both football and software development, simply knowing and following the rules of the game is not enough to ensure success. For example, Scrum is deceptively simple because while the essence of Scrum can be defined in a few pages, and the official Scrum Guide does that very well, reading and memorising those few pages does not fully equip a team to be highly successful in applying Scrum. Similarly, there is a huge difference in the way an English Premier Legue team such as Manchester United approach and play a soccer match compared to my local amateur soccer teams. They both play their matches according to the same rules but the actual execution is worlds apart.
For any software development process, just like any form of football, there are:
- the rules or laws of the 'game',
- a broad, abstract body of knowledge about how to play the game well,
- the tactical application of item 2 to particular circumstances, and
- the skills, discipline, and experience of members of the team/squad.
This even applies to some of the more bizarre variations of football such as:
The rules define the game you are playing and determine officially if you are playing that game or not.
Modern football games evolved out of mob football, "... played between neighbouring towns and villages, involving an unlimited number of players on opposing teams, who would clash in a heaving mass of people, struggling to move an item such as an inflated pig's bladder, to particular geographical points, such as their opponents' church."
Different sets of rules evolved to impose some level of order onto the chaos and form the various different sports that we call football today.
Similarly, software development teams need to agree some rules and guidelines about how they work together. Scrum is one such set of rules, eXtreme Programming a different set, FDD another, DSDM yet another and so on. Many of these have similar rules and share some underlying principles, just as the different football games do. In addition, people are completely free to make up their own versions of games by adding to, subtracting from, and combining different sets of rules.
The Scrum Guide describes the rules of the game of Scrum software development, and the content of the Scrum Guide is basic, required knowledge for a Scrum team. The five short process descriptions on the Nebulon website do a similar job for Feature-Driven Development (FDD) and so on.
In established sports, the rules change relatively infrequently and only after much careful consideration and experimentation but they do change on occasion even in such simply-defined variations of football as soccer. For example, a number of years ago, Football Associations around the world agreed a change in the rules about when a goalkeeper could pick up a ball. That rule change was tried out extensively before it was made official. But once it was official, from that point on, you were not truly playing Association Football (soccer) if you continued to play according to the old rules. Those wanting to continue playing to the old rules were quite free to disassociate themselves and set up a variant of the sport with a different name.
Similarly, we can and should expect the rules of software development processes like Scrum to evolve and change every now and again, and the Scrum Guide or equivalent to be updated to reflect those changes. Software development teams are free to continue following the old rules if they want to but really can no longer consider themselves true Scrum teams. Equally, teams that were following the new rules already can now truly call themselves Scrum teams.
Additionally, if a group of people find a set of rules that they happen to think are better to those of any particular form of football, they are free to define their own football game with those rules. After all, this is essentially how we have come to have all the different forms of football that we have; all variations on a theme with different people having strong preferences in respect to playing, watching, and enjoying each one. For example, I frequently play football (soccer) with my three boys in our backyard. We call it football even though we only have one set of goal posts, one goal keeper, and the first one to score three goals becomes the goalkeeper for the next round. This repeats until mum calls us in for dinner. While our game is certainly inspired by soccer and shares many of the same rules and principles, in no way do we imagine that what we are playing is a soccer match as defined by the rules of Association Football. I certainly wouldn't certify that my boys are experts in playing Association Football (soccer) based on what we play in our backyard. That is not important to us. What counts to us is having fun together, getting some exercise, and practicing some of our ball skills.
If your particular circumstances dictate that you cannot play the Scrum or FDD game well following the established set of rules (your backyard is not the size of a soccer pitch, and you only have three children, not twenty-two) then you are forced to redefine the rules to form your own variation of the game; it might be Scrum-like, Kanban-oriented, or FDD-inspired but it is not officially Scrum, Kanban or FDD.
Fortunately, unlike an official football competition, it is almost totally irrelevant whether or not a software team is officially a Scrum team, an FDD team, a Kanban team, or not. What is important in software development is not the particular name of the game you are playing but whether playing that game is producing the results you need; whether or not you are delivering what Peter Coad used to call frequent, tangible, working results for your customer. It is not important precisely what game you are playing, it is much more important that you are playing the game well.
If the particular software development game you are playing is not producing the results you need, you can look to change the game to one that will. However, the rules of the game are only one factor in the equation.
When you hear football pundits, whether professional pundits on television or amateur pundits in a bar somewhere, they rarely spend much time discussing the details of the rules of the specific game. It is assumed generally that everyone knows what the rules are; it is, basic, required knowledge for playing or talking about the game. No, the discussion is far more likely to revolve around how well or not a team plays.
In addition to the rules of any football game, there is a broader, more abstract body of knowledge that describes, in general, how to play the game well. This is constantly evolving and debated, leading to different 'schools of thought', different approaches, different styles, general agreement about best practices, etc.
This knowledge is as important as the rules and absolutely essential to playing the game well. For example, no serious association football (soccer) team would set themselves up in a formation that had no-one responsible for the defence of their own goal, and no serious American football team would consider starting a season without a play book. Unlike the rules of the game, this body of knowledge is open-ended, can fill a multitude of books, and provides endless fascination, debates, and discussion for connoisseurs and pundits of the game.
Similarly, the rules of a particular software development approach or process are generally much smaller than the size of the heavily-debated, example-based strategies, patterns and techniques for applying that particular approach or process. The most obvious example of this is Scrum where the rules of the 'game' fill only a few pages but the best application of those rules continues to fill many books and blog postings.
While this body of strategies, patterns and techniques exists for established football games and software development processes, if you substantially change the rules of the game to form your own variation, you run the danger of invalidating large segments of it. You may find yourself having to evolve your own equivalent strategies and tactics from scratch. This is a potentially very time consuming and frustrating activity. It is a very strong argument for sticking to the rules of an established, proven approach unless circumstances really dictate otherwise.
Good Coaches, Managers and Players
In addition to this body of strategies, patterns and techniques, there is the tactical application of this knowledge to particular circumstances: to a particular team, within a particular organisation, for a particular match. This application is essential to playing the game well in a particular context. This is the skill that good coaches, managers, and players bring to the table; the innovation, and ability to adapt to different circumstances, even to bending the rules on some occasions to achieve success. How often is a great coach seen to make a small tactical switch during a particular game that completely changes the outcome?
Software teams may know the rules of a particular software development process but if they have little or no experience in applying those rules within a range of different projects, they are likely to struggle badly. No serious football team owners or managers create a team without hiring coaches with proven track records. So why do many software development organisations think they can be successful without doing similarly?
However, there are differences. Football coaches and managers do not tend to move between the various forms of the game. They have so much ability and expertise in one particular form of the game that this specialisation hinders their movement to a different code. A great soccer coach does not usually make a great rugby coach. In contrast, in the current software development industry, coaches, consultants, and developers that have experience in a number of different approaches can be worth their weight in gold because they can adapt and apply strategies and tactics from a wider body of knowledge and experience.
Ability, Experience, and Discipline
Finally, all the process knowledge and adaptive strategic and tactical ability is not going to help you succeed if your developers do not have the discipline, skills and experience for the level of development required. You would not expect a team comprising of amateur soccer players to be consistently successful playing in the English Premier League or any other major soccer league. The players' skill levels, fitness levels, experience, and professionalism are nowhere near the levels required. Nor would you expect top-flight Rugby Union players to be very successful at playing American Football, at least not immediately; some might adapt over time but others might not be able to.
Similarly, you cannot expect average developers to suddenly become great developers simply by significantly raising the level of quality that they must deliver, or by switching the process they work by. Some might make the leap, some might make it over time with training and coaching, but others may never do so, and may not even want to. You may find some developers simply cannot adapt to play according to a different set of rules or expectations, even to the point of doing the software development equivalent of throwing a tantrum, picking up their ball and going home.
And it is not just the developers that have to raise their game when asked to meet increased levels of quality, it is the whole team and supporting teams around them. A soccer team promoted to a higher league must improve not only their team's ability but usually the team's whole environment including the pitch, training facilities, player's renumeration packages, and so on. Similarly, simply improving developer's skill levels is unlikely to produce significantly better results if corresponding improvements in requirements analysis, testing, developer tooling, etc. are not made.
High levels of ability can also be problematic in a football team. If one player is so much better than the rest of the team, the team can start to become dependent upon the consistent, match-winning performance of that one player. The rest of the team can subconsciously start to under-perform, waiting for the team hero to do his or her magic. Removing that hero, although counter-intuitive, can sometimes cause the rest of the team to pull together to produce better results, at least for a while. In contrast, leave the hero in the team when that player experiences a drop in form, and the team can find it inexplicably difficult to produce the results that are expected of them.
The same can happen with so-called hero developers in software teams. The person that dug the team out of a hole on the last three projects, releases, or sprints, burns himself out, and the team is suddenly not able to deliver as before because they are all expecting the hero developer to do it again. The hero leaves the team and suddenly the team outperforms because they all discover that they can raise their game together to more than compensate.
A good football team coach or manager does not build their team around a single great player if they want sustained success. Unfortunately, in software development, the analogous situation occurs far too often.
Team Composition and Cross-Functional Teams
In addition to the rules and playing the game well, consider and contrast the team composition, overall team size, and length of playing time in American Football, Association Football (soccer), and Rugby. Then compare this to the cross-functional teams that agile software development approaches advocate in contrast to the specialised teams of more traditional phased approaches to software development.
- American Football has specialized units (offense, defense, kicking), only some of which are on the field at any one
time, and the game stops each time one of these units swaps with the one currently on the field.
- Soccer and rugby, in contrast, do not have specialist units in this way; the team on the field always contains all
the roles needed to play the whole game and play does not stop nearly so often as it does in American Football.
The most obvious result of this is that soccer and rugby fit more actual playing time into a shorter period of time than American Football; primarily because there are less breaks in the flow of play that interruptions (in the form of TV commercials) can take place in, but also purely from the time needed to handover from one specialized unit to another.
The total amount of time taken to play a game is not particularly important to fans of that sport, and indeed many will prefer the convenience of frequent breaks in the action. It certainly does not imply one sport is any better than another. In contrast, the total amount of time to complete a software development project is very significant for software development managers.
In addition, the proportion of a team's players that are not on the field at any point in time is a significantly larger for American Football than it is for soccer and rugby. Again, overall team size may not be particularly significant for sport, but it is important for a cost-constrained software development effort.
The hand-over time between two specialist teams in American Football is usually trivial compared to the hand-over time in a software development project. In the football game, the team being handed-over to is sitting on the bench carefully watching the game. They know exactly what the circumstances, current context and status of the game is. They are all immediately ready to leave the bench and take to the field, and they do not have managers insisting they participate in other matches at the same time as this one.
In contrast, specialist software development teams such as business analyst teams, architecture teams, design teams, testing teams, etc., frequently require their members to be working on multiple, concurrent projects. Those team members have little chance of observing in detail how other teams are working on a particular project. The hand-over typically takes place through long meetings and document reviews if the team are lucky, or if the schedule is under-pressure, short meetings and documents 'thrown over the wall'.
Of course, we could debate other aspects of this. Possibly, specialist teams have the potential to produce higher quality outputs than their cross-functional counterparts. Football games are frequently higher scoring than soccer games, for example.
Soccer and rugby teams have different levels of specialization and flexibility within their team structures even though the overall team is cross-functional, and the replacement or substitution of a single player during a game can radically change the shape and the way a team plays, for better or for worse. For example, it is highly unusual for a rugby player to switch between playing in the forwards (scrum) and playing in the backs (line) but it is possible when necessary. Some top soccer players are able to play in a number of different positions on the pitch but others only perform at the required level when playing in their accustomed position.
Agile software development approaches usually call for cross-functional teams but opinion differs on how much specialisation is appropriate within a particular team. Some strongly advocate that every member of the team be able to do any task; in other words, be able to play all positions equally well. This might be ideal but as in soccer, it is usually unrealistic and can lead to people under-performing. Like soccer, it is the whole team that needs to be cross-functional not every individual team member. It is a cross-functional team that is asked for, not a team of cross-functional individuals. The team as a whole needs to contain all the skills, ability and experience needed to repeatedly produce the required results to the level of completeness dictated by the team's agreed 'definition of done'. It does not mean that each person on the team needs all those skills, ability and experience.
Comparing and contrasting football and software development can undoubtedly be taken much further and more similarities and differences explored. Comparisons with other types of sport, with film-making, and planning and executing military missions would also be interesting. This is especially true now that the traditional comparisons of construction, and manufacturing have been explored so deeply by so many over the last few decades.
Gerald M. Weinberg, Quality Software Management: Volume 4 Anticipating Change, 1997
The premise behind eXtreme Programming is that the cost of making changes to software does not need to grow
exponentially more expensive throughout a project or product development life-cycle. That the cost of change does
increase exponentially over-time is attributed to unnecessary complexity added early in the project product life-cycle;
complexity that provides the flexibility to address all the changes that might be asked for in the future.
Scrum splits a project into a number of fixed length time boxes or iterations called
sprints. At the beginning of each sprint the project team meets to select a subset of items from a priortised to-do
list known as the product backlog. The subset of items chosen from the product backlog are the items that provide the
most business value for the customer and which the team believe they can complete by the end of the sprint. This
selection process is known as Sprint Planning.
FDD combines key advantages of other agile approaches with model-centric techniques and
fluid team organisation. This means that FDD easily scales to much larger teams and projects than generally recommended
for other agile approaches. FDD is also characterised by an emphasis on quality throughout the process, and timely,
accurate, meaningful status reporting and progress tracking for all levels of leadership.
Domain-Driven Design comes as a bit of a surprise to those who have been taught
that agile software development and especially eXtreme Programming do away with the need for analysis and design
techniques like object modeling and notations like the Unified Modeling
Language (UML). It is actually very obvious that any software team working in a .Net language, Java, Objective-C,
C++ or any of the object-oriented dynamic languages such as Python or Ruby has an object model at the heart of their