A de-scaling roadmap for agile teams

Evolving towards One Team wholeness

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?

Building upon an earlier article of mine, Evolution Towards One Team Wholeness: a perspective on descaling organizations, 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 weighted in Scrum. There are other lenses.

From Dependent Specialist to Interdependent Teams

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

Does this context ring true? People are seen as fungible resources, and organized into dependent teams of specialist disciplines, e.g., Java, testing, UI, etc. Work is assigned to these teams by external control (i.e, portfolio, program or project management), and requirements are also owned externally to the teams. Work is driven nearly exclusively by deadlines, and keeping everyone 100% utilized is top of mind. System bottlenecks occur as specialist teams own specific stages of the workflow (e.g. a system team or release team) and these teams complete work at different rates than planned.

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

• Leaders need to 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.
• The leadership role is to make the system more effective by eliminating waste that slows teams down. Effectiveness of achieving outcomes trumps worker utilization.
• With the complexity belief, comes recognition that for adaptive complex problems, the work cannot be defined for the teams, and that decentralized and distributed decision-making is required. For this to work, teams each need an enduring mission and to own their backlog of requirements.
• 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, which is 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.
• 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, i.e. no separate test and developer management.
• 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.
• Planning and adaptiveness is occurring 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, not have their own separate processes.
• 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.

For this evolutionary stage, organizations could be looking at Scrum@Scale, or a disciplined implementation of Kanban. The Disciplined Agile — Continuous Delivery: Lean model could be viable here.

From Interdependent to Integrated Teams

Leaders start here if they seek to minimize waste in re-work; they are moving work around to keep all teams busy; and there are systemic inefficiencies and waste, such as additional processing to ensure compatibility of software across teams.

Does this context ring true? 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 generally managed through peer to peer interaction, likely through coordinated meetings, and integration challenges limit the ability to deliver value early and continuously.

What capabilities do leaders need to create in their organizations to enable the next stage towards greater agility? Leadership action logics to make this evolutionary leap will be the greatest constraint.

• Foremost, bring together component teams together to create focus around a real product. This means creating one true product backlog of requirements that multiple teams will draw from.
• 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.
• 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.
• 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 in addition may be extended to the inter-team level as well.
• Leadership focus is on enabling the integrated team to create value and a product mindset. Leaders meet the teams where they are, with ‘go and sees’ and joining team events now taking place of any remaining status updates.
• 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.

For this evolutionary stage, Nexus Scrum provides a possible 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.

From Integrated to Whole Teams

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

Does this ring true? Asynchronous dependencies have been largely eliminated, yet those that remain relate largely to integration and require process and human interaction to solve. The whole team identity is strong, and as 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 logics and behaviors that were needed to achieve integrated teams.

• Leaders adopt a coaching mindset that enables the whole team to run safe to fail experiments exploring better ways of working, and 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.
• With experiments driving proactivity in uncovering 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).
• The role of managers is focused on improving the value-delivery capability of the product development system.
• Clear product definitions are a must, and the whole team supports the Product Owner, and are proactive in working directly with stakeholders and customers. A project methodology is no longer tolerated within the organization.
• Investments in technology capabilities and development team competencies should be made to ensure that dependencies can be managed in code vs human interactions, and minimize or eliminate asynchronous dependencies.
• Investments are made to ensure that the right information systems exist for decentralized and informal communication and collaboration to occur.

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

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 5–9 people (and probably fewer) has 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?