Scrum is based on self-managed teams. Self-managed teams are able to evolve and adapt quicker in today’s highly complex working environments than traditional command-and-control management structures. At the same time, self-managed teams are more robust to external disturbances, are faster and more creative in problem solving as they use the full potential of the team and not only one single decision making (and often bottle-necked) brain as seen in hierarchical command-and-control structures. In this blog, I will elaborate on two questions “How to actually “do” self-management?” and “What do I need to help teams to self-manage into more than just a group of individual people?”
What is self-management?
Photo by James Wainscoat on Unsplash
“Knowledge workers have to manage themselves. They have to have autonomy”, leadership guru Peter Drucker states in his book „Management Challenges for the 21st Century“
This resonates with the Agile idea that teams “are self-managing, meaning they internally decide who does what, when, and how.” (Scrum Guide)
Whereas manager-led teams leave team members only the authority for task execution while managers monitor and manage their work, self-managing teams have the authority to decide autonomously who does what, when and how.
Self-management can’t be imposed on teams. No one can establish self-management or order teams to self-manage. Self-management needs to emerge by providing good engaging goals and supportive boundaries.
The degree, direction and intensity of self-management can be influenced and fostered by manipulating those two crucial ingredients.
Both ingredients are needed to give the team the frame and direction in which they operate. They give guidance in what to achieve and they clarify the solution space.
Ingredient #1: Have a good goal
A good goal motivates and gives context about the purpose and the reasons why the team is trying to achieve it. It aligns the team, helps with planning and leaves room for the team to decide on how to achieve the goal. A good goal also helps to remain on track in case distractions occur.
If no goal is set, teams don’t know the direction in which to set out and get lost. They dive head first into something, don’t make much progress as they struggle to measure and often fail as they do not know when they are done.
A goal also helps in communicating and realizing when the team is done.
In Scrum this is why the Scrum Team works towards a Product Goal and agrees upon a Sprint Goal every Sprint during Sprint Planning.
The Product Goal gives the context, the why behind the development initiative and provides focus for the Scrum Team towards a larger valuable objective. Each Sprint should bring the product closer to the overall Product Goal.
The Sprint Goal gives the shorter term objective of the Product Backlog items delivered in the Sprint. It gives the reason why the Scrum Team is building the selected Product Backlog items into the Sprint’s Increment. The Sprint Goal helps the team to decide on what to do when undiscovered work emerges during the Sprint.
A good Sprint Goal is understood, concrete and measurable. Jurgen Appelo’s Checklist for Agile Goals and Roman Pichler’s Sprint Goal template can help Scrum Teams to craft a concrete and measurable Sprint Goal.
A confidence check formulated as a fist-of-five scale question[1]during Sprint Planning can help to improve the team’s confidence and understanding further.
A good Sprint Goal is visible to the Scrum Team, often placed on the Scrum board in the team space. By referring to a visible Sprint Goal the Scrum Team can evaluate its progress and decide on the next actions in order to reach it at the Daily Scrum.
Same is valid for the Product Goal. As the Product Goal is part of the Product Backlog, it is very visible to the Scrum Team. This helps the team stay clear and focused during refinement, when they split the long-term objective into smaller chunks of valuable work for the next Sprints.
Ingredient #2: Boundaries
Besides goals, teams need boundaries to self-manage. Teams without (or too vague) boundaries lack alignment and suffer from too many possibilities.
Too restrictive boundaries reduce self-management as it restricts creativity and autonomy; hence they often lead to a lack of team motivation and commitment.
Photo by Robert Katzki on Unsplash
Boundaries fostering self-management are supportive. They are simple. Everybody in the team knows them. They are accepted as everybody sees the underlying value and purpose. Those Boundaries are well balanced, give guidance and leave autonomy for the team at the same time. Those boundaries build and support a trustful and safe frame in which information, opinion and knowledge is shared openly between the team members, so that creative collaboration becomes possible.
With its minimalistic set of rules the Scrum Framework itself is a well-balanced set of boundaries. Its rules are targeted to enable empirism, creativity and autonomy, hence promoting self-management within the Scrum team:
- The Scrum Events and Scrum Artifacts provide transparency and fast feedback so that the Scrum Team can frequently inspect results and adapt if results are out of acceptable tolerance
- The Scrum roles separate the responsibilities into the what to do (Product Owner), the how to do the work (Developers) and the framework (Scrum Master)
- Timeboxing ensures that the Scrum Team remains focused, synchronized within its team members and in line with its stakeholders
- The Definition of Done creates transparency and trust about what needs to be done in order to get the Increment released to the customer
- The Scrum values focus, respect, openness, commitment and courage all serve to build trust as key foundation for collaboration
The Scrum Framework defines these boundaries and at the same time leaves a lot of room to the Scrum team to choose how to exactly apply the rules. Often, the Scrum Team chooses to implement additional strategies and tactics to optimize their working model.
There are more boundaries to teams: budget, organizational, management, market boundaries and other.
As Scrum Master, I often see teams working in environments with highly restrictive boundaries hindering the team in its autonomy and flexibility, and thus in its ability to self-manage.
As Scrum Master we can’t impose self-management on teams but we can work on the boundaries, which restrict teams in their ability to self-manage.
Work on the boundaries
Start with making the boundaries visible. Ask the team:
“What are our current boundaries and how do we perceive them as a team in delivering the Increment?”
Concentrate on the most hindering boundaries. Describe their impact. Ask the team what needs to change in order to perceive them more supportive and less restrictive. Helpful questions could be:
- What would make our boundaries more supportive with regards to openness and transparency?
- What would help us in delivering the Increment?
- How could we change the existing boundaries in order to speed up decision-making?
Tools which I find helpful in answering these questions are use case diagrams, cross team dependency boards or management 3.0 delegation boards to illustrate the team’s areas of decision authority.
Next, let the team formulate the expected benefits if the boundaries change. What would be a concrete small, measurable and promising next step for the team? Discuss who can help in pushing the boundaries.
Then make the boundaries, the impact, the proposed experiment and the expected benefits visible to management. Search for and implement together with management experiments in order to change the most hindering boundaries. Measure the outcome, inspect & adapt accordingly. Be aware of the local optimization vs. global de-optimization trap – another topic itself, which I will address in another post.
Conclusion
Scrum is based on and helps with establishing self-managing teams.
Scrum Teams are self-managing in that no one (for example, a manager) tells a Scrum Team member who, what, how and when to do their work.
Self-management cannot be imposed on the team. The degree to which this self-management is perceived as “successful” depends on
- whether a good goal is set and
- whether supporting boundaries exist
If we want to have truly successful autonomous self-managing teams we should work on these ingredients. As Scrum Masters, agile coaches or managers we can’t work on teams to make them self-manage but we can help teams to set (and achieve) good goals, and we can collaboratively work on the boundaries that restrict or encourage self-management.
How about you? Where have you seen goals and boundaries fostering or restricting self-managing teams? Which tools do you use to visualize and push boundaries?
Further Reading
Management Challenges for the 21st Century
Management3.0 delegation board
[1] Such as “On a scale of 0 (not confident / understandable / measurable at all) – to 5 (very confident / …)”