Team Forming is a technique used to identify a team's purpose, ways of working and interfaces.
The Business of Software Engineering is a social one. People, working together achieve business value. Processes, plans and organization charts don’t.
Much of the conflict we've observed in organizations is inherent in the internal team structures and inter-team relationships caused by either dysfunctional or emergent organizational design. Holistic Software Development focuses on tried and tested mechanisms for effective team forming. This practice looks at effective Team Forming.
To get work done effectively we need teams to work together effectively and that means enabling the team to form relationships and collaborate together as a social network. Enabling these social mechanisms in and across teams is sometimes called "Enterprise 2.0", "Social Enterprise" or "Social Business" which are often supported with social business tools.
Forming a Team
Team Forming is best understood in the context of Bruce Tuckman's stages of group development (Forming -> Storming -> Norming -> Performing) that describe the behavioral states teams go through. The Team Forming practice is designed to give the best possible start to a team so that it might reach the Performing stage by deliberately drawing out some of the issues that can derail a team during its lifetime.
Teams can either be formed externally by a leader or can self-organize. Self-organizing teams have been found to operate more effectively than many externally organized teams but the choice is a complex matter informed by business decision making, culture, team goals, required and available skills, levels of mastery, organizational trust and risk impact.
In either case the challenges presented in Team Forming are creating interpersonal human relationships, understanding skills, establishing a common understanding of the team's purpose and ultimately creating a team culture. We do these with a Team Forming Workshop.
A number of methods can be used to structure the Team Forming workshop, with the method used chosen to best resonate with business tools already in use. The primary methods include using a form of "Business Model Canvas" if that is used at Business Strategy level or using a Team Charter to structure the workshop. Both methods result in the same information and interactions but structure the workshop differently.
A Team Charter explains the purpose, structure, membership and ways of working for a team. Creating a Team Charter is an exercise in Team Forming and the Charter is a useful way of communicating the intentions of the team to other teams, for on-boarding new members and for alignment with business goals.
Maintaining a Team
Teams need maintenance. They will, and should, change over time as they react to their experience, external events and critically membership changes. Whenever people leave or join a team it’s center of gravity changes. We recommend putting effort into maintaining teams.
We recommend that new team members are explicitly on-boarded culturally into a team by walking them through the team forming workshop activities and the resulting Team Charter or other outputs. To maintain team communication and cohesiveness we recommend regular team retrospectives are held.
Retrospectives are periodic team based reviews focusing on what went well and what went wrong so that lessons can be learned and processes improved.
Cross Team Interactions
Cross-team communication is often a major source of systemic dysfunction in large/complex organizations. Efficient and effective teams of teams rarely happen by accident so we recommend using Team Forming techniques at this cross-team level as well as inside teams.
Two useful tools for smoothing cross-team communications are establishing a common understanding of the intent of each team by sharing and discussion of each others Team Charter and also a common understanding of the definitions of done that teams are collectively working towards or use as quality gates between teams.
Transactional behaviors between teams can lead to dysfunctional behaviors as teams abdicate holistic responsibility for work to each other. Team collaboration must be encouraged by "establishing pull" throughout the delivery system so that successful teams are those who work together to deliver business value, not simply their local team's output.
Teams are most effective when they are cohesive and have as little coupling as possible (similar to good architecture/design principles). This means that teams need to have well rounded functions, splitting related functions across teams introduces barriers to coherent delivery. For example, we recommend that the people needed to design, develop, test and deploy a component are part of a single team rather than having separate development, test and other teams for a single outcome.
Such divisions lead to "them and us" attitudes, increases in transactional behaviour and a lack of focus on coherent quality. Sometimes split-team models are introduced as a way of sharing resources across teams but this typically makes the shared team, and its workflow management, a resource and performance bottleneck. Instead we recommend sharing the limited resources across teams - if they become overloaded then their workflow must either be reduced or more resources must be invested in.
Organizing Multiple Teams
As businesses grow beyond single isolated teams they tend to seek ways to structure themselves in an attempt to make work and people more "manageable". This is based on the mistaken belief that structure is organization, whereas structure is only one part of organization. Structure can be useful when it reflects desired cultural models and isolates truly separate concerns (e.g. ethical divides in different parts of a business such as tax advice vs. audit assurance) or completely separate brands/business lines. However, by its nature, structure can be divisive.
Every team boundary, or other structural boundary, typically causes a team inbox, backlog or other form of work queue adding to the total Lead Time for work unnecessarily. As a result, structure increases the impedance in the organization to doing a piece of work.