Org Topologies and Feature Team Adoption Map

While studying organizational design, we created a visual representation of our findings using the Org Topologies™ Map. When explaining our concepts at various conferences and meetups, some people ask questions about the relationship between the Feature Team Adoption Map (FTAM, as known from LeSS) and Org Topologies™. The purpose of this short write-up is to clarify the similarities and differences between the two.

The conclusion is: At first sight, there are some similarities, however, the two graphs serve a different purpose and are used differently. We should not compare them as they are too different.

The Feature Team Adoption Map

Just to align our thoughts on the Feature Team Adoption Map (FTAM), let's start with a short explanation of what it is and how it is used. I was not able to find a formal definition in the LeSS literature, but I think we are pretty close by saying: “The feature team adoption map is a graph that displays a product group's capabilities, expressed as the potential technology work scope and the degree of cross-functionality in the teams of that group”.

Although the name Feature Team Adoption Map suggests that this is a tool to map teams, it is not. It is a map that displays organizational capabilities. The FTAM suggests Feature Teams as a building block for adopting an organizational design. Feature teams are defined in LeSS:

A feature team is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one.

The FTAM concept looks like this:

POTENTIAL TECHNOLOGY WORK SCOPE INSIDE THE TEAMPROBLEMWHOLE SYSTEMWHOLE PRODUCTSUBSYSTEMCOMPONENTFUNCTIONAL OVERSPECIALIZATIONIDEAL STATE! HARD TO ACHIEVE, GOOD TO WORK TOWARDSFEATURE TEAMSCOMPONENT TEAMSEXTENDED COMPONENT TEAMS: CONFLICT IN SCOPE IN THE TEAM LEADING TO DUPLICATION OR ADDITIONAL COORDINATION WORKNOTHINGCODE+DESIGN AND UNIT TEST+SUBSYSTEM ARCHITECTURE AND TEST+ANALYSIS AND SYSTEM TEST+CO-CREATIONACTIVITY (FUNCTION) INSIDE THE TEAM. DEGREE OF CROSS-FUNCTIONALITYhttp://less.works (CC BY-ND)

Hover over or tap any text on the drawing to read it.Tap any text on the drawing to read it.

The FTAM is used in LeSS Huge adoptions to:

• help in defining the scope of teams when forming feature teams,
• define the size of an adoption, and
• set future improvement goals.

The FTAM is used at the organizational level and focuses on organizational capability. In LeSS Huge, the change is gradual and may take many years to achieve full capability. The purpose of the FTAM is to map out different stages with timelines for when each change can happen and what that change might look like. At the beginning of a change, the FTAM can be used to set the stage for this process and have a vision and strategy for how to get to perfection. Such mapping can look like the picture below.

POTENTIAL TECHNOLOGY WORK SCOPE INSIDE THE TEAMPROBLEMTELECOM NETWORKWHOLE PRODUCTSYSTEM COMPONENTCOMPONENTFILE/CLASSNOTHINGWOULD REQUIRE INVOLVEMENT IN STANDARDIZATION OF TELECOM NETWORKOUTSIDE CURRENT ORGANIZATIONAL SCOPEORGANIZATIONAL CONSTRAINT OR SCOPE OF PRODUCT GROUPGOAL NEXT FEW YEARSCURRENT STATEORIGINAL TEAMS BEFORE LESS ADOPTIONCODE+DESIGN AND UNIT TEST+SC DESIGN AND SC TEST+SPECIFICATION AND ENTITY INTEGRATION TEST+SYSTEM DESIGN AND SYSTEM VERIFICATION+STANDARDIZATIONACTIVITY (FUNCTION) INSIDE THE TEAM. DEGREE OF CROSS-FUNCTIONALITYhttp://less.works (CC BY-ND)

Hover over or tap any text on the drawing to read it.Tap any text on the drawing to read it.

The current activities or capabilities (horizontal axis) of a product group are mapped in relation to the product technology breakdown (vertical axis). Such mapping could tell us for example that most of the teams in the group code their component and then hand it off to testing teams.

The FTAM should be created at the organizational level to analyze the current state of a product group. To get insight into the level of cross-functionality of the product group, the degree of cross-functionality in the teams is studied. Since the cross-functionality happens within each team, "the team" is mentioned on the axes.

We have found that understanding FTAM is not easy for a couple of reasons:

• The FTAM appears to be more than just a map.
• When applying the FTAM, additional dimensions need to be considered that are not mentioned on the map (e.g. Private-code policies, capability,..)
• The naming on the FTAM axes is confusing (explicitly referring to single teams while the map is not about single teams but product groups)
• Explanations on the LeSS website and in the LeSS books are limited.

The Org Topologies™ Map

For how the Org Topologies map works, see Org Topologies mapping.

The picture below of the journey of a department at a Dutch bank shows that in their starting position, the bank did not work with stable teams. They had individuals and groups working on tasks (Y0 [TASKS-1] and Y1 [TASKS-1]), and component teams trying to work on features (A2 [CAPS-2]). Their anticipated goal was to resolve dependencies by moving to the B2 [PART-2] archetype, meaning they planned to create value areas where multi-disciplinary teams deliver customer features. This would require teams to be reshuffled to improve the capabilities of the feature teams (horizontal growth) and would require new practices to work on a product part with groups of teams (vertical growth).

There Are Similarities

When we started exploring the problem space of adaptivity, we had LeSS in the back of our minds. We are LeSS-friendly people because LeSS is a very adaptive approach for product development. The idea that the Org Topologies™ map would be similar to FTAM was an observation we never were aware of until someone asked us about it. We were surprised, as the two tools are very different, although we need to admit that at a first glance, novices might be confused by some obvious similarities. Both graphs:

• are two-dimensional graphs and have an x-axis and a y-axis
• talk about teams in the context of product development
• visualize shifting from component/technology to customer/product-centric specialization
• have an x-axis that tells something about team capabilities
• have a y-axis that tells something about collaborating on the product
• can be used to monitor growth toward a better state of adaptivity
• plot items against a perfection vision of high adaptivity
• help to leverage bi-directional team growth to reach a sweet spot
• both are graphs that are more than just a picture

But They Are Not the Same.

There are essential differences between the two maps:

• The FTAM is only used in LeSS Huge adoptions. The Org Topologies™ map is framework agnostic.
• The FTAM gives insight into the adaptivity of a product group and its anticipated future state. The Org Topologies™ map gives insight into the current and future adaptivity of various types of organizational units (individuals, teams, areas, departments, or organizations).
• The FTAM shows four areas (component teams, feature teams, extended component teams, and functional overspecialized teams). The Org Topologies™ map describes sixteen archetypes.
• In the FTAM, the X-axis describes the cross-functionality of a team, and the cross-component-ness of the team is on the Y-axis. The X-axis on the Org Topologies™ map describes both cross-functionality and cross-component-ness.
• The FTAM template needs to be instantiated in each context where it is used. To explain what instantiating means, find an example of such instantiated FTAM below. Notice that the naming on the axes has been contextualized. The Org Topologies™ map can be used as-is to compare, recognize, and locate your org design in relation to an anticipated perfection goal. Additionally, this allows us in theory to compare Org Topologies™ maps from different groups, departments and organizations. This is not possible with an FTAM.

Feature Team Adoption Map for BIOS TeamsPotential Technology Work Scope Inside the TeamEnd Customer NeedEntire Nakashima product catalogWhole MCS systemSub-System related functionality throughout whole MCS system (e.g. BIOS code plus portions of other sub-systems)Entire Sub-System (e.g. BIOS)Narrow Code Area/File (e.g. Code area within BIOS)NothingActual Product Boundary (Divisional Scope)Expanded BIOS Multi-Component BoundaryInitial BIOS Component BoundaryOrig. BIOS Developer ScopeNothingCode/HW DebugSub-System VerificationSystem VerificationSystem SW/HW Arch.Whole Prd. Catalog Scale VerificationActivity (Function) Inside the Team, Degree of Cross-Functionality

Hover over or tap any text on the drawing to read it.Tap any text on the drawing to read it.

Example of an instantiated FTAM for the Nakashima product catalog. Notice how the naming on the axes has been changed to reflect the organizational context.

Example of two ways to represent an organizational mapping with Org Topologies™. Note how the axes remain unchanged. The red dots in the picture on the right represent teams or people of that archetype that are playing a part in the ecosystem. (More elaborate versions can be created where each red dot is named specifically: team Avengers, Lead Architect, etc).

Conclusion

The tools are both focusing on the domain of organizational design and in their own way, they try to clarify organizational change. However, we conclude that these tools are very different from each other, and comparing the FTAM with the Org Topologies™ map is like comparing apples with pears.