Introduction
Many organizations have discovered that a cultural shift towards greater agility is hard to do and is constrained by their structure and processes. These processes, in turn, are constrained by their leadership mindset and behaviors in enabling change towards achieving the level of agility they need to respond effectively to market and customer needs.
In this blog post, I talk about my own experience, observation, and learning of organizational evolution towards agile ways of working, particularly the push and pull towards scaling or de-scaling.
This post is inspired from a talk Simon Powers gave in a in the summer of 2022, which is in itself based on a talk from Craig Larman, the co-creator of Large Scale Scrum (LeSS).
Six evolutionary stages
The image below depicts the journey, through which this model theorizes six stages that organizations may progress through toward One Team Wholeness. One Team Wholeness is defined as the state that provides the conditions in which the greatest value from agile ways of working can be realized.
We should recognize, however, that reaching the top of this evolutionary pathway should not be a goal itself. The foremost question is: How agile do we need to be to solve our real business problems, and does our current stage of agility enable us to do this?
No teams
In this stage of the evolutionary journey, there are no teams. Departments are made up of individuals with specific skills that are coordinated through hierarchies. In this state, people are seen as fungible resources, given specific work items, and moved from project to project.
Value generating cycles are long and driven by project management. Complex environments will often fail to meet their expected promise. In this mode, enterprises position people with deep specialists into narrow boundaries of focus and autonomy. This is, for example, when organizations hire chess masters and treat them like pawns (Theory X as defined by McGregor in the 1950s).Leaders are firmly entrenched in (Theory X .
Specialist teams
Teams are built around one or two specialisms, for example, Java & QA testing. They are often seen as fungible, that is, people can be swapped around in teams, and teams are asked to pick up different packages of work. Teams represent groups of individuals over truly collaborating groups. A complex network of interrelated and overlapping dependencies must be managed by humans, often requiring a lot of collective time and effort.
Specialist teams own specific parts of the path to production, for example, the User Acceptance Testing (UAT) team, the Systems Team, and the Release Team. Handovers cause delays and bottlenecks constrain a system that is not well understood. Given these constraints, teams batch work and delay integration.
The enterprise attempts to increase system throughput by adding more teams to overall capacity, which compounds the problem and further constrains the system's effectiveness. Theory X prevails and teams may be blamed for not working hard or smart enough.
Teams hold knowledge in silos, where “only that team knows how that component works”. There is a "just get started" mentality derived from the tyranny of high utilization. The enterprise may have a single ordered backlog of priorities; however, teams pick the highest work that they can start, meaning that work on the backlog is achieved in a different order than it is prioritized (with high lead and cycle times to boot). The system of constraints is the true prioritization mechanism. Opportunity costs are high.
Connected teams
With connected teams, teams have become more cross functional, containing the skills that they need to release to production. These are teams of generalists that have become more orientated to an enduring Product Goal. Team composition has become more persistent, and they hold collective identity as a collaboration team.
These teams remain interdependent on one another to accomplish real customer and business valued outcomes. Management of these dependencies is more greatly decentralized across the teams, but are still managed through human-to-human communication,
Each team has their own prioritized backlog. Greater independence in releasing value allows them to begin focusing less on utilization (what keeps us busy) to effectiveness (what is the most valuable work that we can now do?).
This evolution has become possible by leadership shifting into Theory Y, enabling more bounded autonomy to teams, with greater shared decision making.
Integrated teams
Cross-functional teams have built greater resilience that has resulted in longer lived persistent teams. Team identity has grown from the individual team to the Team of Teams. The guiding metaphor for this culture has moved from the well-oiled machine to that of the family.
The Integrated Team has a single prioritize for the first time by a single Product Owner empowered with appropriate authority to make decisions. As a result, the Integrated Team takes responsibility for customer and stakeholder interaction. while the Product owner takes a more strategic stance.
Dependencies and integration challenges remain significant, and the Integrated Team has dedicated roles within each team to ensure that integration of a Product Increment is achievable on a regular cadence. These roles are not job titles but accountability hats that can be shared.
Whole teams
Dependencies are now managed through code and not people. The integration challenges have been resolved to a point where dedicated roles are no longer needed to ensure integration occurs regularly.
Whole Team identity comes fully before the individual’s identity, and the team of teams has become highly collaborative. There is persistency within the Whole Team, but there is fluidity within the individual teams as they swarm around the work.
Focus is on effectiveness over efficiency. By maintaining incremental, fully integrated product increments on a regular cadence, the Whole Team can pivot with low stitching costs.
One team
A single team is fully cross functional and able to meet the demands of a Product Backlog, including being able to meet the time criticality of valuable work that decays over time.
This is not to say that a single team results in a reduction of head count, just that the bonds between teams are now no longer defined by dependencies, technical or otherwise.
The organizational metaphor has moved from family to living organism, as described by the Laloux Culture Model—if indeed it had not already been in the prior evolutionary state. An alternative hypothesis: therefore, the next stage from Whole Team might instead be the dissolution of the individual teams from within.
The evolution presents the descaling of organizations, as tight dependency bonds between teams are progressively loosened and broken into smaller and smaller networks of interconnected teams. This is not about organizations becoming smaller, or reducing headcount, or doing less with more. This model identifies however that there is a non-linear value amplifier, of teams becoming exponentially more effective at delivering value as the organization progresses through each stage.
Intermediary states may exist that draw in elements of the next stage. Or legacy structures and long-lived impediments act as an anchor preventing forward momentum. As stated, it should not be a goal to move an organization up through these evolutionary stages, for example, the transformation of specialist teams into a Whole Team. Similar to the Agile Fluency Model, there are many valid destinations. How agile do you need to be to meet your unique business challenges?
Crossing boundaries
Structure follows business need, and the most significant limiting factor is still leadership behavior and mindset. The green and teal structures on the diagram, mapping to the Laloux Culture Model, cannot be achieved or sustained without leaders who create the conditions for empowerment and cooperation, and give the power of decision-making to those closest to the work. This change requires leaders that can shift their leadership mindset and behavior from Theory X to Theory Y.
The boundaries, therefore, between one evolutionary stage to the next must be crossed with intent and supported by appropriate investment.
These include investments into:
- Leadership behavior, beginning with leadership self-development, coaching, and strategic hiring to advance their collective Action Logic.
- Appropriate structures to organize around value and to eliminate different forms of waste.
- DevOps to shorten the system's development life cycle, to enable continuous integration and continuous deployment. This is essential in pushing dependencies from being managed by many dozens of people meeting daily or weekly to managing dependencies in the code itself.
See the article A Descaling Roadmap for Agile Organizations for more investments that must be made.
Throughout this evolution, sufficient and sometimes significant training is needed to enable everyone working within this system to apply new thinking and ways of working such that a new culture can emerge.
It is vital to start where you are now, and to understand what is true about your current context -- the good, the bad and most certainly the ugly. Which evolutionary stage represents where you truly are at? Does it serve your business needs? Can you optimize with incremental improvement for your current stage, or is radical change needed?
No backwards steps
Through discussion on this model so far, we believe it would be harmful to deliberately move backwards on the evolutionary path. The possible exception to this being a move from One Team to Whole Team, demonstrating this is the least developed area of understanding so far.
Moving down one stage or more may have to happen as a consequence of other forces at play. For instance, if the only leader with a transforming Action Logic leaves for a new company, and the remaining leaders cannot sustain the psychologically safe environment needed for the green or teal structures. Or high turnover leaves a whole team full of new faces, and for a time people are once again needed to support integration as a dedicated role. Or the technical debt of a once-ordered code base is left unchecked, code branches are left open for glacial epochs, and people are once again reduced to joining regular calls to crawl through integration issues. In other words, the agile culture bubble has imploded.
Mapping to scaling frameworks
Throughout this article you may well be considering how your companies, past and present, have mapped to this model. That may also then connect with the methodology or framework that these organizations have been using to coordinate and manage the generation of value.
I suspect the graphic below is the part of this article that is likely to draw contention. It is based almost entirely on what I intuitively believe to be correct based on my experience and knowledge of these various frameworks, and so far, validated through discussion of some 30+ agile coaches and practitioners who draw experience widely and deeply from many different companies, industries, and contexts.
The Integration Team stage is almost entirely inspired by the Nexus Scrum framework, and the Whole Team on the work by Craig Larman with LeSS. That is not to say that these are the only frameworks or ways of working that will suit these evolutionary stages. Sociocracy 3.0 offers ways of working that seem very compatible with the Whole Team and One Team stages. In fact, these later stages can be noted by the fluidity of their agile practices, versus the adoption of any single framework.
Summary
In summary, this model helps frame where an organization is today. In understanding where your team is now, it also offers views on what would need to be true to achieve the next stage of evolution.
If this model has legs, it would be great to develop it further through support of secondary research and primary in the form of case studies. If this sounds like something you might like to contribute to, to a greater or lesser degree, please do get in touch.
