One indicator of a successful project is the desire of the customer/client to have more projects. This desire can quickly grow in volume to the point that the original team no longer has the bandwidth to accommodate all of the requests without augmenting the team. Many teams grow organically and, over time, they often grow so large as to become unwieldy. What is a good way to deal with this? How can we continue capturing the benefits of Agile while still expanding bot the team and the business?

I want to explore a couple of aspects of Agile Teams. First, Agile Teams have all of the skills necessary to get the job done. Where possible we want to avoid the need to reach outside the team in order to accomplish the client’s ask. This enables the team to “own” the work and automatically removes many of the potential blockers to success.

Second, Agile Teams need to be fully dedicated to the team. In this case dedication can be viewed as both a dedication of time and a commitment to the team’s success. Teams that are full-time experience less context switching and have the benefit of only learning how one team works. Being committed to the success of the team ensures that every individual is striving for the success of other team members rather than seeking for individual glory. Where this is not the case, a team will quickly fall apart.

Agile Teams also need to be a manageable size. The general rule of thumb is that 5-9 individuals make a good sized team. Much less than 5 and you probably won’t have all of the skillsets required. Much larger than 9 and you will most likely have too many moving parts to keep track of. In addition, humans don’t do so well at forging the close relationships required in a team with many people. Trying maintain a working relationship with more than 7 people is a bit difficult.

The last aspect of Agile Teams is perhaps the most important. The team needs to be given responsibility and authority for their work. In an organically grown organization, it can be all too easy for original leadership to retain authority after a new team has been created. This will result in the team being a team on paper, but not really providing the full expected benefits. Some examples of retained authority are:

  • Timelines are committed to without the input of the team
  • Authority figures outside the team make requests of individuals rather than requests of the team
  • Scope changes without the team being involved

So, how do you deal with a team that has grown too large? You divide it. Find a logical grouping of individuals and empower them to be responsible for their work. This usually means that there is a product owner, a tester and a couple of doers. The nature of the work will further define the types of roles that are necessary on the team. Once the team has been formed… leave them together. Most of the benefits of the team don’t become available until the team has been able to work together for a few months.