Introduction
Successful teams exhibit elements that can be utilized and fostered by leaders in their own teams to increase performance and collaboration. There are six components leaders should consider when fostering team development. These components include Size, Composition, Governance, Identity, Interaction and Culture. There is not one right composition of these elements rather a unique blending that each group requires to become a high performing team. An example of the impact of these elements can be viewed in the cases of two real teams. The first team, CodeMonkeys, was a software development team assembled to fulfill the coding needs of a major software initiative. The second team, Pixelators, were also software developers but were filing more of a support and maintenance role for a single application. Both of these teams exhibit characteristics from each of the six core elements. The ability of these teams to perform at their maximum was driven by this composition.
Various Elements of Team
Size
The number of members of a team impacts many of the other elements. Smaller teams trend to communicate better and require less governance. Conversely as the size of these teams grows, members tend to collaborate less (Gratton & Erickson, 2007). The Pixelators included 8 core members located in the same office space. The CodeMonkeys on the other hand varied between 30-80 at any given time and were spread between onsite and offshore locations. The smaller Pixelators team clearly collaborated much more frequently than the larger CodeMonkeys team.
Composition
Teams are built for various reasons and those needs dictate the various types of people the team needs. The composition of the teams extends beyond the technical skills of its members and includes some of the softer skills such as managing people and interpersonal communications. When building a team leaders should be mindful of the composition and makeup of the group. The Pixelators was a small team composed of individuals with unique skill sets. At most, two people would be a master of a particular skill. The team also had a breadth of leadership, interpersonal, and management skills to complete the structure. The CodeMonkeys on the other hand was comprised of individuals with similar skills. Members were interchangeable and common. The team lacked a sense of leadership or interpersonal skills and relied solely on the technical makeup to satisfy the needs of the project.
Governance
The governance of teams also varies based on size and makeup. Teams may be managed formally or self-managed. The larger and more sophisticated the monitoring and measurements become the more skilled the managers need to be (Liang, Rajan, & Ray, 2008) which can result in additional levels of skilled resources within the teams. Teams that are able to self govern tend to be given an objective and are able to figure out the means to accomplish it without being told. Managed teams are told not only what the objectives are but how and when to do each component. The CodeMonkeys had many levels of management and tools for tracking performance. The individuals felt no personal empowerment to make decisions on their own. When faced with an unexpected situation members would wait for direction rather than find a solution. The Pixelators represented a rather self directed team structure. While the group had formal management members were given objectives and were able to work out the solutions on their own. This built levels of trust and collaboration within the team making them ultimately more self sufficient.
Interaction
How members of the team communicate and collaborate plays an important role in the ability of the team to succeed. Face to face communication typically provides the best results but various technologies can be utilized to facilitate interactions. It should be noted however that teamwork most successfully occurs after team building, and too often this team building is lacking in online environments (Staggers, Garcia, & Nagelhout, 2008). This can be seen clearly with the CodeMonkey team. This larger group communicated regularly providing status reports and task updates to other members of the team. Little if any team building occurred and interpersonal interactions were minimal. Great distances and cold technology enabled individuals to isolate and function away from the team. The Pixilators worked in close proximity interacting both in person and through technology regularly daily. Team building occurred frequently as members discussed non work events building camaraderie and personal relationships
Identity
In order to build a team the individuals need to feel part of the group. To enable these teams need to be able to demonstrate boundaries of the team versus the rest of the world. This ability to identify the team can be address in multiple ways. Proximity and frequency provide the most straight forward means of designating groups. The closer individuals are to each other, the more likely they are to associate as a group. Additionally the more time these individuals spend together, through technology or in person, the more likely group tendencies will arise. To further enable the team identity leaders should consider a name for the group. Names promote a team atmosphere and support the bonding of a group into a team. The names used here are not the real names for these teams. Leadership however did provide CodeMonkeys with a name for the team. Unfortunately the high rate of turnover, great distances, and lack of interpersonal interactions left the group with a name and no identity. In reality the Pixilators did not have as strong a team name; however the proximity and shared purpose set the group apart as a team with a clear identity.
Ideology
Ultimately individuals bond with others who share similar traits. As teams form they build upon those shared values and ideals. Leaders have traditionally focused on three primary elements of team culture including Norms, Roles, and Goals, however these alone do not provide the means for a group to bond into a team. Norms, the rules and standards the team adopts, Roles each member holds and the Goals the team is working toward can be placed on the team or developed by the team. The CodeMonkeys had volumes of documentation clearly stating the norms of the team, how people should interact, how decisions were made etc. There were also scores of responsibility charts defining roles, and of course the project charter defined the goal. Yet with all these elements readily available none of the members really felt part of that ideal. One might suggest that the team culture needs to be developed and absorbed by the members rather than forced upon by outside entities. The Pixelators had no formal documentation stating role or norms but it was clear overtime that coming late to meetings was not acceptable and certain people were in more leadership positions than others. The team did not have a vision or mission statement but they all shared the same goals and objectives.
Conclusion
These six elements represent areas leadership needs to consider when developing teams. In most cases high performing teams bond on a personal level. Leadership needs to support team development by creating environments and situations with Size, Composition, Governance, Identity, Interaction and Culture that enable individuals to join and create high performing teams.
References
Gratton, L., & Erickson, T. J. (2007, Nov). 8 Ways to Build Collaborative Teams. Harvard Business Review , 85 (11), pp. p100-109.
Liang, P. J., Rajan, M. V., & Ray, K. (2008, May). Optimal Team Size and Monitoring in Organizations. Accounting Review , 83 (3), pp. p789-822.
Staggers, J., Garcia, S., & Nagelhout, E. (2008, Dec). Teamwork Through Team Building: Face-To-Face to Online. Business Communication Quarterly , 71 (4), pp. p472-487.
Frequently teams new to agile will size the work in a time based unit such as hours or days. This is a common carry over from traditional project management. While Agile does manage time and resources, the time is fixed not variable. In Agile an iteration or sprint is a fixed length of time typically between two or four weeks. A chart showing time spent working in an iteration isn’t that valuable. A better process is to view the amount of work a team can produce in a specific amount of time. This is called velocity. 
Lets look at an example. A small team is pulled together to work on a new project. They sit down and estimated 30 stories varying between 2 and 10 points of effort each. The team believes they can take on 30 points in the first iteration (two weeks). At the end of that iteration the team only completed 10 points. When planning the next iteration the team learns from the previous one and only plans to complete 15 points. Iteration 2 hits the mark, the team does complete 15 points. For Iteration 3 the team plans for 15 points again. This time however they are able to complete 17 points, they’re getting better. Iteration 4 they plan for 18 points but produce 22. Iteration 5 they plan for 20 but only produce 18. Feeling they’ve identified the standard velocity at 20 points, the team continues through the project allocating 20 points per iteration. With this in mind the team can look at the work produced and determine how productive they are and forecast a valid completion timeline. This forecast is the projected project burn-up. The burn up chart shows the actual accumulated work completed against the projected values across multiple iterations. The burn-up chart can also chart scope increases and decreases A burn-down chart on the other hand deals with a fixed amount of work and shows the amount of that work completed in a single iteration. Both of these commonly used planning and status charts can’t be produced without understanding what the velocity of the team is. 
