Mathematical Combination, Brooks’s Law, and the Implications for Team Communication
When it comes to communication and collaboration, there are certain patterns that have gained wide acceptance with regard to the size of groups (teams). One of those patterns relates to the “ideal size” of an Agile team, and it’s common to say that size is seven, plus or minus two. To help frame this conversation, I’m going to reference two concepts:
- Mathematical Combination
- Brooks’s Law
Mathematical Combination
One way to think about communication in groups is informed by the mathematical concept of combination. As articulated on Wikipedia:
“A combination is a selection of items from a set that has distinct members, such that the order of selection does not matter (unlike permutations). For example, given three fruits, say an apple, an orange and a pear, there are three combinations of two that can be drawn from this set: an apple and a pear; an apple and an orange; or a pear and an orange.”
I’m going to use this hand-drawn diagram to illustrate why this concept matters in a team communication context:
The “People” line represents team size, where in this example there are examples of teams with the size of 2, 3, 4, 5, and 6, represented by a straight line, a triangle, a rectangle, a pentagon, and a hexagon.
The “Interfaces” line represents the number of possible communication pathways among members of the team, where for a team of 2, there’s 1 possible communication pathway, and by the time team size reaches 6, there are already 15 possible communication pathways. And thus as team size continues to increase, the number of communication pathways grows rapidly. For example, when team size reaches 10 people, the number of possible communication pathways is 45, and on a 12-person team there are 66 possible communication pathways.
For anybody who has used asynchronous communication tools like Slack or Microsoft Teams, the greater the number of people communicating in a given channel at a time, the more obvious it often becomes when the potential for confusion sets in. And for synchronous communications, often manifested in the form of meetings, once again, the number of people in the meeting has a significant impact on the ability to communicate effectively (among other variables).
There are many other variables, in addition to team size, that come into play in a team context that can also inform the extent to which a team is able to effectively communicate and collaborate, which also merit consideration. For example:
- Geographic distribution. There are numerous ways in which teams can be distributed across geographies, such as having anywhere from one to all team members working remotely, potentially in different time zones, and potentially clustered into one or more localities that are close to offices where a cluster of people might work together in person some of the time, or all of the time.
- Areas of specialization. On many Agile teams, there might be two or more people doing front-end development, and a similar number doing back-end development, automated testing, or manual testing (to name just a few possibilities). Areas of specialization tend to drive specific behaviors when it comes to who communicates with whom, and at what frequency.
- Team dynamics. How long a particular team has worked together has implications for communication effectiveness, as does the specific communication habits that each team member might have, for example, more likely to communicate in writing than verbally.
Brooks’s Law
It is a common occurrence that when completion of work on a software product is going more slowly than what was expected, one of the first, if not the first, suggestions to be made is to assign more people to the team(s). Having observed this phenomenon many times himself, a Software Engineer named Fred Brooks wrote a book in 1975 called the Mythical Man Month that has been influential ever since it was published. The idea that has proved to have the greatest staying power from the book is assertion that he made that adding more people to a late software project makes it later, and this assertion has come to be referred to as Brook’s Law.
Among the observations that Brooks made were the following:
- There is a period of time during which people who have just joined a team are not fully productive, that is, “ramp-up time.”
- One or more existing members of the team are likely to need to spend time helping the new team member(s) get up to speed, thus impacting their ability to complete work.
- As described in the above section about mathematical combinations, the larger a team gets, the greater the number of communication pathways that exist among them.
Does Brooks’s Law mean that there is never a case where it might make sense to assign one or more people to a team, where the chief reason to do so is to speed up completion of a body of work? — No, it does not.
Other factors that merit consideration when considering changes to team composition include the following:
- Start time. One of the first questions that needs to be asked, but seldom is, with respect to expectations related to deadlines and dates, is whether the work actually started when it was supposed to. The reality is that far too often, work is “late” before it even begins, because certain assumptions where made about when the work would start which proved to be unrealistic. There are many ways in which this problem is manifested; to name one of them, a certain body of work is considered “done,” when in fact one or more team members are still doing work in that area, even though they have already started work on something new. Students of flow in particular will recognize the implications of this problem, where Work In Progress (WIP) is likely to increase, with a negative impact on Cycle Time and Throughput.
- Pay back period. Admittedly it can be a tricky business to guess how long it might take for a new team member to be able to fully contribute to a team’s work without assistance from anyone else. That being said, it is sometimes a reasonable assumption to make that the modified team will be able to complete more work than it could before team size increased. However, if the intention is to only add a team member for a
relatively short period of time (perhaps a Sprint or two on a Scrum team), given ramp-up time and its impact on existing team members, short-term team assignments are especially prone to not delivering the expected schedule improvement. - Team areas of specialization. As mentioned above, areas of specialization are a complicating factor on teams, with significant potential ramifications for team flow. Let’s say that a decision is made to add 2 Software Engineers to a 7-person team, and that there is one full-time Quality Engineer on the team. Let’s further suppose that the Quality Engineer was finding it challenging to complete the testing for the 4 software engineers that were already on the team, and that with two more Software Engineers on the team, the number of test cases to be executed is likely to increase. Not only are there implications for the team in question, there are often ripple effects, where the (now) larger team might ask a Quality Engineer on another team to help with testing.
- Team chemistry. Each team is its own unique entity; one of the intangibles associated with teams is that each time a person leaves or joins, it can have an impact on that team which can be difficult to predict, quite often putting the team into a different place on the forming-storming-norming-performing curve.
Conclusion
The nature of communication among people in a group is a complex topic, and I’ve only delved into a small set of factors that it can be helpful to consider when it comes to team composition and team size. Also significant in the context of Brooks’s Law is the way in which planning and forecasting is done in any given organizational context. There is plenty to read on the topic of forecasting alone. Below are a couple of examples of posts I’ve written on the topic:
and
