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?
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 questionduring 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 …read more
Read more here:: B2CMarketingInsider