✥ ✥ ✥
There is no one way to structure a team or work that is correct for all situations and all work, and therefore 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 (, 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, for the situations at those times. 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 and technology both advance. 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 intention and job satisfaction can suffer when people are working for controlling managers (see ). Moreover, the people doing the work are the ones who understand how to do their jobs the best, and when someone else controls their work, they miss valuable opportunities for efficiency, effectiveness, and for quality results. 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, and it is beneficial to take advantage of their differences to work efficiently. But if everyone only works only within their own expertise, they may delay work that they would otherwise complete if they were to spread the work more evenly.
The Development Team controls all aspects of its day-to-day work. For example, they run the Daily Scrum meetings, and decide who works on what. They decide the order of work, and decide how to organize Swarming. 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 Product Owner may be tempted to jump in to help, or the ScrumMaster might think they know the 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 Scrum Coach can help.
One danger in removing an explicit supervisory role is that another individual (on the team) may fill that same role, forcing their 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 that 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 to identify and resolve the impediment.
This pattern is one of the practices at the heart of Scrum. It allows the work in a 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 ). It allows the Development Team to examine itself and improve (see Sprint Retrospective, Scrumming the Scrum, and 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, they gain both freedom and commensurate responsibility: it is the gate to a Community of Trust. A team that has their own say over how they build their product is likely to become more proud both of themselves and of their product; see Team Pride (patlet for Team Pride) and Product Pride, respectively.
 Don Reinertsen. Managing the Design Factory: a product developer’s toolkit. New York: The Free Press, 1997, p. 184.
 Stefan T. Güntert. “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, 2015, pp. 74—87.
 Marie-Ève Jobidon, Isabelle Turcotte, Caroline Aubé, Alexandre Labrecque, Shelley Kelsey, and Sébastien Tremblay. “Role Variability in Self-Organizing Teams Working in Crisis Management.” In Small Group Research 48(1), 2016, pp. 62-92.
Picture credits: Shutterstock.com