Finding the right team

Who belongs in which team? What is the best size? Which roles need to be present in a team? How do we decide which team does what? These questions (and more) come up again and again when discussing larger agile organizations working on multiple projects or products. And it is one of the manager's key tasks to help grow a structure of teams within an agile organization so that the organization's goals are being met.

From four to nine - that's fine

Team size has been discussed at length in many books and blogs and I cannot add much insight here. Remember that the teams must be able to communicate well and therefore the size must not be too large. Any number with two digits is too large in my opinion. And to be able to compensate for absences and have sufficient diversity, I believe four is the minimum number. So there you have my suggested range: four to nine. In a Scrum context, for example, I really like a scrum team of seven, with one PO, one ScrumMaster and five development team members. I have seen this work well many times.

But who is on the team? Conventional wisdom calls for cross- (or multi-) functional teams. In other words have a bunch of people with diverse specialties on a team. Depending on the organization and its projects these could be developers with various areas of expertise, QA specialists, documentation experts, UI designers, but even business people such as marketing and sales could make sense if the results to be produced include, for example, sales kits or other business materials.For the most part, I agree with this conventional wisdom - cross-functional teams offer much greater flexibility and tend to be more efficient. Why more efficient? As I have pointed out in previous posts, I believe direct communication is key to high productivity. Efficiency reduces dramatically when communication takes long (not taking the direct route between the parties that need to talk) or even worse if the messages are compromised through too many indirections (I call this the 'Chinese Whispers' syndrome, after the children's game of that name - no offense to Chinese people or language). So it seems natural to put the people into one team who need to communicate much in order to implement some functionality. Depending on the functionality that the team typically needs to produce, this probably means that the team needs to have people with skills in various disciplines, in other words: cross-functional.But what about a skill that is only required occasionally and does not keep a person busy for a complete development iteration? It seems wasteful to include for example a technical writer in a team that only has a few paragraphs of help text for each implemented functionality. Ideally a person with writing skills will also be able to code or test or do other relevant tasks to complete the implementation. Unfortunately, there are very few gifted people that are specialists in many, diverse subjects.This is why I also find functional teams a useful construct in an agile organization. For example, a UIX team with experts on user interface design could make sense, or a team of technical writers.

And how do these teams work together with their cross-functional counterparts?

One option is to hire team members out temporarily to cross-functional teams. This way the specialist will be very involved in the actual implementation and the communication is easy, especially if the hired out person really physically moves to the hiring team for the duration. On the other hand it might well be very disturbing for the hiring team to incorporate a new and temporary team member, especially if the hiring period is short.I much prefer the concept of functional teams as service teams. They offer services to the cross-functional teams that those teams cannot provide themselves. In this way, the service teams can grow together as a team because they offer the services as a team not a single person. And they are able to have their own projects within an iteration. The UIX team could develop general UI components, stylesheets etc.

But such service teams must be able to deliver services on very short notice. A build and CI team, for example, may have to make branches available quickly due to an emergency patch to be delivered to a customer. Often the cross-functional development teams notice the need for a UIX service (e.g. some graphical component) only in the middle of a development iteration. So, the service teams will have to work in a highly event driven way, where the events coming in must be properly prioritized so that the team can focus on the most important services. Often, a Kanban organization works well for service teams.I use the term service deliberately. Service teams must make it their primary goal to serve the organization as quickly and efficiently as possible while maintaining the highest quality. All too often have we seen service teams deteriorate into isolated groups stymied by complicated service request processes. The rest of the organization must beg them for help or does not even dare to ask. Service teams must regard the rest of the organization as their valued customer and continue to ask them: How can we serve you even better.Are there even more types of teams around? What about Management? What kind of a team are they? How do they organize their work? I have some proposals which I intend to discuss here soon.See also previous posts from this series by Christof Braun:Manager in a networked organizationCommunities are communication bridgesAgile and organizational structuresRelated Training:Management 3.0