From the Agile Manifesto:
- “The best architectures, requirements, and designs emerge from self-organizing teams."
The Scrum Guide defines the power and authority of the team in terms of self-organization:
- defining the Scrum Team: “Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.”
- defining the Development Team role: “They [Development Team] are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.”
- defining the Scrum Master role: "The Scrum Master serves the Development Team in several ways, including: Coaching the Development Team in self-organization and cross-functionality."
- defining the Sprint Planning Meeting: "The Development Team self-organizes to undertake the work in the Sprint Backlog, both during the Sprint Planning Meeting and as needed throughout the Sprint...By the end of the Sprint Planning meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment."
- defining the Daily Scrum: "Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated increment in the remainder of the Sprint."
It's clear the Scrum Guide expects the Scrum Team, and more specifically, the Development Team, be a self-organizing body. However, the Scrum Guide gives no hints on how self-organization is achieved and maintained.
What is a Self-organized Team?
In his book, "The Leader's Guide to Radical Management: Reinventing the Workplace for the 21st Century", Stephen Denning defines a Self-organizing team as a team that can "decide how the work will be organized, who will do what, and in what order; select leaders and spokepersons; and can decide who should be a member of the team" *.
Qualities of a Self-organizing Team
Self-organizing teams are given the freedom to find the best solution to the problems given them. The Development Team is in full control of finding a solution to a given business problem and is not directed to a specific solution from outside the team. This means that although outsiders may provide solicited or unsolicited advice to the team, the team has the freedom to ignore that advice and follow their own instincts and intuition.
Self-organizing teams can react to problems quickly. Instead of waiting for a manager’s approval, the team has the authority to take necessary actions by itself. The team 'owns' the solution and Scrum provides the team all the latitude necessary to achieve it.
Self-organizing teams are cross-functional. The Development Team does not have dependencies on others outside the team to accomplish their work. The team doesn't have divisions of work based on specialized skills within the team e.g. the whole team is responsible for testing, not just the "tester". By being cross-functional, the team has the ability to organize themselves to respond to changes in project, customers, technologies, and requirements. Being a cross-functional team does not mean team members have equal knowledge and talent. Creativity and innovation largely result when team members of differing knowledge and talents debate possible solutions from their respective view-points.
Self-organizing teams value self-improvement and continuous learning. The team actively pursues self-improvement; to find better and innovative ways to work smarter and to satisfy the customer. For example, in order for the team to be cross-functional, they need to learn from each other; the "tester" on the team is teaching all the team members about testing. Furthermore, teams need to learn about the customer's needs and get frequent feedback from customers. Self-organizing teams are given the freedom to chose their own team goals every iteration to facilitate and implement self-improvement actions.
Self-organizing teams have a common focus. The self-organized team collectively understands the goal of the iteration, release or project and has a shared understanding of the solution. The team needs a compelling goal; one which the team feels is worthwhile to achieve. The team needs to re-enforce the understanding of the goal throughout the iteration. This is done through the inspect and adapt Daily Stand-up meeting.
Self-organizing teams have mutual trust and respect. Self-organizing team members are always open and honest, have the ability to voice ideas and opinions without fear of ridicule or rejection, and knowing others will accomplish the tasks assigned to them. Self-organizing team members value other team members for their unique contributions and opinions.
The Role Of Managers and Customers On The Self-organizing Team
In a recent InfoQ interview, Rashina Hoda says two environmental factors need to be in place to enable self-organization to emerge. These are:
- Senior management at the teams' organization must be able to provide freedom to the teams so that they can self-organize themselves.
- Customers must support the teams by being actively involved in the development process through providing regular requirements, clarifications, and feedback as required.
Senior management
"Self-organizing Agile teams ... require organization structures that are informal in practice, where the boundaries of hierarchy do not prohibit free flow of information and feedback. In an informal organizational structure, the senior management is directly accessible by all employees (maintaining an ‘opendoors’ policy), and accepts feedback—both positive and negative."
- from "Supporting Self-Organizing Agile Teams What’s Senior Management Got To Do With It?" by Rashina Hoda, James Noble, and Stuart Marshall,
The Customer's (or customer surrogate's) task is to set the priorities, decide when each requirement is satisfied, and write stories and acceptance/functional tests together with the team. Self-organizing teams are responsible for collaborating effectively and often with the customers to elicit and understand the product requirements. (See "Agile Undercover: When Customers Don’t Collaborate" for more on how customers can help or hurt a team's ability to self-organize.)
Roles Facilitating Self-Organizing Agile Teams
In the paper, "Organizing Self-Organizing Teams", Rashina Hoda, James Noble, and Stuart Marshall concluded that Scrum Teams adopt 6 roles to facilitate their team’s self-organization (see the table below). Although any Scrum Team member could do any of the 6 roles, it was generally the Scrum Master (agile coach) and Product Owner (business analyst) who take on the roles. If the Scrum Team doesn't have the capacity or ability to fulfill these roles or someone outside the Scrum Team is occupying one of these roles, it may indicate the team is not yet self-organizing.
Role | Definition | Played by |
Mentor | Guides and supports the team initially, helps them become confident in their use of Agile methods, and encourages continued adherence to Agile practices. | Agile Coach |
Coordinator | Acts as a representative of the self-organizing Agile team to coordinate communication and change requests from customers. | Developer, Business Analyst |
Translator | Understands and translates between the business language used by customers and the technical terminology used by the team, in an effort to improve communication between the two. | Business Analyst |
Champion | Champions the Agile cause with the senior management within their organization in order to gain support for the self-organizing Agile team. | Agile Coach |
Promoter | Promotes Agile with customers and attempts to secure their involvement and collaboration to support the efficient functioning of the self-organizing Agile team. | Agile Coach |
Terminator | Identifies team members threatening the proper functioning and productivity of the self-organizing Agile team and engages senior management support in removing such members from the team. | Agile Coach |
*Although Stephen Denning states that the self-organizing team "can decide who should be a member of the team", I would suggest looking at Mike Cohn's removing team members blog and the role of leaders on a self-organizing team blog. There may be times when the Scrum Master or management juggle the team make-up to help foster self-organizational improvements.