…a new team is coming together to work in Scrum, or an existing team is adopting Scrum. In either case, it is necessary for the team to establish how to work together.

✥       ✥       ✥ 

When it comes to policies and procedures, one size does not fit all. Different teams have different people and dynamics unique to themselves. Also, a team with a given responsibility and the expertise necessary to fulfill it knows best how to go about doing it.

By definition, a stakeholder has a vested interest in the success of a Scrum endeavor. As such, it is natural to want to have some control over the development effort. Stakeholders with product responsibility feel safer if they have the authority to direct details of the work. However, stakeholders outside the Development Team are likely not to know the details of development work, so the policies and procedures they may want may not suit the team’s needs nor contribute to the Greatest Value. And if a Scrum Team finds itself doing its work within a larger corporate structure, that structure may want to impose business goals or steer development direction out of concern for its own return on investment, even from a superficial base of knowledge about the product or its rollout. At the very least, these interventions send the subtle but unmistakable message that the corporation does not trust the team to act on its own. This sets up an “us versus them” mentality; it erodes trust (see Community of Trust).

Too often a well-meaning organization strives for economies of scope by defining “best practices” designed for the greater good. Management and administrative bodies often stipulate such practices as standards. In the spirit of the lean canon, standards can be enabling. However, one team’s Best Practice can be another team’s poison, and teams should consider adopting these of their own initiative—either individually or collectively—rather than following an external mandate.

Decisions made locally are more efficient than decisions imposed from outside a team.

Therefore:

The Scrum Team makes its decisions free from external control, and while it is an open system attentive to external considerations, the team charts its own direction according to its pursuit of value without undue external influence. Similarly, at the next level the Development Team governs itself during the Production Episode without outside intervention.

✥       ✥       ✥ 

Teams keep control over actions that lead to results for which they are accountable. While making decisions that affect their own processes, the teams are still open to interaction with other development and delivery teams, they still keep their internal work visible through Information Radiators, and they seek input on how to improve from groups such as Birds of a Feather.

Autonomy includes establishment of one’s own culture, including any Norms of Conduct as well as reward systems. It also includes how the team carries out work; see Self-Organizing Team.

This does not mean that the Development Team has the authority to simply do whatever it wants (and maybe not accomplish anything): if the organization has adopted Scrum, the Development Team follows Scrum. Effective autonomy always lies within the constraints of the organization’s values and goals–in this case, the team has a common commitment to evolve toward the Vision and to create value through the Value Stream.

An important part of autonomy is the authority to set up the team’s organization (Self-Organizing Team). While a team that is autonomous is more likely to be able to manage itself over time, these two patterns incrementally build on each other, and either may initially precede the other. An Autonomous Team can define and execute its own processes: it decides how it works. It includes the organizational pattern, Developer Controls Process, but goes beyond process to the creation of the team’s own culture.

Much of the ScrumMaster’s work, largely as a Firewall, entails maintaining the autonomy of the Development Team and occasionally of the broader Scrum Team. Organizational norms and rituals also help protect the autonomy of the team; see Snack Shrine as an example.

It is important to understand the link between autonomy and accountability: if a team is autonomous, people trust that they will do what they set out to do, and the team is accountable to those who trust them. The team has the responsibility and the authority to meet the Sprint Goal.

A possible danger in an Autonomous Team is that the team may become blind to its own weaknesses. Therefore, temper Autonomous Teams with Pop the Happy Bubble, as well as having the ScrumMaster working along with the teams to give them feedback, to convey feedback from outside the team, and to keep them open to feedback from other sources. The teams remain part of the larger open systems in which they are embedded and are subject to reviews (such as the Sprint Review and Sprint Retrospective) and external feedback.

A team that is autonomous is best able to examine and increase its own velocity (see “The Transparency Paradox” in Notes on Velocity) to optimize value creation. Extending the Value Stream metaphor, water flowing downhill can cut its own channel to find the fastest and most efficient path down the mountain.

People are generally most motivated and engaged when they have autonomy ([1]). When successful, this sets up a virtuous circle: Autonomous Teams that prove their accountability gain more autonomy, allowing them to be more successful. This is an important success factor in highly effective organizations.

Note that while this pattern as written focuses on the Development Team and on the complete Scrum Team, it extends even to pairs of Developers (see Developing in Pairs) working together. Autonomy extends all the way to the level of individual team members, who are trusted to do their best to report successes, failures, and willful process compliance (or not) on their own rather than being externally monitored. In fact, research shows that a decrease in what is usually called “transparency” helps surface and resolve impediments. Workers felt that being seen fixing a defect would invite external interference; left unobserved, workers were willing to make things right and quality improved. Respecting individual autonomy means respecting privacy (see [2]). Think twice before adopting a tool that allows management to track defects.

Autonomy should extend in the opposite direction in the long term as well, so the whole Value Stream becomes an autonomous entity. Toyota has gathered the production of virtually every conceivable automotive component under a single confederation umbrella. Supply chain management across the entire enterprise ties it together as an autonomous unit.

Scaling can be the enemy of autonomy, and it is often difficult to sustain team autonomy while growing. It may take much effort to avoid adding control structures with more teams. There is also a longstanding organizational principle that a manager’s power is a function of that manager’s scope of control, so organizations with latent management structures run the risk of management flexing its muscle in the interest of keeping development coordinated and on-track. A good ScrumMaster will intervene and may challenge the teams to better self-organize.

Jens Østergaard observes that Development Team autonomy is the “heart of Scrum.” It is central to Scrum’s effectiveness; without it, it is hard to argue that it is even possible to do Scrum. And Jeff Sutherland writes (with emphasis on “pillars of Scrum” and “dramatic”) ([3], pp. 23–4):

One of the pillars of Scrum is that once the Team makes its commitment, any additions or changes must be deferred until the next Sprint. This means that if halfway through the Sprint the Product Owner decides there is a new item he or she would like the Team to work on, he cannot make the change until the start of the next Sprint. If an external circumstance appears that significantly changes priorities, and means the Team would be wasting its time if it continued working, the Product Owner or the team can terminate the Sprint. The Team stops, and a new Sprint Planning meeting initiates a new Sprint. The disruption of doing this is usually great; this serves as a disincentive for the Product Owner or team to resort to this dramatic decision.

The structure of a product and its development process often make the difference of whether teams can develop that product together while retaining a modicum of autonomy. In multi-team Scrums, it’s important to structure the product to support partitioning the work between several loosely coupled teams. See Conway’s Law and Organization Follows Market.

Counter the potential myopia and inbreeding of an Autonomous Team with Scrum of Scrums, Birds of a Feather, Sprint Planning, Sprint Review, and the Sprint Retrospective. See also Gatekeeper.

[1] Daniel Pink. Drive: The amazing truth about what motivates us. New York: Riverhead Books, 2011.

[2] Ethan S. Bernstein. “The Transparency Paradox: A Role for Privacy in Organizational Learning and Operational Control.” In Administrative Science Quarterly 57(2), 21 June, 2012, pp 181–216. http://journals.sagepub.com/doi/abs/10.1177/0001839212453028.

[3] Jeff Sutherland. The Scrum Handbook. Somerville, MA: STI Press, July 2010, pp. 23–4.

Picture credits: U.S. Department of Defense, Joel Rogers, ID: 636681-E-PBD16-814, https://www.defense.gov/Photos/Photo-Gallery/igphoto/2001084205/ (public domain).