Achieving Team Autonomy not Anarchy

Agile teams sometimes struggle with the meaning and value of autonomy within a team. Is it the autonomy to decide how best to accomplish a goal? Is it the autonomy to choose what tools and processes they will employ to accomplish that goal? Is it both? To answer this, we need to first determine where autonomy drives value creation and where it destroys value within an enterprise.

Getting Team Autonomy over Anarchy

Consider the following analogy: We have the autonomy to determine what roads and paths we will take to a destination when driving a vehicle, but we are governed by speed limits, right of way (which side to drive on, stop signs, stop signals and other road signs), emission standards, and both vehicle and personal licensing. Put another way, we are completely empowered to determine WHAT path we take, and WHY we take it. We are much more limited in HOW we get to a place (on road, off road, speed, only licensed vehicles, etc) and WHO can do it (only sober, licensed drivers). How does this apply to a fully autonomous technology team?

The value-creation of autonomy within a team deals with what path a team takes to accomplish a goal and the reasoning as to why that approach is valuable. A failure to provide structure and rules for how something is accomplished through architectural principles, coding standards, development standards, etc. can start to escalate the costs of development and destroy value. Also, not sharing best practices through standards, means that teams are bound to repeat mistakes and cause customer interruptions. While there is a narrow line between autonomy and anarchy, the difference on their effect in an organization is significant.

Consider the matrix below which distinguishes between decision making (What path gets taken to a result and Why that path is taken) and governance (the rules around How and Who should do something). In an Autocratic organization there is a high amount of Governance controlled via a Top-Down method of Management. Agile teams here are bounded by how they can accomplish a goal and crippled by what path to take because of the heavy involvement of Management. Here is where you find organizations that are described derogatorily as Bureaucratic.

On the opposite side of the spectrum, if an Agile shop finds itself unbounded by Governance and capable of making all decisions then you run into the possibility of anarchy. This type of environment is what allows start-ups to thrive in their early days, but once you have moved beyond a handful of employees, it is necessary to start building governance.

Where companies with Agile succeed is when Governance is in place and decisions are driven from the bottom. Ownership and appropriately known boundaries allow Agile teams to deftly maneuver and get after the concept of "Build Small, Fail Fast". Lastly, it is important that the lessons learned from all of the Autonomous teams are continually brought up and shared across the multitude of products and teams you have. It is a waste of time to reinvent the wheel when another team has already solved the problem.

Empowering Teams

Teams should be built around the suggestions from AKF's white paper on Organizing Product Teams for Innovation: small, cross functional teams built around a service, who are empowered to be autonomous and work independently on their own. Autonomy should be defined within the rules of the organization, inform the organization's architectural principles, and drive adherence through leadership. This is by no means a notion that the organization should avoid cross functional empowered teams! As we state in our white paper, "We still have executives developing strategy, functional teams (product management, etc.) defining subservient strategies and road maps. But the primary identities of these folks are embedded within the teams that implement these solutions."

It is also easy to confuse the notion of empowerment and autonomy. Empowerment is an action of delegation coupled with the assurance of resources and tools to complete the desired outcomes to the delegated party. It is only through empowerment that autonomy can be achieved within an organizational hierarchy. Further, it is only through empowerment that autonomous agile teams can be established. But both empowerment and autonomy need to have rules governing their action or issuance. Specifically, an agile team is empowered to be autonomous with the following constraints: following development protocols and standards, adhering to architectural principals, adhering to established best practices regarding test coverage, etc. and ensuring that you achieve the "non-functional requirements" codified within the Agile Definition of Done.