The Teams' Perspective

Introduction

“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 addresses these challenges by nurturing and supporting Agile teams with a high degree of autonomy, that can respond rapidly, operating with minimum dependencies on external decision-makers and other teams and services.

This section revisits the essential elements of successful Agile teams and then explores how we can scale this model to a larger product development organisation whilst retaining the advantages. The key related Scaling Principles are called out in the relevant places.

Sections in this Perspective:

• Agile Teams
  1. Defining “Highly Effective”
  2. Why Agile Teams Are Effective
  3. Elements of a Highly Effective Agile Team
• Options for Scaling Agile Teams
  1. Assumptions on the Need for Scale
  2. Optimise a Single Team
  3. Grow the Single Team
  4. Component Teams
  5. Feature Teams
• Effective Autonomy with Boundaries
• Maximise Team Learning

Agile Teams

Defining "Highly Effective"

How do we recognise that a team is highly effective, what are the visible signs and capabilities?

Here are some examples of what we might be looking for:

• Consistently realise high-value, high-quality outcomes with short lead-time and low waste
• Creative and innovative solutions to diverse, complex problems
• Learn fast and are continually improving
• Adaptable and Resilient
• Collaborative, supportive and inclusive culture

Why Agile Teams Are Effective

Agile teams are effective because they are small units of people committed and focused on getting the “job done”, autonomously delivering end-to-end products to customers.

In this context, “end-to-end” means having control over everything related to the execution of product development, from the analysis and design activities through all the technological development and testing to ensure the released product is successful.

With a high degree of autonomy, they can respond rapidly, operating with minimum dependencies on external decision-makers and other teams and services. Waste, caused by hand-offs, dependencies and coordination, is dramatically reduced as it is internalised within the boundary of the team’s collaboration.

According to Richard Hackman, the “recipe” to create great teams is the following:

1. A real team
2. Compelling direction
3. Enabling team structure
4. Supportive organisational context
5. Expert team coaching

Most Agile approaches implement this model, though in slightly different ways. For example, Scrum has a Product Owner providing compelling direction and a Scrum Master providing coaching and working to achieve a supportive organisational context:

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

Related Principles:

• Self-managed teams
• Maximise team empowerment and localised decision making
• Maximise Team autonomy
• Favour Teams with broader Solution Accountability
• Favour Teams with broader Business Domain Competence

Relevant References:

Hackman, J. R. (2002). Leading teams: Setting the stage for great performances. Harvard Business School Press.

Elements of a Highly Effective Agile Team

In this section, we dig a little deeper into the elements that go into an effective Agile team. The diagram below illustrates some of the elements incorporated within a Scrum manifestation of the Agile principles.

We explore these elements required for a highly effective Agile team:

• Small Team Size
• Autonomous and Empowered
• Clarity of Purpose
• Team Membership
• Cross-functional
• Supportive Organisational Context
• Team Coaching
• Psychological Safety

Small Team Size

Research on Team size consistently finds that for complex knowledge work with high interdependency of tasks, smaller teams, 10 or less, are more effective than larger teams.

Scrum, for example, in the 2020 Scrum Guide says,” The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive.”

Larger teams experience dramatically increased communication complexity, increased effort and time to deliver a given outcome and lower motivation and morale.

Relevant Principles:

• Scale only when you need to
• Start small and scale success
• Organise around value streams
• Minimise unnecessary complexity

• Limit Team Mental Workload

Relevant references:

• The Ringelmann Effect
• Team Size and Quality of Group Experience
• Brooks's Law
• Metcalfe’s Law
• Google re:Work
• Katzenbach, J. R., & Smith, D. K. (2015). The wisdom of teams: Creating the high-performance organization. Harvard Business Review Press
• Familiar Metric Management - Small is Beautiful-Once Again, Lawrence H. Putnam and Ware Myers

Autonomous and Empowered

An Agile team should be able to operate with a high degree of autonomy, taking a requirement or idea from concept to realisation with a minimum of outside dependencies. In addition, they will be empowered to decide how to solve the problem without the need to seek permission from outside authorities.

The team need to be free to decide how to meet the outcome described by clear goals and Product Backlog items and their Acceptance Criteria (or equivalent) - see Clarity of Purpose. However, there should be clearly understood boundaries to the team’s autonomy and empowerment. These boundary 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.

In addition to the efficiency gains due to the speed of decision-making and reduced waste caused by delays waiting for dependencies to be resolved, teams experience increased motivation and accountability for their work.

The quality of decisions also improves due to the proximity of the decisions to the work and information, along with the skills of the people deciding.  

Relevant Principles:

• Support autonomy with clear boundaries
• Leadership supports rather than drives the work
• Product solution design is driven from within development teams
• Maximise engagement
• Maximise Team autonomy
• Create clarity of purpose
• Leadership supports rather than drives the work
• Create the environment for people to thrive
• Foster a high trust environment
• Self-managed teams
• Self-managed Team of Teams

Relevant References:

A relevant 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.”

Clarity of Purpose

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 Bungay, S. (2021).

A clear, compelling and common purpose guides and enables the team to shape their autonomous and empowered work. The fact that the team share a purpose is an important element to support and motivate a collaborative team dynamic rather than just a group of individual efforts.

Creating and maintaining the purpose of a team is an important contact point between the team and outside stakeholders. This process needs to work in such a way that it provides clear alignment and rich contextual information, whilst simultaneously protecting the autonomy and empowerment of the team. In Scrum, the Product Owner is responsible for engaging stakeholders to input into goals and requirements and feedback on team outputs, whilst retaining decision-making authority within the team.

The “Semi-permeable” boundary around a 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.

Relevant Principles:

• Create clarity of purpose

• Shared context improves decisions

• Organise around value streams

• Maximise engagement

• Maximise Team autonomy
• Maximise team empowerment and localised decision making
• Favour Teams with broader Business Domain Competence
• Self-managed teams
• Self-managed Team of Teams

Team Membership

Largely stable membership enables team formation to take place, evolving from a group of individuals to a collaborating, mutually supportive team unit. A revolving set of players creates an uncertain and unstable environment for relationships and trust to build and is unlikely to lead to a strong team identity.

Team members should complement each other. Covering each other's weaknesses and providing a constructive diversity of perspectives and experiences. In addition, the team should be resilient and retain the ability to deliver outcomes even when missing individual team members through vacations and illness.

Relevant References:

“Teams with stable membership perform better than those that constantly have to deal with the arrival of new members and the departure of old ones.” - Leading Teams by J. Richard Hackman.

Relevant Principles:

• Favour teams with maximised cognitive diversity
• Create the environment for people to thrive
• Foster a high trust environment
• Maximise engagement

• Maximise Team autonomy

Cross-functional

Teams are cross-functional – they have all the business and delivery domain 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. In this context, “outcomes” refers to realised value to the organisation and/or customers.

Relevant Principles:

• Favour teams with maximised cognitive diversity
• Favour Teams with broader Solution Accountability
• Limit Team Mental Workload
• Maximise Team autonomy
• Cultivate learning between teams
• Product solution design is driven from within development teams
• Create a Learning Organisation

Supportive Organisational Context

Leaders are considered to be “Stakeholders” when it comes to influencing what the team focus on. They don’t directly tell the team what to work on or how to accomplish their work. However, they 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.

Relevant Principles:

• Leadership supports rather than drives the work
• Create clarity of purpose
• Limit Team Mental Workload
• Create the environment for people to thrive
• Foster a high trust environment
• Maximise engagement
• Maximise Team autonomy
• Create a Learning Organisation
• Cultivate learning between teams
• Involve those affected by change
• Provide an impediment removal service

Team Coaching

Assembling all the correct ingredients is a good start, but on its own is unlikely to result in a successful team. A coach (e.g. a Scrum Master) helps the individual players learn how to work together as a collaborating team, accelerating the learning from group experience to continuously improve their collective processes, capabilities and interactions.

Relevant Principles:

• Leadership supports rather than drives the work
• Create the environment for people to thrive
• Foster a high trust environment
• Maximise Team autonomy
• Cultivate learning between teams
• Create a Learning Organisation

Psychological Safety

Amy Edmondson defines Psychological Safety as ”a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…”

A simple definition of a fundamental element that is required for a team to learn from its mistakes, innovate products, services and processes, take accountability, and collaborate and support each other.

Leadership within and external to the team has a major role in creating and maintaining the environment to promote high levels of psychological safety and realise the resultant performance improvements.

Relevant Principles:

• Create the environment for people to thrive
• Foster a high trust environment
• Maximise engagement
• Maximise Team autonomy
• Cultivate learning between teams
• Involve those affected by change
• Create a Learning Organisation
• Leadership supports rather than drives the work

Relevant References:

• Project Aristotle: On team performance factors -“Psychological safety was by far the most important of the five key dynamics we found. It's the underpinning of the other four (Dependability, Structure & Clarity, Meaning and Impact)."
• Edmondson, A. C. (2019). The fearless organization: Creating psychological safety in the workplace for learning, innovation, and growth. John Wiley & Sons, Inc.

Options for Scaling Agile Teams

Assumptions on the Need for Scale

Many companies operate under the assumption that one team will be insufficient in larger product development challenges. This thinking is often rooted in assembly line thinking, where higher output means higher value and, to double production, there is a need to double the assembly line and the people working in it. Product development does not function based on that logic:

• The difference between the best and worst performers in a knowledge-based organisation is way larger than in manufacturing
• In developing high-tech products, the results are more dependent on the generated outcome than on the output. Those outputs that do not generate value are waste!

So, assuming that scale is required is often incorrect. One small team working in the right organisational ecosystem can, in many cases, deliver exceptional results. This should be the default assumption, as scaling a development organisation using more teams will inevitably add complexity and overhead.

Related Principles:

• Scale only when you need to
• Start small and scale success
• Minimise unnecessary complexity

Optimise a Single Team

Before moving to a multi-team scaled model, first, implement options to improve the delivery capabilities of the single team. This strategy will result in increased value delivery by the team and additionally provide valuable empirical data on which to base the decision on the need to scale beyond a single team.

However, in many cases, it is necessary to have several teams collaborate on the same product development. For example, the complexity and diversity of the technical or business domains may exceed the cognitive capabilities of a single small team.

Related Principles: Limit Team Mental Workload

Grow the Single Team

One possible option is to enlarge the Team by adding more and more people. We know from the research on Teams that this approach will only be viable for up to approximately 10 people. Most research puts the optimum team size as less than 10, so there will be a balance point at which the overhead of multiple smaller teams will be less than the suboptimal performance likely for a large team. Scrum, for example, says only up to 9 people in the Development Team (Scrum Guides until 2017) or, in the current version, up to 10 people, including Scrum Master and Product Owner (Scrum Guide 2020).

There are two competing forces impacting the Team's size:

• Smaller Teams performing better: Functioning team dynamics, collaboration, knowledge transfer, and alignment are more straightforward with fewer people being involved.
• In order to have all the necessary skills in a Team, there might be the need to have more people in it. This issue becomes more critical the greater the number and diversity of technologies involved.

Eventually, in large product development, this is not a viable option as we reach a maximum effective size for a single team and have to explore options to increase then umber of teams.

Related Principles:

• Maximise team empowerment and localised decision making
• Favour teams with maximised cognitive diversity
• Limit Team Mental Workload

Divide the development into separate parts - "Component teams"

The second option would be to have several Teams divide the solution accountability, i.e. each Team takes part in the product development with the aim of working as much as possible in isolation from the other Teams, a configuration usually known as Component Teams. The usual boundaries used for the split are knowledge, hierarchy, politics, sites, ... Rarely, though, is this split planned according to sound organisational design principles and is more often the result of years of action of many competing forces.

This strategy might sometimes result in what appears to be a higher local development speed, though often a lot of the work done by the Teams is actually coordination with other parts of the organisation rather than actual output creation. In any case, the drawbacks are enormous:

• Knowledge silos, with teams not understanding how to create a complete solution
• Lack of focus on a complete solution: Each team considers the work as done when they have implemented their part according to whatever definition they agreed on
• Lack of accountability, often resulting in finger-pointing and partisan thinking: what we did works; it's somebody else's fault if the complete solution does not work!
• Increased department thinking and internal politics games
• Increase of local solutions, further complicating the technological landscape and the opportunities for product-wide learning
• Very few people in the organisation have sufficient knowledge to talk to and understand the actual customers and end users, resulting in a system of Chinese Whispers and the relative distortion of information that this causes along the way

A particular form of this accountability split is when one Team is established to define the work for other Teams. This creates a thinker-worker split that is typical of the Tayloristic view of a company but is highly problematic in knowledge-creating ones. Typical examples of this are Analysts vs. Developers, Architects vs. Developers, Developers vs. Testers, ... The structure is just as problematic as having Component Teams, with the addition of creating some Teams that have a perceived higher authority, thus exacerbating morale problems.

End-to-end "Feature Teams"

The other option is to create Teams capable of developing end-to-end products, also known as Feature Teams. Each Team can develop separately from the others without the (or, usually, with limited) need to coordinate with other Teams.

There are, however, two challenges:

• Each Team needs to have a much broader knowledge about the solution domain and about the business domain, i.e. learning becomes a central aspect of how the organisation works. This is fully aligned with what many regards as the way a modern knowledge-based organisation should work (Maximise team empowerment and localised decision making). Nonetheless, it requires an investment in learning that many organisations don't consider or see as needed.
• While knowledgeable Teams can develop end-to-end parts of a solution independently, they still need to integrate their contributions. This problem also exists for Component Teams, but in the case of Feature Teams, the probability of colliding changes is higher because they are more likely to apply changes in the same places as other teams. How problematic this is in practice depends on how the development is organised. In software, for example, there are several practices and technologies that help to reduce this issue a lot: continuous integration/continuous delivery, modern development tools, collective code ownership, ..., so that for properly organised software development, this point is de facto irrelevant (though the investment many companies have to do to reach that point is huge!) In other disciplines, your mileage might vary. The section on Craft describes several options.

We suggest this option is the preferred one, though sometimes, in very large product development, Component Teams may have to be considered as part of the team model design. If you are including Component Teams, we suggest to keep looking for ways to implement more and more Feature Teams and optimise towards the relevant ELSE principles.

Related Principles:

• Organise around value streams
• Shared context improves decisions
• Minimise unnecessary complexity

• Maximise Team autonomy
• Favour Teams with broader Solution Accountability
• Favour Teams with broader Business Domain Competence

• Maximise team empowerment and localised decision making

• Use the Definition of Done as an enabling constraint
• Regular small changes: Scale the number of changes rather than the size
• Amplify Speed and Quality of Learning Cycles
• Collective responsibility for complete product development
• Support autonomy with clear boundaries
• Product solution design is driven from within development teams
• Invest in quality

Effective Autonomy with Boundaries

How do we direct Agile teams without telling them what to do and destroying their autonomy and empowerment? This challenge is often not well addressed even for a single Agile product team, but scaling scenarios often experience dramatically undermined autonomy and empowerment.

The answer is to ensure that there are carefully cultivated and 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 – teams have meaningful 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 end-to-end value creation (be wary of and avoid the local optimisation trap!).

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

It is easy to lose the idea of “Meaningful clarity of purpose” when decomposing a large product across multiple teams. Often they are reduced to working on arbitrary elements of technology layers or product components, with little idea of the customer context and how their work contributes to end-to-end value. A common telltale sign of this scenario is “technical” backlog items that have no direct business or customer value.

Careful attention is required to ensure that the team structure is designed to match end-to-end aspects of the value stream to retain clarity of meaningful purpose and clear sight of the value of their work. Evidence that this is working will be that the teams can autonomously deliver backlog items that are articulated in business and customer outcomes with clear value.

Consideration should also be given to the dual nature of a team’s mission when working as part of a team of teams. There will be a balance between team-specific goals and the wider collective mission of the product group. Shared goals across teams can encourage inter-team collaboration, however the stronger the need for collaboration, the less autonomous the teams are likely to be.

Team Constraints

Teams 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 cross-team integration, 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.

Supporting environments and tooling will also be required to ensure that the aspirations expressed in the constraints can be met in an effective and practical manner.

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.

In a team of teams setting, this may well include other teams. These interactions can be supported by practices such as joint Sprint Planning, cross-team pairing, group design workshops, shared Sprint Goals and joint Sprint Reviews.

Role of Leadership

Leadership are considered as “Stakeholders” when it comes to influencing what teams focus on. They also have an essential role in supporting the evolution of the environment around the teams to ensure that they can maximise their collective 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. Other impediments to value creation can come from policies and systems that promote unhelpful behaviours, for example, performance reviews and objective setting that encourage individualistic or tribal actions.

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. Sharing specialist team members across multiple teams is a common anti-pattern that erodes this concept of a Real Team.

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

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 leads to interdependent and overlapping work
• Over-specialisation of skills leads to teams that are not fully cross-functional
• Design decisions imposed by functions external to the teams. E.g. Architectural, User Experience, Security, etc…

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.
   • Organise around value streams
   • Favour Teams with broader Business Domain Competence
2. Optimise the team structures and skills mixture to minimise interdependencies with other teams whilst staying true to number 1.
   • Maximise team empowerment and localised decision making
   • Maximise Team autonomy
   • Favour teams with maximised cognitive diversity
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.
   • Product solution design is driven from within development teams
   • Technical leaders as coaches, mentors and community leaders

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!

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.

Related Principle: Support autonomy with clear boundaries

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.

Related Principle: Use the Definition of Done as an enabling constraint

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:

Maximise Team Learning

In order to have Teams that can develop end-to-end Products, the organisation needs to create an environment where learning is possible, i.e. a Learning Organisation. The concept was coined and popularised by Peter Senge. While it's relevant for every knowledge-based organisation, it is even more important in large-scale product development due to the increased cognitive load with larger product scope.

Creating a learning organisation is everybody's responsibility, but leadership has a more important systemic role of enabling learning to happen.

For more details, there are several principles related to this:

• Create the environment for people to thrive
• Foster a high trust environment
• Cultivate learning between teams
• Create a Learning Organisation

Team Perspective Summary

• Start small and retain the power of small autonomous Agile teams until reaching the threshold where scaling is no longer optional.
• 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.
• Teams should have a clear sight of the value they deliver in terms of business outcomes, and end-to-end value stream is ideal.
• 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.
• Maximise learning within and between teams - the value of your teams is in their knowledge and capabilities!
• Continuously evolve your team structures and models of collaboration using the ELSE Principles as a guide.