The four Levels of Autonomy – J.R. Hackman

the-four-levels-of-autonomy
The four Levels of Autonomy JR Hackman

Four levels of autonomy :The human species is not a loner. Even in prehistoric times, groups joined together and became teams, e.g. to be able to hunt larger animals that ensured their joint survival. This is still ingrained in us today. Companies are formed to create something together as a team or team of teams, to generate value that could not be created alone. Despite all this background, assessments still take place individually in many companies. What do successful teams look like, how do they come together, how dynamic or static must and may they be.

The Scrum Guide 2020 has also sharpened its view on teams or in particular the Scrum Team. While the pre-2020 version of the Scrum Guide spoke of the development team being self-organized — they decide HOW — the new Scrum Guide speaks of the Scrum team being self-managed, thus deciding HOW and WHAT.

The nature of self-determination was already published by J. Richard Hackman a few years ago.

Hackman distinguishes autonomy related to four different levels:

  1. Work
  2. Processes
  3. Structure
  4. Goals

Depending on the degree of autonomy, either the team or a management representative makes the decision.

Manager-led Teams (Level 1)

At the first level, the degree of autonomy of teams is not yet high or not really given. The team completes a task together, has a common goal. The team cannot make adjustments to the context without help or permission from management. This kind of autonomy is not in line with the recommendation of the Scrum Guide, neither the current one, nor the previous ones.

Self-Managing Teams (Level 2)

At Hackman’s second level, teams are autonomous in terms of work and processes for getting the work done. This corresponds to the idea of self-management according to Scrum, the team itself determines HOW the work is done, keeps an eye on the progress and adjusts, if necessary, the organization of the work. Since the product owner is also part of the Scrum team, the team also decides WHAT to do. The team needs to learn how to take shared responsibility to deliver value. From a Scrum perspective, this is helped by the Sprint Goal, which gives an alignment for the Sprint. Thus, there is a balance between alignment and autonomy. The team or teams, if there are several (for example in a scaling environment), must also learn that the solution is no longer dictated by management. The product owner only specifies the customer problem to be solved, e.g. getting from A to B, the solution is developed by the team. Teams that manage themselves must ensure that the skills required to find a solution are also available in the team. If this is not the case, the team must be trained accordingly or supplemented. In self-managing teams, this requirement can usually be brought to the Scrum Master, since the necessary authority to solve this without management permission is missing; this is only achieved or given at level three.

Self-designing Teams (Level 3)

In most organizations, teams are created by PUSH, i.e., management determines who is in a team and what product is to be developed. When a company reaches a higher level of self-determination, the teams also decide their structures themselves, and are therefore at level three with Hackman. If a team determines that they lack competencies to develop a solution end to end, the team has the authority to acquire the necessary knowledge, for example through training. If this is not the appropriate approach, the team can likewise take on new team members, even temporarily. Collaboration between teams also works better at this level, as the structures are self-organized by the teams. When assembling teams, care must be taken not to do so without necessary constraints. An important constraint in most contexts is that team members can implement product requirements end to end, so team members should go towards T-shape if possible. Teams should go toward feature teams and not be component teams (so, for example, a pure database team). The LeSS scaling approach recommends that teams be at this level to effectively develop a product together.

Self-governing Teams (Level 4)

At the last stage, and thus the fourth level according to Hackman, the teams no longer only determine the composition and interaction, but also the direction of their product without consulting management. Teams at this level are allowed to change the product vision or stop product development completely in order to operate better or differently in the market. Teams with such powers are completely oriented towards the market and decide everything, in relation to their stock and the team. For this it is necessary that the (Scrum) team has the authority to discard idea and products/product ideas.

Conclusion

The Scrum Guide 2020 has taken an important step to redefine the Scrum Team. The sub-team within the Scrum Team, the Development Team was abolished. This step helps to reduce hierarchies, even if they are only implicit within the Scrum Team and not to give the impression that the Product Owner and/or Scrum Master are the superiors of the Developers. It also helped to re-focus that the entire Scrum Team is self-managing and not just the Development Team self-organizing. This is a good step towards customer centricity, as the team as a whole is responsible for product success.

References

[1] „The 2020 Scrum Guide,“ 2020. [Online]. Available: https://scrumguides.org/scrum-guide.html

[2] The LeSS Company B.V., „Overview — Large Scale Scrum (LeSS),“ Mai 2019. [Online]. Available: https://less.works/

[3] R. Schröder, Follow … the path of Ray, Howard and Britta: Don’t call it agile transformation, yet!, München: RegSus Consulting GmbH, 2021

[4] J. R. Hackman, Leading Teams: Setting the Stage for Great Performances