A de-scaling roadmap for Agile teams

Steps to take as your team evolves towards One Team wholeness.
February 22, 2022
Last updated February 22, 2022

Graphic that says Descaling

A lot has been written about scaling agile from the perspective of when organizations first encounter the choice to scale. In my last article, The Five Orders of scaling agile teams, I presented a decision-making approach for scaling (and importantly, when not to). But what about organizations that have already scaled up that are trying to figure out a path to de-scaling and greater agility?

I would like to suggest a roadmap—partial and incomplete—for the decisions and investments that leaders will need to make on what will be a difficult and many-staged journey. Where they start, stop, or whether they find an express route depends on the context of their organization, and how agile they need to be.

Note: The ideas presented in this article are heavily weighed in Scrum. There are other lenses.

Moving from dependent specialist to interdependent teams

Graphic with imagery moving from 1 to many

Leaders start here if they need to evolve from a top-down management of work across dependent specialist teams.

Characteristics of dependent specialist teams

In this context, people are seen as fungible resources, and organized into dependent teams of specialist disciplines. Work is assigned to these teams by external control (that is, portfolio, program or project management), and requirements are also owned externally from the teams. Work is driven almost exclusively by deadlines and keeping everyone 100% utilized is top of mind. System bottlenecks occur as specialist teams own specific stages of the workflow, and these teams complete work at different rates than planned.

Steps to move towards being interdependent teams

Many large organizations are like this today. What takes them towards their first stages of agility? It starts with leaders who will:

  • Build a system thinking competency to see a value stream as a whole, and to focus on eliminating waste. The system needs to be recognized as complex, where cause and effect cannot be connected upfront.

  • Eliminate waste that slows teams down. The effectiveness of achieving outcomes trumps worker utilization.

  • Encourage more bounded autonomy and more shared and distributed decision-making. This enables teams to define more of the work themselves, so they can easily adapt to complex problems. For this to work, teams each need an enduring mission and to own their backlog of requirements.

  • Give teams ownership of the whole product. The challenge at this stage will be establishing team missions that give ownership of a whole product in themselves, and not components of a product. Each team may be assigned an owner of the backlog of requirements. If it's a real product, they are a product owner. Otherwise, they are a component owner, an antipattern to long-term product-centric agility. Leaders need to trust their Product Owners and ensure they have decision-making authority to prioritize work to achieve their mission.

  • Create persistent teams. Enduring missions need persistent teams, so, managers need to move beyond swapping people in and out of teams as fungible resources. Eliminating different reporting lines should be done now, for example, you don’t need separate test and developer management.

  • Ensure teams have proper skills. Teams need to contain all the skills needed to release working products to real customers, including all stages of the workflow. The Traveller's pattern may be helpful at first to support certain specialists. Investments in CI/CD and independent pipelines to production are an essential ingredient to success.

  • Implement shared team plans, refinements, reviews and retros. Planning and adapting plans occurs at the team level, but teams remain interdependent on one another. Patterns for scaling will likely include shared team planning, refinement, reviews, and retrospectives of the collective system. Stakeholders and leaders should join teams ‘inspect & adapt’ cycles and not have their own separate processes.

  • Build a culture of transparency and respect. With distributed decision-making, transparency of information across the system is essential. Leaders should work to break down silos and create a psychologically safe environment and culture that promotes collaboration.

Resources to help you change

Use these resources as a guide during this evolutionary phase:

Move from interdependent to integrated teams

Leaders, start here if you:

  • Seek to minimize waste in re-work
  • Are moving work around to keep all teams busy
  • Need to reduce systemic inefficiencies and waste, such as additional processing to ensure compatibility of software across teams

Characteristics of interdependent teams

In this context, teams have become more cross-functional, and teams of generalists have become orientated around enduring goals. Team ownership is more around components of a product than the whole product, and so remain interdependent on each other to deliver real customer value. Dependencies exist across teams, which are managed through peer-to-peer interaction, likely through coordinated meetings. Integration challenges limit the ability to deliver value early and continuously.

Steps to move towards being integrated teams

What capabilities do leaders need to create in their organizations to enable the next stage towards greater agility? A leadership mindset shift to make this evolutionary leap will be the greatest constraint. A place of reflection is to explore whether you as a leader are living into a Theory X or Theory Y belief of people motivation.

Ways you can move from being interdependent to being integrated include:

  • Create a single product backlog. Foremost, bring together component teams to create focus around a real product. This means creating one true product backlog of requirements that multiple teams will draw from.

  • Identify one empowered Product Owner. For each true product backlog, have one empowered Product Owner with sufficient authority, accountability and deep entrepreneurial competency. This may lead to some difficult conversations, especially if each team had their own Product Owner before (even if in name only). For leaders, growing safety in the workplace to establish job safety over role safety is a prerequisite for this stage.

  • Create a clear Definition of Done & skill requirements. Role adaptability extends into the development teams. Leaders need to ensure the integrated teams owns a complete Definition of Done and all the skills to get a product to market, with validated feedback, and meaningful interaction with customers. Investment in people and appropriate training to achieve role adaptability is essential.

  • Work from a single team identity. The integrated team has a shared one-team identity, even if it is composed of smaller teams that make up this whole. Planning, refinement, review and retrospection occurs at the integrated team level and may be extended to the inter-team level.

  • Commitment to simplification. Investment will be required to further simplify the system, especially to decouple the architecture and enable greater independence of the integrated team within the wider system. Many integrated teams may exist in a large organization.

Resources to help you change

Use these resources as a guide during this evolutionary phase:

  • Nexus Scrum provides a scaling framework, especially if integration challenges exist on a recurring basis.
  • Large Scale Scrum (LeSS) is also viable and is the foundation for the next stage of agility. 
  • John Coleman agility chef, PKT, PST, LSFT provides a good LeSS and Nexus comparison.

Moving from integrated to whole teams

Leaders start here if they recognize the need for greater simplification of organization structure and processes to better respond to the adaptive problem-solving required to meet complex product and customer needs.

Characteristics of integrated teams

In integrated teams, asynchronous dependencies have been eliminated, yet those that remain relate to integration and require process and human interaction to solve. The whole team identity is strong. Because a psychologically safe environment exists, there is a strong desire to experiment with new ways of working and healthy challenge of existing processes and practices.

The good news for leaders is that this evolutionary step builds upon the action logic and behaviors that were needed to achieve integrated teams.

Steps to move to being a whole team

Ways to move from being an integrated team to a whole team include:

  • Encourage experimentation. Leaders adopt a coaching mindset that enables the whole team to experiment exploring better ways of working. Experimentation is valued over conformance to standards or processes. To achieve this, leaders need to support the self determination of the whole team and uphold unconditional positive regard for their people.
  • Support informal, decentralized communication. With experiments proactively finding better ways of working, the whole team shifts to more informal, decentralized, and fluid communication methods. Leaders encourage this through team co-location (or whatever regional proximity for in person meet-ups is possible in a post-pandemic world).
  • Shift the manager mindset. The role of managers is focused on improving the value-delivery capability of the product development system.
  • Enforce a product-first mindset. Clear product definitions are a must. The whole team supports the Product Owner and is proactive in working directly with stakeholders and customers. A project methodology is no longer tolerated within the organization.
  • Invest in technology, skills, and team communication. Investments in technology capabilities and development team competencies should be made to ensure that dependencies can be managed in code vs. human interactions, and to minimize or eliminate asynchronous dependencies. Additionally, make investments to ensure that the right information systems exist for decentralized and informal communication and collaboration to occur.

Resources to help you change

The design philosophy and principles behind Large Scale Scrum provide the basis for this evolutionary stage.

Move from whole teams to one team

Now, after a long and difficult journey of change and substantial mindset growth, we come full circle back to one team agility. A single team of five to nine people (and probably fewer) have all the skills to meet the demands of the product. They hold a mindset for maximizing value and of early and continuous delivery.

Willem-Jan Ageling’s 2019 article 7 things to check before you decide to Scale Scrum provides the elements of the de-scaling roadmap to achieve one team agility:

  • One Product Backlog with one empowered Product Owner
  • All the skills exist in one team to create a done increment
  • Done really does mean done
  • Stakeholders are present with the team, and plan together


The evolutionary roadmap presented in this article will not be easy to achieve. There will be roadblocks, diversions, and map reading errors along the way. The speed each organization travels through these stages will vary but will always face the single largest limiting factor: leadership readiness and the capability to lead culture shift through structure and process change.

The Agile Fluency Project asks a fundamental question: how agile does your organization need to be? One size does not fit all. Different organizations will find success by operating at different evolutionary stages of agility. Being agile is not the goal. The goal is to solve real business problems.

So, what are your real business problems, and what is your best fit agility?

© 2023 Discover Financial Services. Opinions are those of the individual author. Unless noted otherwise in this post, Discover is not affiliated with, nor endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are property of their respective owners