Scrum is based on self-organized teams. Self-organized 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-organized 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-organization?” and “What do I need to help teams to self-organize into more than just a group of individual people?”
What is self-organization?
Photo by James Wainscoat on Unsplash
According to Wikipedia self-organization is not directly related to team success but is merely a process where some form of overall order arises from local interactions between parts of an initially disordered system
Self-organization can’t be imposed on teams. No one can establish self-organization or order teams to self-organize. Self-organization happens; all the time and as soon as two ingredients are given: Boundaries and goals.
The degree, direction and intensity of self-organization 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 Development Team together with the Product Owner agrees upon a Sprint Goal during Sprint Planning.
The Sprint Goal gives the overarching 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 Development Team can evaluate its progress and decide on the next actions in order to reach it at the Daily Scrum.
Ingredient #2: Boundaries
Besides goals, teams need boundaries to self-organize. Teams without (or too vague) boundaries lack alignment and suffer from too many possibilities.
Too restrictive boundaries reduce self-organization as it restricts creativity and autonomy; hence they often lead to a lack of team motivation and commitment.
Recommended for You
Webcast, December 18th: Optimizing Customer Engagement with User Intent
Photo by Robert Katzki on Unsplash
Boundaries fostering self-organization 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-organization within the Scrum team:
- The Scrum Events and Scrum Artifacts provide transparency and fast feedback so that the Development 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 (Development Team) and the framework (Scrum Master)
- Timeboxing ensures that the Development 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 Development 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-organize.
As Scrum Master we can’t impose self-organization on teams but we can work on the boundaries, which restrict teams in their ability to self-organize.
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 self-organization, just as the Agile Manifesto mentions: “the best architectures, requirements, and designs emerge from self-organizing teams“
Self-organization cannot be imposed on the team; it happens in teams all the time anyway. The degree to which this self-organization 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-organizing teams we should work on these ingredients. As Scrum Masters, agile coaches or managers we can’t work on teams to make them self-organize but we can help teams to set (and achieve) good goals, and we can collaboratively work on the boundaries that restrict or encourage self-organization.
How about you? Where have you seen goals and boundaries fostering or restricting self-organizing teams? Which tools do you use to visualize and push boundaries?