Not Yet Another Team Maturity Model
The mission of the Org Topologies™ is not to develop another team maturity and assessment model, but to expand our systemic view on the entire value-creating landscape.
The essential questions that the Org Topologies™ explores are:
How can we build an organization where the synergy of all the teams equals the performance of the organization itself? This means elevating the collaboration of the teams to the highest level by eliminating all unnecessary levels of indirection and management.
How can we create a team of teams that is capable of discovering and delivering value to the customers? Meaning, expanding the collaboration of the teams on all fronts (which is referred to as 'left-shifting' - blending discovery & delivery) and getting to zero distance to the customers.
Which org archetypes need to be put in place to realize the maximum potential of the people in the organization?This means uplifting people to the most humanistic and human-centered org design that helps people grow.
All these questions are not about individual teams and their solo performance. The scope is rather on designing organizations for tight collaboration as a holistic value-creating ecosystem. This article explores some of them.
Ecosystems Thinking
Org Topologies Mapping's most prominent benefit is to provide a visual language to model ecosystems - groups of work units cooperating to get things done. Comparing and contrasting such models might serve as a powerful source of insights on finding the true-north vector for the long-term development of your organization.
Let's look at three very recognizable yet distinctive ecosystems that prevail in the digital product development space.
Ecosystem Type 1: Pre-Agile (Matrix Organization)
As depicted in the image above, such an ecosystem consists of the low-level delivery-oriented archetypes (Y0-A1) which are either task-focused single-skill individuals or feature-focused functional groups.
Because none of these archetypes can produce end-to-end customer value independently, they require each other plus the special higher-level archetypes to perform upfront analysis and discovery work.
Such a setup typically results in analysis work being handed over for implementation in the form of thorough requirement specifications followed by heavyweight upfront planning and estimating, followed by identifying and then tracking the numerous dependencies.
From the lean thinking perspective, such a process results in overcomplicated big batch processing that contributes to all kinds of inefficiencies and waste. From the process perspective, such an ecosystem will have to master the sequential staged development process, also known as waterfall.
To manage this excess complexity, organizations that are organized in such a pre-agile ecosystem need to rely heavily on the practices of traditional project management. A presence of a dedicated project management office (PMO) is not rare. It would act as an intermediary between the business-oriented and delivery units of the ecosystem, thus contributing to the inherent lack of transparency and effective business-to-IT collaboration.
With such a strong focus on inner concerns (i.e., managing projects), these ecosystems would have to optimize for what they can measure and manage: that is, utilization of existing skills instead of customer value impact. This creates a strong focus on resource utilization and prescribed process culture.
So no surprise, Ecosystem 1 is usually contrasted with "agile". But is it so black and white?
Ecosystem Type 2: Agile Teams (Fast Local Flow)
This ecosystem upgraded its delivery units to 'agile teams', essentially forming cross-functional units with a focus on fast flow. That is a great improvement compared to the pre-agile setup (see Ecosystem 1 above). Such teams (Y2-A3) are better fit for fast delivery and reacting to feedback - fast flow of change within a narrow scope of ownership.
This kind of transformation we call "the first wave of agile" - moving the delivery box to the right. Getting faster with better flow. Creating such an ecosystem has been the main focus of many agile change agents for the last few decades. A series of frameworks and methodologies have emerged to provide practices and tooling for creating and sustaining such constructs, with a strong focus on increasing the 'flow of change'.
Discovery and delivery are separated. Resulting in what some people call a "dual track agile". That is a half-measure, a half-backed agility. Thinkers and doers are separated. That is the same old Taylorism. Unchanged paradigms. Sloppy thinking.
Maybe some things have slightly improved compared to the matrix world of Ecosystem 1, but in general, it is naïve to expect a drastic organizational improvement with such an org design. So, no surprise:
Last year [202], over seven in ten respondents (72%) said they were satisfied with the Agile practices in their company, while this year, that has dropped to three in five (59%). – 17th Annual State of Agile Report
In such ecosystems, the so-called 'agile practices' mainly affect how delivery is being run, but they failed to introduce systemic changes to the power structures and the way delivery learns what to work on.
Traditional top-down analysis with dedicated 'discovery groups' is a very prevalent way of managing requirements engineering in such ecosystems.
Separating Dreaming, Thinking, and Doing is the deadly sin of large organizations. It will lead to Coordination Chaos: fragmentation, waste, and underperformance.– Ari Tikka from gosei.fi
Result? Big batch processing, hand-offs, queues, waiting... No surprise, countless organizations that invested in creating so-called "agile teams" still have to fall back on traditional project management practices to deal with dependency management and execution concerns. That's why there is still a "projects" box in the illustration above, the same as in the pre-agile ecosystem.
Unless you elevate the whole ecosystem (simplifying and integrating it), some notion of projects will still need to happen to provide some even illusionary understanding of control. In this ecosystem, projects have to support the need for scoping agreements between business and IT, plus decent dependency management. The more teams are added, the more dependencies will emerge, and the more efforts need to be spent on managing such a system.
Because of the above: such an ecosystem scales badly. Thus creating a fruitful market for so-called "agile scaling solutions". Aiming at streamlining the complexity of management at scale. But the root causes that create that complexity and difficulty of scaling remain unsolved.
Long-term effect? Unsatisfied business stakeholders (things are still slow from their global perspective), and demotivated members of the agile teams due to lack of empowerment and constant micromanagement. More investments into such an ecosystem won't necessarily result in more impact. ROI is problematic. We should see how organizations that have been creating such ecosystems will deal with the ongoing light financial crisis. Unfortunately, we will see more layoffs but as a result, hopefully, more systems thinking.
Ecosystem Type 3: Business Agility (Team of Teams with Co-Ownership)
This last ecosystem that we are discussing in this article merges "dreaming, thinking, and doing" into one holistic workflow. This is what we call "the second wave of agile". This is a true upgrade, uplifting of the whole ecosystem.
Such change is to enable the "cooperative game of invention and communication" as the co-creator of the Agile manifesto, Alistair Cockburn, nicely put it in his industry-changing book "Agile Software Development: The Cooperative Game".
Structurally, to create the preconditions for such rich collaboration, an organization needs to introduce the notion of a team or teams. This is a scaled concept - where a collective of agile teams work together with each other and with the customers, business stakeholders, and subject-matter experts to outlearn the competition.
In the Org Topologies language, we call this an elevated ecosystem - a true enabler of business agility. This can be made possible by investing in both: flow and learning.
This can be achieved by allowing the agile teams to co-own the business/customer domain - going up the "scope of work", the Y-axis of the Org Topologies map.
Making teams co-own and thus truly co-create, requires removing all artificial boundaries that would otherwise cause the "us-them" mentality and result in a "not our job" culture.
The B2-C3 archetypes of the Org Topologies are gaining the best of the two worlds by combining flow efficiency with outcome orientation (see the illustrations above). This is the space of Business Agility.
Learn about the Elevating Structures™ and Business-Oriented R&D to discover the ways to elevate your ecosystem and gain the true benefits of agility.
Comentarios