Skip to content

Demystifying Agile Project Team Intercommunication

Composing the Perfect Agile Project Team

A software project’s complexity is proportional to the agile project team’s size. The problem of team size is not specific to software engineers; people in other industries, such as music, deal with it as well.

One of the most significant constraints to successful project completion is poor communication within and among the team. The group intercommunication formula is described mathematically as n (n − 1) / 2 (see The Mythical Man-Month ). For example, if you have 50 developers trying to communicate on a given project, the result is 1225 channels of communication (50 * (50 – 1) / 2 = 1225)! From a management perspective, a standard solution to failing projects is to add more people; while this is sometimes a valid solution, it often adds complexity.

The Group Intercommunication Problem

A natural side effect of the group intercommunication problem is specialization. As the team grows, people must rely more on a single point of communication which causes managers and directors to emerge, thus forcing the individuals to specialize their parts even more. You can be a one-person band (low specialization), but more specialization is required as you add more people to your band (or software team).

For example, in a non-one-person band, you typically see a power trio. The specialization begins there, with one person playing drums, bass, or guitar (high specialization). One is partially specialized because they typically sing, sometimes play an instrument, and provide coordination. As you add more people to the band, more specialization becomes necessary. The extent is an orchestra with so much vocation that a director becomes required.

Finding the Agile Development Melody

Have you ever played in a band? Have you been on an agile project team? How many people were in it? Just you? More than four? You can be a lone wolf with music and software, but typically running in packs yields tremendous success, regardless of how you measure it.

We’ve all heard of software projects where one or two people have stayed up extraordinary hours to pull off some magical implementation; however, this is not the norm. You’ve probably also been on large projects with dozens of super-smart developers only to run over time and budget creating a Swiss army knife.

The agile software development movement addresses such complexities in the middle of the happy medium.

Reese Hodge leads an agile development team as they collaborate during a code review.

Interestingly, 5 – 11 people are typically the magic number. Why is this? It has nothing to do with music or software but instead the interactions and synchronization of thoughts and concepts by the team members creating the medium. Communication quality diminishes as team size increases, and from my experience, this isn’t a problem just in the software industry.

Creating a Cacophony

Why is it harmful to have too many people on a team?

The consequences of expanding an agile project team too drastically go back to the “group intercommunication formula” mentioned above. Having more people introduces more communication channels, which naturally increases complexity.

When does it cross the line between helpful collaboration and detrimental arguing?

The answer is it depends in the music industry and software. For example, it depends on how tight-knit the group is and the duration of time they’ve worked together.

Coding in Harmony

Be mindful of your agile project team size as it grows and shrinks because this can indicate a more fundamental problem that isn’t due to the song or project. It’s important to note that being a rock star is not more admirable than being an orchestra member. Likewise, a small group with a single rock star can be a huge success, but an orchestra with many rock stars will probably not be successful.

What has your experience been? Have you been on a failing project where adding more people to the agile project team was the solution? What was the outcome? What about a successful project? I would love to hear your feedback.

Want More?

Check out Demystifying the Requirements-Gathering Environment and Dare to Lead: Leadership Without Armor for more tips on communicating effectively at every step of the agile development process.