¶17 Self-Organizing Team
Confidence stars: **
Birds organize themselves into formation and continually reorganize their formation.
...an organization has established a community of trust (see ¶95 Community of Trust) and tills the ¶3 Fertile Soil. The ¶14 Development Team is running as an ¶16 Autonomous Team.
There is no one way to structure a team or work that is correct for all situations and all work, and thus unchanging over time.
For any multi-person work, you must organize tasks and people to work together in a coherent, coordinated manner. Otherwise, you risk falling into chaos. But this organization can be complex.
To reduce complexity, organizations will standardize structures and processes. This may be through adoption of a best practice or through historical development of the organization’s culture. Best practices develop in a specific context to achieve specific objectives, and these may not suit a given organization (Managing the Design Factory: A Product Developer’s Toolkit [Rei98], p. 184). In any complex endeavor, you can rarely forecast ahead of time which of several shared foundations will be the optimal one: you need only something that is “good enough,” and let emergence guide you from there. An organization may develop its own best practice structures and processes at certain times, as situations demand; they become established practices. However, though these approaches usually work for a while, they will not continue to be the best practices as time goes on. The business situation changes as management approaches advance and technology improves. The team may become stuck at a new plateau.
People can be comfortable when someone else leads and tells them what to do. This direction and control has some consequences. Motivation and workplace factors such as turnover rate and job satisfaction can suffer when people are working for controlling managers (see “The impact of work design, autonomy support, and strategy on employee outcomes: A differentiated perspective on self-determination at work” in Motivation and Emotion 39 [Gün15]). Moreover, the people doing the work are the ones who understand how to do their jobs the best. When workers don’t have control of their work, valuable opportunities for efficiency, effectiveness, and for quality results are missed. For example, a factory worker may take the initiative to improve the efficiency or safety of a task. This improvement might never come were we to expect it from a manager who is too out of touch with the situation to appreciate the need for a solution, let alone conceive of a solution.
Development Team members often have specialized skills; it is beneficial to take advantage of their differences to work efficiently. But if everyone works only within his or her own expertise, tasks may get delayed instead of being spread more evenly.
Therefore:
The Development Team organizes itself to get its work Done (see ¶82 Definition of Done). The Development Team is solely responsible for how it does its work.
The Development Team controls all aspects of its day-to-day work. For example, they run the ¶29 Daily Scrum meetings, and decide who works on what. They decide the order of work, and decide how to organize ¶25 Swarming: One-Piece Continuous Flow. The team decides how to take advantage of the Development Team members’ special skills and areas of expertise. It may include deciding who pairs with whom, and so forth.
Note that self-organization requires maturity and discipline. Some people are uncomfortable with self-organization. Stakeholders such as the ¶11 Product Owner may be tempted to jump in to help, or the ¶19 ScrumMaster might think they know who should work on what (at no time does the ScrumMaster assign people to work on tasks or tell Developers how to work). But people outside of the Development Team need to let the team learn through self-organization, even if it is initially difficult. A ¶22 Scrum (Master) Coach can help.
One danger in removing an explicit supervisory role is that another individual (on the team) may fill that same role, forcing his or her will on the team through charisma, bullying, or dominating the conversation. This leaves the team with exactly the same dynamics as it had previously. The ScrumMaster needs to understand this may happen and prepare the team by modeling behaviors that ensure everyone on the Development Team can contribute. This will help establish norms for the team. If this type of behavior does appear (or anything else that inhibits self-organization) it is the responsibility of the ScrumMaster to help the team identify and resolve the impediment.
Naturally, self-organization is easiest with ¶9 Small Teams and ¶8 Collocated Teams, because the logistics are easier in both cases.
This pattern is one of the practices at the heart of Scrum. It allows the work in a ¶46 Sprint to move forward in the most efficient manner. It improves the morale of the Development Team (and there is evidence of improved performance; see Small Group Research 48 [JTAL16]). It allows the Development Team to examine itself and improve (see ¶36 Sprint Retrospective, ¶92 Scrumming the Scrum, and ¶91 Happiness Metric, for example.) With it, the Development Team becomes self-healing—it can see its faults and has the power to fix them. This is one of the most important patterns for a Scrum organization to master.
When the business allows Development Teams to self-organize, the teams gain both freedom and commensurate responsibility: it is the gate to a Community of Trust. A team that has its own say over how it builds the product is likely to become more proud both of itself and of the product; see Team Pride (patlet for ¶118 Team Pride) and ¶38 Product Pride, respectively.
See also ¶76 Developer-Ordered Work Plan, Swarming, and ¶100 Informal Labor Plan.