Agile teams often seem to be confused with the meaning and value of autonomy within a team. Is it the autonomy to decide review what path to take 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 unlock the riddle of where autonomy drives value creation and where and how it destroys value within an enterprise.
Balancing Team Autonomy and Anarchy
As an aid to this discussion, 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-creating autonomy within a team deals with WHAT paths 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 cause repeating failures maintenance. 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 in their effect on an organization is significant.
Consider the matrix below which differentiates the notion of decision making (What path gets taken to a result and Why that path is taken) from governance (the rules around How and Who should do something). Autocracy (complete top down decisions and governance) occupies the upper left and the spectrum moves toward Anarchy in the bottom right (bottom-up decisions with little to no alignment to organizational goals and vision, and a complete lack of governance and best practice adherence). Autonomy (as in an autonomous agile teams) exists in the upper right quadrant of the AKF’s Team Autonomy 2x2 with a high level of innovation because teams share best practices through governance but are free to experiment with paths to achieve desired outcomes. Freedom in deciding what path to take to a destination or desired outcome is valuable, however it should be balanced with the governance to validate that past lessons learned (be they security related, operationally related, or simply development related) are properly applied.
Similarly, we can plot the decision making authority for “WHO and HOW” something gets done as compared to the “WHAT (paths) and WHY (a path is taken)”. In so doing, autonomous agile teams exist in the realm where leadership enforces standards, but the team is the deciding authority for what path to take. Anarchy (bad) exists when the team makes all decisions as learnings codified within shared standards are not applied. Warring tribes emerge when leadership defines a path but leaves the decision of who and how to the teams (similar to the “bad leadership” example in the prior matrix). Autocracy exists when the leadership is responsible for all decisions. The reason we identify this as “medium” innovation is that we assume the leadership is at least experientially diverse. But innovation is low relative to autonomous teams because we aren’t tapping the innovation capabilities of the teams themselves - the intellectual capital in which we’ve so heavily invested.
How to Find the Balance of Freedom and Governance
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, Organizing Product Teams for Innovation, “We still have executives developing strategy, functional teams (product management, etc.) defining subservient strategies and roadmaps. But the primary identities of these folks are embedded within the teams that implement these solutions.”
It is 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 (more on this later).
Like this article? Share it with friends and subscribe to the newsletter here.
Have your autonomous technology teams been free to make decisions that do not align with the vision of the company? Are you fearful of switching to Agile because of the rampant anarchy they will exhibit? AKF Partners has over 200 combined years of experience helping companies ensure that their organizations and architectures are aligned to the outcomes they desire. We’d love to help you achieve the success you desire.