What is Elevation by Org Topologies?
Elevation by Org Topologies refers to the process of enhancing an organization’s design and functioning to achieve higher levels of adaptability, innovation, and resilience. This method involves a structured approach to understanding the current state of an organization, identifying capability and value gaps, and designing a visionary path forward. By utilizing Org Topologies’ mapping and assessment techniques, organizations can navigate their transformation journey systematically.
This elevation process fosters a more holistic understanding of organizational systems, allowing for continuous improvement and alignment with strategic goals. The ultimate aim is to create a sustainable, high-performing ecosystem that can effectively respond to changing market conditions and drive long-term success.
According to the theory, there are three types of ecosystems. A traditional SAFe adoption is either type-one or a type-two. Both of these ecosystems are characterized by reliance on lower level archetypes (Y0-A3) that are not aligned with business stakeholder needs and customers journeys. Thus, to yield expected results, such archetypes require extra management capabilities, roles and processes.
Note that the type-three ecosystem (known as "Business Agility") requires a complete different set of archetypes reciting in the top right quadrant of the map:
Reasons Why SAFe Adoption Needs to Be Elevated*
* The reasoning below is based on numerous observed SAFe adoptions of various sizes. If your SAFe adoption avoids many of these drawbacks, you are an exemplary exception—
keep up the great work!
1. Lack of True Agility: Many organizations implementing SAFe do not achieve the level of agility intended. They often get stuck in lower archetypes (e.g., A2 or Y2) with significant dependencies that slow down the development process and reduce overall responsiveness to change.
2. Dependency Management: SAFe tends to manage rather than eliminate dependencies. This management approach consumes time and resources, reducing the system’s efficiency and effectiveness in delivering value.
3. Push System Pitfalls: Although SAFe is designed to operate as a pull system, it often functions as a push system. This misalignment leads to decreased adaptability and responsiveness to customer needs, ultimately impairing the system’s performance.
4. Siloed Teams and Fragmented Backlogs: Teams often work in silos with their own backlogs, resulting in local optimizations that do not align with the broader organizational goals. This fragmentation complicates prioritization and reduces transparency and predictability in delivering customer value.
5. Inadequate Organizational Design: The typical SAFe implementation does not address the root causes of organizational inefficiencies. It often fails to align with strategic goals, resulting in suboptimal configurations that need continuous adjustments and elevation.
6. Slow Feedback Loops: SAFe’s dependency on program increments (PIs) with 8-12 week cycles limits the frequency of customer feedback, making it difficult to quickly adapt to changing market conditions and customer requirements.
7. Suboptimal Use of Agile Release Trains (ARTs): ARTs frequently operate as loosely connected teams rather than cohesive units focused on common goals. Elevating ARTs to function as high-performing, integrated teams of teams can significantly enhance their agility and value delivery.
8. Misalignment with Business Needs: SAFe’s structure often separates product management from teams, leading to designs that are difficult to implement and creating waste. Integrating product management and development teams can help align solutions more closely with business needs.
By addressing these issues and elevating SAFe adoption, organizations can improve their adaptability, enhance customer value delivery, and create more cohesive and responsive development ecosystems.
A "Team of Teams" Concept from Org Topologies™
A "team of teams" is an advanced organizational concept where multiple specialized teams are integrated to work collaboratively on broader business problems, creating a larger, cohesive unit. This approach enhances scalability and adaptability by leveraging the combined skills and expertise of different teams to address complex challenges that span their individual scopes.
Key Features of a Team of Teams:
Business Problem Focus: Teams are combined to address business problems at a higher level, often encompassing entire customer journeys or significant business areas.
Self-coordination: The integrated teams coordinate among themselves, eliminating the need for external coordinators.
Shared Backlog: A single business-level backlog is used, ensuring all teams work towards common goals in a synchronized manner.
Higher Adaptability: By working in a shared cadence (e.g., synchronized sprints), teams can adapt quickly to changes and dependencies that arise during the development process.
Simpler Org Design: by allowing your stakeholders and product managers to work with the cohesive unit – a "team of teams" and now pre-cut and pre-assign for the individuals and individual teams.
Synchronous Work on Business Objectives: in contrast with traditional sequential work is planned upfront, the teams within the "team of teams" are able to work synchronously contributing together to the shared business objectives. This is similar to a great Scrum team, where the whole team works as one to complete an end-to-end single piece of customer-facing functionality before moving to the next one.
The last point is critical: it gives us an observable differentiator whether your teams are working as asynchronously (individually) or together as a true "team of teams".
Not how a traditional ART is not a "team of teams". And the fact that the dependencies between different teams in an ART are being analyzed upfront and managed externally to the teams, deprives the teams from an ability to collaborate just-in-time, share work and thus work synchronously. This is so by design: in SAFe because it is given that they are blocking dependencies between the teams, the goal of the framework and its method is to save the team from dealing with the dependencies.
From the systems thinking perspective, such an over-management is a quick fix -- it will not make the system better overtime and the system will always require such an intervention (i.e. PI Planning and Upfront Dependency Management) for the system to work.
Our core belief: a framework (or any management system that we apply) should 1) improve that ecosystem, not merely provide a crutch and 2) become less needed in a long run as the system has healed, improve and acquired new capabilities to deal with those historical problems in an inherent way.
Towards Elevated ARTs, one eARTs at a time:
1. Pick an ART to get elevated.
SAFe adoption is usually advised as a big bang, a "one size fits all" transformation. But once you are ready for a SAFe adoption, nothing stops you from experimenting independently on the ART level. Not all the ARTs need to undergo the same transformation and at the same time. The context matters. Size matters. Steady acquisition of new skills and capabilities matters. The willingness of people to participate voluntarily in experiments matters. So go an ART at a time, provided they can deliver value understood by the business (if not - consider merging the ARTs or pick the ones that do). Pick in ART that has more intrinsic chances of being converted into a "team of teams". Make sure all the members of an ART understand the ultimate goal and the challenges of the journey. Make sure they want to solve those challenges. The challenge must be accepted first before addressed.
2. Elevated an ART's Backlog to Business Objectives.
In practice, an ART often functions as collections of individual teams rather than cohesive units. To achieve a higher level of organizational agility, aim for an ART to reach the B-level archetype (a "team of teams"), characterized by a focus on business value and a higher degree of adaptability. This requires for all the teams in an ART to share the same context. They should stop seeing individual features or tasks being fed to them as their work. Bigger, challenging business objectives should be used to unite them and help them see they need each other to work together on those. So present a united backlog formulated on the level of business objectives to all teams in the ART. You don't need to create special roles to do this work. The existing group of product managers, product owners plus selected team members and stakeholders shall become up with a list of prioritized business objectives. In most cases, such a list already exists.
3. Contain the dependencies and allow for synchronous work of multiple teams.
SAFe tends to manage dependencies rather than addressing the root causes of their existence (i.e. focus on component development rather than end-to-end customer-facing functionality). To elevate an ART to be able to self-manage cross-team dependencies is the goal here. This can be achieved by minimizing WIP and allowing the teams to work together on a single business objective and in the shared cadence. In most cases, some form of technical coaching will be needed to teach the teams to integrate across the teams continuously. Dispersing the teams or lightning up the team boundaries is usually very helpful in this period. It's absolutely OK (and must be taught and appreciated) for the team members from different teams to work together on some core pieces of functionality. The "team of teams" should be more important than the individual teams within.
4. Improve an ART at a time.
Don't cancel any existing SAFe rituals, but first add processes that will allow the teams to have a shared context and a cadence. Postpone your judgements about the speed or performance of your Elevated ART (eART). Remind yourselves and the others of the goal: creating a cohesive unit which can act together as one -- jumping on bigger problems and learning and working in-sync. Work as one and learn as one: apply inspection and adaptation as well as managers' support to solve raised impediments via overall retrospectives, joined backlog refinements, cross-team mobbing sessions, collecting multi-team architectural workshops and joint increment reviews.
Comments