When talking about LeSS adoptions, the Feature Team adoption map (FTAM) is often brought up as one of its powerful tools. Although FTAM is described in the LeSS book (1), and gets a great deal of attention in most LeSS practitioner classes, it plays a less important role in LeSS and LeSS Huge adoptions than we might suspect. However, it is a valuable tool that can be used for various purposes.

What is it?

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 team’s ability to deliver “done”, expressed as the potential technology work scope inside the team and the degree of cross-functionality in the team”.

The Definition of Done (DoD) shows the abilities of a team in terms of the activities required to deliver a potentially shippable product, which is the same as the team’s degree of cross-functionality. The FTAM extends this with the team’s knowledge of the product domain, which is the same as the team’s degree of cross-component ability. Stated in other words, the FTAM is an extension to the DoD, adding a second dimension (of product) to that concept.

The FTAM picture below is used in the LeSS book.

Feature Team Adoption Map in LeSS and LeSS Huge

Although the FTAM tool is described extensively in the LeSS literature, it not used in LeSS adoptions and only exceptionally in LeSS Huge adoptions. Let me clarify this.

In the LeSS book (1), the use of Feature team Adoption Maps is described in two guides:

• “Guide: Feature Team adoption maps” (page 90)
• “Guide: Transitioning to Feature Teams” (page 106)

The FTAM is not described in the LeSS rules, but in the guides. Guides in the LeSS book are defined as: “A moderate set of guides to effectively adopt the rules and for a subset of experiments; worth trying based on years of experience with LeSS. Guides contain tips. Usually helpful and are an area for continuous improvement; e.g. Three Adoption Principles.”

This implies using FTAMs might be helpful but it’s not mandatory when adopting LeSS.

smaller LeSS Framework

According to the guides, the FTAM can be used when adopting feature teams. Adopting feature teams is not uncommon in LeSS adoptions, as the LeSS Rules state that “the majority of the teams are customer-focused feature teams”. Creating an FTAM then:

• helps in defining the scope of the feature teams,
• helps to define the size of your LeSS adoption,
• sets future improvement goals.

In practice, the FTAM is not commonly used in the smaller LeSS framework adoptions (in contrast to LeSS Huge framework). This is because LeSS adoptions are relatively small. The product diversity is small enough for everybody to understand “done” on both the cross-functionality and product domain.

LeSS Huge

When adopting the LeSS Huge framework, the FTAM can be used:

• to define the adoption context which will clarify the current degree of team specialization.
• to support the incremental LeSS Huge adoption strategy of “gradually expanding scope”, in which the FTAM is used to mark the future scope expanding goals. However, the LeSS adoption principles suggest a preference for a narrow and deep approach, which the “gradually expanding scope” approach is not.

When can the Feature Team Adoption Map be used?

You will find great value in using this tool with the purpose of supporting:

Feature team adoptions:

Your organisation wants to move towards feature teams coming from component or functional teams. In large organisations, the number of variations in team abilities and software components might be overwhelming. Drawing maps will visualise how you can group your components into features, thus revealing the learning effort required by the teams and the impact the transition will have on your organisation.

Preparing LeSS Huge adoptions:

During the preparation phase of the creation of the initial Requirement Area(s), the FTAM serves as a useful thinking exercise to extract as many preparations as possible. It will help us get the most of the flip-needs visible; without the structured way of thinking through preparation needs for a flip we will definitely will miss out on some obvious things that are needed making the flip more difficult.

Growing toward perfection:

When your organisation is working with feature teams, your current DoD is likely to be imperfect, as with (almost) everything in life. There are always new activities that can be added to the abilities of the feature team to deliver closer to truly “done”. You can use this tool as a beacon to guide the teams’ growth towards perfection. In a company I worked we identified the activities of “creating user manual” and “making instruction video” as future cross-functional team activities.

How to create a Feature Team Adoption Map

The FTAM can be created when we want to transition to feature teams or when we want to monitor team growth towards perfection. On the vertical axis of a FTAM we plot the product, and on the horizontal axis we plot the Definition of Done (DoD). In the chapter “Getting started” the LeSS book describes step 1 (define product) and step 2 (define done). Combining the output of these steps into the feature team adoption map provides big context.

The Vertical Axis: Product

When creating a FTAM, we start with the product axis because the horizontal axis describes activities needed for “done” and that requires the context of a product. Yi lv explains this in his blog (2): “The definition of a feature is dependent on the definition of the product. The product bounds the feature, and the feature is end-to-end within the product.”. It is often difficult to find a common agreement on the product definition. In many cases, the product definition is bent with components being defined as product, which leads to fake FTAM’s and messy setups.

The LeSS book (1) advises a procedure of asking restraining and expanding questions to identify the product elements. Expanding questions relate to “What is bigger than our current product that would satisfy the customer need?”. Answers to this question will be in line with product strategy and broaden the current product scope. A common misunderstanding here is that the product referred to is the LeSS product, while people think it’s the customer product. The LeSS product is the product as perceived by software development. Let’s take an insurance as an example. The paper you have at home on which you can read you are insured is the embodiment of the insurance product. The software needed to provide the insurance service is the LeSS product, which includes an app, website, insurance policy administration, settlement software etc.

Asking the restraining questions should provide better understanding of our product features. The goal of knowing these features is to identify which knowledge is needed in each of our future feature teams. The question we need to therefore ask ourselves is: “What is the feature that the customer desires in our product and what components does this feature consist of?”. To be able to answer these, we need a product backlog. Using features on the product backlog, we can trace back which components of our software landscape makeup that feature and group the components by the likelihood they need to be changed together when the feature needs change. This will reveal logical grouping of components into features and thus will show future team composition. While asking the restraining questions we will also discover which components will be excluded due to organisational constraints or lack of affinity.

The Horizontal Axis: Activity

For creating the horizontal axis, we enumerate all the activities a team needs to do to produce a potentially shippable product, i.e. the Definition of Done. When enumerating the activities, pay special attention to the testing activity. Testing as an activity is too broad and should be expanded to enumerate the different types of and different levels of testing (unit, integration, pen, performance, regression,…). Order the activities from small to bigger scope, in the order, the teams normally do their work. Enumerate all activities needed to get the product in the hands of the customer. If your teams are not perfect yet, this will span multiple teams and possibly multiple departments.

An example

The FTAM picture published in the LeSS book is helpful to understand what an FTAM is, but it is not specific enough to learn how to create one.

This example below is an FTAM of an imaginary company that builds a CMS (content management software). The company has set their product expansion strategy to grow towards a product that covers the customer’s financial needs. The existing component teams are capable of changing a single component, for example Portal Front End (portal FE). There are other component teams working on the Portal Back End (portal BE).

The blue rectangle represents the teams’ current capabilities. These component teams test their solution for integration problems, before handing their code over to the integration department, responsible for staging, integrating and user acceptance testing. After that, the software is handed over to the release department, who will perform the remainder of tests and takes care of deploying to the production environment.

For this organisation to move towards feature teams, the future teams ideally need to specialise in the customer domain so they can tackle customer problems at product level: CMS-problems, which means fixing front-end and back-end code in portal, manager and platform components. Unfortunately this is not possible yet as this company is working with a nearshore partner who is currently taking care of all portal component changes. To create perfect feature teams, all knowledge will need to be co-located and this is not possible in the short term. The new feature teams that will be created initially will be able to handle all software changes at the system level: a portal, a manager and a platform team.

This is not ideal, but a good step into the desired perfection direction. The Product Owner verified the features in the Product Backlog to ensure that there are very few features that require changes in multiple systems (portal, manager and platform), i.e. there is low dependency.

The DoD for the new feature teams (the orange block) does not include user acceptance testing. The cross-functionality level of the new feature teams was set to the minimal set of capabilities (up until system test), as this is the level of Done that all new feature teams can deliver. Some future feature teams were already able to include the activity of user acceptance testing, but unfortunately, not all teams were capable of doing so since there were not enough people with the right skills (yet).

An organisational constraint is present on the activities axis: after user acceptance testing, the software is handed over to the support department, responsible for penetration, performance and deployment. At this point in time, developers are not granted physical access to these environments due to existing security policies.

The Feature Team Adoption Map makes visible the current and future state of the feature teams’ capability to deliver “done” product. It may be difficult to create teams with full product scope and all activities covered as it would require a too much organizational change that could possibly incur business risk. In such case, these capabilities are excluded from the current scope of the teams, by which the FTAM serves as a visualisation of the perfection goal.

Endnote

In this article I have tried to explain what a Feature Team Adoption Map is and how it can be used. Although this article might have helped you to better understand, creating one yourself is the best way to learn. I invite you to use the approach as described and try to create a FTAM of the teams in your organisation. Do not hesitate to share your findings.

Addendum: Guides

“Guide: Feature Team adoption maps”

“A feature-team adoption map is an important tool when you are adopting LeSS. It helps with the following decisions:

What is “all”?— A smaller LeSS framework adoption requires an all-at-once change to feature teams. Who is included in “all” depends on the scope of the feature teams?

Future improvement goals— The map can be used for setting future goals (…). These future goals frequently go hand in hand with the expansion of the Definition of Done. The map also shows the expected changes and their difficulty, as expanding beyond the current organizational boundary involves the hard work of “political” boundaries.

LeSS or LeSS Huge?— The scope of the feature teams influences the size of your adoption and can swing a LeSS group into adopting LeSS Huge instead. For example, a network-performance tool is a customer-centric product and its development-group size leads to the smaller LeSS Framework. However, when realizing it is always sold as an integrated part of a network management system changes the product scope and then is likely a LeSS Huge adoption.”

“Guide: Transitioning to Feature Teams”

“When adopting (smaller framework) LeSS, the transition to feature teams is all-at-once. But when adopting LeSS Huge, you can choose from several transition strategies. Which one is best? These simplistic steps help you determine the best strategy for your organization:

Determine Your Context: The transition to feature teams is influenced by several factors:

• Size of the product group— (…)
• The lifetime of the product— (…)
• Degree of component and functional specialization— More specialization makes feature-team adoption a larger change. Use the feature-team adoption map to draw the current state of component/functional specialization.
• Number of development sites— (…)

Determine your Transition Strategy: There are three broad transitioning strategies:

• All-at-once— As also used in LeSS adoption. (…)
• Gradually expand component team responsibility— You can plot the current state of your organization in a feature-team adoption map and mark future goals for expanding the scope of the teams. (…)
• Parallel organization— In this strategy, you keep the existing component team organization in place and gradually build a feature team organization next to it as a parallel organization.”

References

1. Larman, Craig; Vodde, Bas. Large-Scale Scrum: More with LeSS (Addison-Wesley Signature Series (Cohn)) (p. 73). Pearson Education. Kindle Edition.
2. https://blog.odd-e.com/yilv/2017/01/is-team-in-scrum-feature-team.html