Bounded Autonomy: Supporting Agile Team Autonomy With Boundaries

The Need for Autonomy

“In the long history of humankind (and animal kind, too) that those who learned to collaborate and improvise most effectively have prevailed.” – Charles Darwin

The evolutionary pressure in the world has never been more volatile and uncertain. Surviving and thriving requires organisations to respond rapidly, adapt and navigate complex challenges. An Agile organisation nurtures and supports Agile teams that can rapidly and effectively engage with complex challenges.

Autonomous Agile Team

There are a number of factors contributing to the effectiveness of an Agile team. One of the core factors is the need for a high degree of Autonomy so that they can respond rapidly, operating with minimum dependencies on external decision-makers and other teams and services.

In addition to a “Process efficiency” gain, team autonomy is also a major motivational factor, increasing team member engagement.

Here is an excerpt from Self-Determination Theory:

“Conditions supporting the individual’s experience of autonomy, competence, and relatedness are argued to foster the most volitional and high quality forms of motivation and engagement for activities, including enhanced performance, persistence, and creativity.” – https://selfdeterminationtheory.org/theory/

In summary, Agile teams are highly effective when they are empowered and can function with significant autonomy and clarity of purpose.

Bounding Autonomy Without Breaking It

A question that many leaders ask: “How do we direct Agile teams without telling them what to do and destroying their autonomy and empowerment?”

The answer is to ensure that there are explicitly agreed boundaries around the teams that make clear what they can, and what they can not, decide and act on independently. Team autonomy should be “Bounded”.

Careful design and co-creation of team boundaries enable:

  • Explicitly agreed boundaries – teams won’t have to guess what decision authority they have.
  • Focus – the team have clarity of purpose and priorities guided by their Product Owner.
  • Constraints – the team understand the technology, design and compliance standards within which they need to work.
  • Emergence – boundaries should evolve when teams find that they limit value creation.

Agile Team Control Surfaces

The diagram below illustrates an array of “Control Surfaces” that serve as mechanisms to bound interactions with the team and actions by the team:

Team Focus

To influence what the team works on, stakeholders collaborate with the Product Owner, offering their perspectives on backlog candidates and priorities. Stakeholder input will assist the Product Owner in forming the Product Goal and influence the Sprint Goals selected by the team, providing the alignment “Focus” around the mission. In the words of Stephen Bungay, “The more alignment you have around direction, the more autonomy you can get around actions” – The Art of Action by Stephen Bungay. No one outside the team should override the direction guided by their Product Owner or directly task team members.

Team Constraints

The team need to be free to decide how to meet the outcome described by Product Backlog items and their Acceptance Criteria. However, constraints can be applied via the Definition of Done (DoD) and other agreements that cover standards and compliance aspects. These agreements should be collaboratively formed with the team and other relevant stakeholders and should be viewed as living, evolving artefacts that the team can challenge.

Boundary Permeability

The “Semi-permeable” boundary around the team indicates the protection the team should have from disruption and interference in their mission to achieve the agreed goals. It should, however, not exclude the team from interacting directly with sources of information external to the team.

Role of Leadership

Leadership are considered as “Stakeholders” when it comes to influencing what the team focus on. They also have an essential role in supporting the evolution of the environment around the team to ensure that the team can maximise their value creation for customers and stakeholders. Where the team are hindered by issues such as unnecessary or overly heavy bureaucracy, leadership should work to understand and evolve the organisational systems and structures.

Preconditions

The boundary delineates who is in the team and assumes that the membership is largely stable and committed to accomplishing the shared team mission – what Richard Hackman refers to as a “Real Team” – Leading Teams by J. Richard Hackman.

Teams must be cross-functional – they have all the skills required to autonomously turn backlog items from ideas to outcomes. In other words, the team is not dependent on external capability to deliver items from their backlog.

A further precondition is that backlog items themselves are autonomously valuable and articulated in business domain outcome form and not as technical or component level work.

Protecting Autonomy at Scale

Scale Challenges to Autonomy

In scaled situations, where there can be multiple teams contributing to a large and complex outcome, there is often a loss of team autonomy. There are a number of potential causes, including:

  • Top-down imposition of bureaucracy and additional process controls.
  • Additional team coordination functions external to the teams.
  • Lack of clarity about what is within a given team’s decision-making authority.
  • Poor Value Stream/Product and Team design creating interdependent and overlapping work.
  • Over-specialisation of skills leading to teams that are not fully cross-functional.
  • Design decisions imposed by functions external to the teams reducing team empowerment and increasing dependency on external agents. E.g. Architectural, User Experience, Security, Infrastructure, etc…

Team Structure

Ideally, the design of the team of teams structure should be optimised to provide an environment that will support greater team autonomy. Look to incrementally improve the following factors to foster the conditions for greater potential team autonomy:

  1. Design the Product and team structures so that they align closely with the business and customer Value Stream.
  2. Optimise the team structures and skills mixture to minimise interdependencies with other teams whilst staying true to number 1.
  3. Avoid external subject matter experts injecting design decisions into teams. This requires that the team membership includes the relevant competencies and has the authority to emerge design from within the team.

Applying Boundaries

Building on the evolving improvements to the structural team model, work with the teams and relevant stakeholders to create boundaries to support autonomous team behaviour at scale:

  1. Create explicitly agreed boundaries around each team so that they understand what they can decide and execute autonomously, versus what they need to escalate and discuss externally. Boundaries should be set and evolved collaboratively with the teams rather than imposed on them.
  2. Use shared “Enabling Constraints” to encourage teams to collaborate enough that their autonomous design and output integrate to support the outcomes of the Value Stream. A combined integrated Sprint Review on a shared environment at the end of each Sprint is a great example.
  3. Ensure that the teams work within a shared context of the end-to-end Value Stream so that they understand the bigger picture of the overall mission.
  4. Continuously evolve all of the above!

Shared Boundaries

Consider a number of teams contributing to the same Value Stream. Each team will need a clear set of boundaries within which they can be autonomous. These team boundaries may also need to share some common elements to support consistency for decisions that have a Value Stream-wide impact. For example, there may need to be common interface or user experience standards so that the combined work has cohesion and user interaction consistency.

Within a Value Stream

The diagram below illustrates this relationship where the effective team boundaries include common Value Stream level boundary elements. Each team should also be able to exert influence on the Value Stream boundaries, for example, identifying new elements or those that need to be updated and removing excess restrictions and bureaucracy.

All Value Stream teams sharing a common set of core Definition of Done elements is a good example of a shared boundary that will support inter-team collaboration and consistent quality of the integrated whole.

Across an Organisation

The DoD is also an example of where an explicit boundary, may be, and usually is, influenced by organisation-wide quality standards.

The model can be thought of as a “Russian Doll”, with the effective boundary from a team’s perspective being an amalgam of the organisational + Value Stream + team-specific boundaries. As per the diagram below:

Summary

  • How teams are designed is a key determining factor in enabling their autonomy.
  • Team design should be based on a Product structure that is aligned with Value Streams.
  • Team design should be optimised to reduce interdependencies between teams, external experts and external services.
  • The right boundary constraints, explicitly articulated, and collaboratively set and evolved, will establish the conditions for autonomous and empowered teams.
  • Scaled teams should collaborate and agree on the boundary constraints that will be necessary to support clear autonomy at a team level and understand why some constraints need to be set and evolved at a Value Stream level.
  • Value stream and team boundaries have to consider what constraints need to be included from the wider organisation. 
  • Although boundary constraints define the limit of team and Value Stream autonomy, they are open to challenge whenever they appear to impede value flow.
  • Leaders play a crucial role in supporting the continuous evolution of organisational environments to optimise and sustain value creation.