Successful Teamwork: Self-organizing teams and their responsibilities
Most projects are too large and too complex to be fully completed by one person alone. Therefore, teams have been forming regularly for many years to accomplish tasks together. What are the things to consider when forming a team?
According to Hackman [1], there are four points that should be considered when forming a team:
- Defining the team’s purpose and setting the overall direction
- Composition of the team and embedding the team in the organization and its context
- Organizing the work of the team, managing and monitoring the work process and progress
- Completion of the work
Based on which of these tasks are performed by the team (or management), the degree of autonomy of a team can be classified. These different degrees of autonomy are discussed in this article. It should be noted that much of this article is based on an excellent book by Hoffmann and Roock [2].
Manager-led team
If the team is solely responsible for doing the actual work (point 4), the manager must take over the remaining points 1–3. This distribution of roles is often described negatively with the term Taylorism. Typical for such manager-led teams are the following characteristics:
- Detailed specification of the work method by the manager
- Determination of the place and the time of performance by the manager
- Extremely detailed and decomposed work tasks by the manager
- One-way communication from manager to team members, with fixed and narrow content
- Detailed objectives set by the manager with a connection to the company objective that is not always apparent to individual team members
- External (quality) control
Of course, there are cases in which such a separation of executive and planning work makes sense. In the case of repetitive, non-complex tasks (for example, in series production), this method has been established for many years and delivers reliable and dependable results. Agile project management is not suitable for such tasks. At the same time, a manager-led team cannot be considered an agile team either, because the team is not adaptable. All adjustments to changing conditions must instead be made by management.
Self-managing team
A self-managing team takes over the organization of the work (point 3) in addition to the completion of the work (point 4). This is the minimum requirement for an agile team, so from here on we can speak of agile teams.
This organization of the work includes three sub-areas. First, the team itself should decide who takes on which task and when. This also includes the consideration of how tasks should be subdivided. In the Scrum framework, sprint planning is used for this purpose. Second, the team should monitor the progress of the work itself; in the Scrum framework, this happens in the dailies. Thirdly, it is the team’s task to improve its own team organization itself. The Scrum framework uses the retrospective for this purpose.
There are some requirements for a team to be self-managing. At the beginning, the team usually has to learn to plan its own work, and to take responsibility for this planning. A particular challenge is communication by the manager. In manager-led teams, work planning is simply communicated, but it is precisely this work planning that is supposed to be done by the team. So instead, communication needs to be at a higher level, which means communicating the team purpose and the organizational context. This leads to transparency in communication, and requires a significant shift in thinking. Possible models for how such team purposes can be communicated include visions in the Scrum framework, the management-by-objectives model, or the North Star concept.
So far, I have been talking about posed tasks. In the agile environment this is rather uncommon, instead customer requirements are usually formulated, for example through user stories. This orientation to customer needs is fundamentally important if a team is to work in a way that optimizes customer value. This means that translating the customer’s needs into corresponding tasks is part of work planning and is therefore also the team’s task. A useful task for the manager (or a product owner) is usually the prioritization of requirements.
Furthermore, a team must be able to completely fulfil the requirements. To do this, a team must be able to cover all relevant areas. Cross-functional teams are particularly suitable here. At the same time, the team itself often knows best which skills the team still lacks. Unfortunately, self-managing teams cannot do anything to build up missing skills; the transition to the self-designing team is fluid.
Self-designing team
Self-designing teams also take on the task of team composition and embedding the team in the organization.
Team composition includes what roles are needed on the team, which individuals are team members, and whether skills need to be built through continuing education of individual team members. Of course, this also requires communication with other parts of the organization, especially if some individuals are needed by multiple teams. Organizing interfaces and how multiple teams work together now also falls under the purview of the team.
Again, there are some requirements for a team to be self-designing. Again, a team must be willing to accept these additional responsibilities and be coached to use these responsibilities consciously. In addition, it may be useful to discuss budgets with the team if they want to hire additional team members.
Depending on the framework used, it may also be necessary for the team to be able to completely process and fulfil all of a customer’s requirements. This is especially the case with Scrum. If the Kanban framework is used, this requirement is not mandatory, as specialized teams are also allowed here. In this case, the team must invest significantly more effort in the interaction with other specialized teams of the company. Since there is a risk of local optimization here, while at the same time the customer’s needs slip out of focus, the Kanban framework is only recommended for experienced teams.
Self-governing team
Self-governing teams have the highest level of responsibility and autonomy. In addition to the tasks mentioned so far, self-governing teams also take on defining and adapting the team’s purpose. This means that teams decide for themselves whether they exist, who their customers are, and what product vision they want to fulfil for those customers. At the same time, self-governing teams are allowed to adjust these aspects at any time, and if in doubt, terminate and dissolve the team.
On the one hand, this sounds like chaos; on the other, it leads to maximum flexibility for teams should requirements change quickly. In practice, requirements usually do not change that quickly, so self-designing teams are often sufficient. However, there are two scenarios in which self-governing teams can be useful, and both are based on requirements that are not precisely known at the beginning.
The first scenario is the startup. Here, it is assumed that at the beginning of a startup it is not clear which customers and customer needs are to be addressed. Instead, the aim here is to work out, through direct and ongoing interaction with the market, which customer groups actually exist, what requirements they have, and how these are to be met by a product vision.
The second scenario is horizon 3 development. Actually, this scenario is not really different from a startup, since startups (should) begin in the third horizon. Nevertheless, this scenario is listed separately because innovation processes also take place in classic companies across the three horizons. The concept is therefore the same as in the first scenario: at the beginning of an innovation process, the customer groups and customer needs must first be worked out so that a product can be developed for them.
There are challenges here as well. If teams are to be flexible enough to adapt to changing requirements, these requirements must be reviewed regularly. This requires an iterative process with ongoing collaboration with customers. It also requires teams to be requirements-driven, not simply implementing exciting technology trends.
Summary
If a team is to develop a product based on customer needs, this requires a certain degree of flexibility. This requires the transfer of classic management tasks into the hands of the team, so that it is not always necessary to wait for translations and decisions from management. To ensure that this system does not descend into chaos, a clear framework must be defined. Also, the team needs to be trained in the skills they need to effectively fill that framework.
My personal experience is that self-managing teams in a supporting framework like Scrum can create value in many environments. The concept works in large corporations, family businesses, and startups as well as in national or international organizations. Often I experience that self-managing teams learn quickly, and want to evolve into self-designing teams. This development is to be welcomed, and leads to teams being even better at creating value for the customer (and thus for the company). Unfortunately, at this point, organizational structure is a common obstacle, as a hierarchical understanding with organizational charts does not easily fit autonomous teams and their composition. However, if the organization is willing to work in a more agile way, autonomous teams can bring great benefits.
[1] J. R. Hackman, Leading Teams: Setting the Stage for Great Performances, 1. Ed., Harvard Business Review Press, Brighton, 2002.
[2] J. Hoffmann, S. Roock, Agile Unternehmen: Veränderungsprozesse gestalten, agile Prinzipien verankern, Selbstorganisation und neue Führungsstile etablieren, 1. Ed., dpunkt.verlag GmbH, Heidelberg, 2018.
