One term you hear a lot when talking about agile development is cross functional team. A cross functional team is a team with a common goal where the team members have all the expertise that is needed to reach the goal. This means that the team is able to fulfill its goal independently, without too much involvement from outside of the team.
“The best architectures, requirements, and designs
emerge from self-organizing teams”
One of the principles behind the Agile Manifesto
© 2001, the authors of the Agile Manifesto http://agilemanifesto.org/principles.html
In software development, a cross functional team can consist of a team lead, requirements engineers, software designers and testers. The size of the team should be around 5-10 people. Since the team has the ability to create new functionality, from writing requirements, to designing the software and test the feature, you minimize the hand over between different disciplines. Teams that get the responsibility for an entire feature also tend to be more motivated, seeing that what they do gives customer value. Giving responsibility and trust to people also leads to increased accountability, both as individuals and as a team. When you don’t have anyone outside the team to blame, you cooperate in the team and make sure that the things that you create work.
Although a cross functional team has all expertise needed to fulfill its tasks, it does not mean that all people in the team need to do all different kinds of tasks. Typically, each team member is a specialist of something. But it helps a lot if the team members can do different tasks. The term T-shaped person is a metaphor where the vertical bar of the T represents the depth of the knowledge in a certain area and the horizontal bar represents the broad base of knowledge in other areas. I.e. a T-shaped person is really good at one thing, but can also help doing other things in the team. Having T-shaped persons in a team means that you get less vulnerable to personnel changes and helps the team to manage workload. For example, there might be a lot of requirements to be written in the beginning of a delivery period, and lot of testing to be done in the end. Having T-shaped people in the team means that the team members can help balance the workload between themselves.