Feature Team


Such a team has no technical barrier to generate the functionality the customer needs


The concept of feature team

In the 60’s, Melvin Conway studied committees and made the connection between organization and architecture [Conway 1968] which has been popularized under the name "Conway’s Law":

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”

It is easy to see that organizations tend to produce Component Teams (CT) in particular because of [SAFe 2018-41]:

  • certain knowledge about a given technology
  • sensitive data and restrictions on their accessibility
  • reuse constraints
  • underlying complexity that only historical developers can understand

Unfortunately, these CT-based structures meet some issues such as [McGreal 2018]

  • sequential SDLC with complex interactions impacted by a VATI-like structure 
  • strong Dependency management, coordination and management due to the organizational structure
  • work on feature that have little business added value
  • hand overs that Passage de relais, scattering of information and significant accumulation of activities
  • the client and the globality of the project dissipate in the structure and end up being lost from sight
  • opaque measure of progress
  • Teams invent work for themselves when they are on hold
  • low quality level

All of these constraints justify a component-centric and API-driven organization with a dramatic drawback: the Product Owners (POs) on these teams end up with a relatively poor business vision and a Product Increment that needs to be integrated with a lot of other components and a staggered Waterfall-like deployment process “Development → Integration  → System Testing  → Deployment”, the A-shaped structure as the first drawback quoted above.

Note on Matrix Teams: Some may be compelled to create Matrix Team-based organizations. This model dates from the 1950s; such teams can assign temporarily some of their members to Scrum teams. This model poses a pitfall: the non-regular presence of a person for a recurring need will be a source of disruption for the estimation of velocity or the effective management of the WIP, especially if the resource is not immediately available, that which makes this configuration a bad idea in terms of flow [Larman 2010].

The thing is, when an organization starts, it is Customer-oriented and people arrange each other with their Way of Work (WoW) in a network-oriented approach to naturally maximize the delivery flow in an entrepreneurial state of mind [Kotter 2014]. As the enterprise succeeds, people's responsibility must become clearer to make things more visible, experts are recruited and departments created along with procedures to raise productivity and a hierarchy is installed. If Managers within the emerging hierarchy don’t know about Business Agility and its implications on how things should be driven on their part, the enterprise starts to organize by functions and silos appear everywhere. With the business, hierarchy continues to grow while the entrepreneurship continues and collides at some points, and every time, hierarchy will win [SAFe 2021-40]. This situation continues until a “Black Swan” appears and while Customers need a shift, the organization is stuck in intestinal squabbles. This situation is named “organizational traps” [Argyris 2010] and is due to two reflex models everyone has:

  • Model I: “defensive reasoning” - protects the individual from change
  • Model II: “productive reasoning” - prevents the counterproductive consequences of defensive thinking
Argyris’ models attributes [Moustier 2020] - Icons made by Freepik from Flaticon
Argyris’ models attributes [Moustier 2020] - Icons made by Freepik from Flaticon

This inevitable situation leads the company to an ambidextrous organization [Maier 2015] that mixes Hierarchy & Connectivity, Model I & Model II as per de Puydt’s “Panarchy” which proposes the coexistence of many governance models in parallel [de Puydt 1860][Appelo 2010] (which is not to be confused with Holling & Gunderson’s Panarchy).

Now, let’s have look at alternatives to those Component teams [Moustier 2020]:

  • No Team (NT): participants are self-organized, as in open source product development; ideally, they are holons (independent, autonomous entity) in a holacratic system [Moustier 2019a] [Mateleshkavo 2018] [Viðarsson 2017].
  • Private Open Source Teams (POST): this organization relies on the involvement of members in open source mode on some components. The members use a common component backlog [Ambler 2012] [Kniberg 2014-2]. It is especially useful when applied on business critical components and impacting several teams.
  • Product Teams (PT): they take charge of the entire development of the solution, including marketing and operations. The limitation of this operation is the size of the solution, which is necessarily modest in terms of the amount of functionality [Burm 2016].
  • Feature Teams (FT): they take responsibility for a few functionalities on all technical aspects, which makes the natural evolution of Product Teams when the solution becomes too rich for all teams to know the whole solution. FT are close to “I-Shaped” or “T-Shaped” teams as per the VATI model from the Theory of Constraints. It may be noted that these teams are, however, sooner or later subject to forms of matrix management but simultaneously [Rigby 2016] with cadenced, synchronized and incremental approaches with short learning cycles for better coordination.
  • Customer Journey Teams (CJT): this is an extension of the functionality teams that encompasses how customers use the solution, from identifying the problem to implementing new offerings, that make a difference in the digital environment [Burm 2016].

This ambidextrous organization may then be able to embed different Team structures to adapt to different situations and challenges such as the Team’s maturity towards Customer journey teams. This inevitable situation leads to the panachage of structures within the organization as per de Puydt’s Panarchy:

  • a few component-oriented teams,
  • a handful of private open source teams,
  • a good majority of teams organized around features, or around customer journeys for the most mature teams.

Since team autonomy is crucial to reduce delays, a feature team-based organization is unanimously supported regardless of the framework [SAFe 2018-41] [Ambler 2012][Larman 2010] [Larman 2017] [Kniberg 2012]; nevertheless, looking at the situations, advantages and disadvantages, the estimated long-term ratios are as follows:

  • SAFe finds it appropriate to keep about 25% of teams in component mode
  • DAD proposes similar numbers with 80-90% of teams in feature mode, to 10-20% in component mode and 1-4% in private open source mode [Ambler 2012]

Panachage of structures over time - Illustration from [Moustier 2020]
Panachage of structures over time
- Illustration from [Moustier 2020]

From a CT to more agile forms of teams, there are numerous transformations that should occur. To help this, the Definition of Done (DoD) is extremely useful and when the team is able to fully respond to the company's problem, in co-creation with technical partners likely to contribute to the solution  [Larman 2017]. As a result, FTs feel responsible for the quality of the product.

It is also possible to let a unique agile team start a component until its outcome is good enough to let other teams take ownership and sustain what has been put in place before the first team would “calcify” around that component [Leffingwell 2018].

Another option to transitioning from CT to FT and help culture change, you may [Larman 2010] [Moustier 2020]:

  1. Start from a CT and keep it for a while and spread the team members across existing FT (or more Customer centric teams)
  2. Share the Product Backlog Items (PBI) about the component between the existing CT and its former members
  3. Decreasing the CT size until it dissolves

When a Team transitions from a CT to a FT, in terms of Panarchy, it means the ecocycle of the Team and the Company are getting merged. This can be facilitated thanks to X-Teams.

Impact on the testing maturity

The term “Feature” on a FT holds two aspects

  1. Technology wise: such a team is able to handle the required technologies to provide the feature - this leads teams to raise the members to T-Shape people
  2. Business wise: To deliver the right feature, such a team gets closer from End Users and the Domain they deal with - X-Teams and Ubiquitous language should help embodying the FT state of mind
  3. Organization wise: sometime a feature makes sense across several teams, notably because the feature is wide or because not all teams turned to FT

The 3rd situation is the hardest to cope with and would look like this: say your system has different “Touch Points” (TP) (A, B and C in the schema here below), vertical applications that handle some parts of the objects the system manages. User Stories (US) in every team are obviously Customer facing and those TPs interact to fulfill a business case. Testers from C may require end-to-end testing with data flowing from A to B and to C. This situation forces Testers from C to know some of the features from B and A. 

End-to-end testing across several FT - Illustration from [Moustier 2020]
End-to-end testing across several FT - Illustration from [Moustier 2020]

To let C run their tests, they have different graduated options that should progressively gain some independence and then improve their flow:

  • Step 0 - C doesn’t know anything about A and B: C will mock B behaviours and data
  • Step 1 - C doesn’t know anything about A and B: C will require the help of other teams to discover and execute required actions
  • Step 2 - C is able to run some features from previous TP: C will run tests on his own on known features and will require the help of other for specific cases

While step 0 will involve at least Test Harnesses, step 1 and above require the X-Team state of mind. This step 1 will help C discover and learn how to play with previous parts, at least on the easiest and most common features.

Step 2 is a continuous improvement that progressively provides more freedom to C. This freedom may be brought with training, available documentation or even better, automated scripts that run required actions. All of those items are actually addressed with the social side of testability.

Agilitest’s standpoint on this practice

The immediate impact of FT with Agilitest is the integration of automation inside the FT, during the Sprint. This configuration pushes the Team to do everything at the same time, eventually merging the development / test automation ecocycles and building a task force around each US, doing some end-to-end testing as soon as possible. If test automation could not occur during the Sprint, Dark Launch will be most useful to avoid delivering low quality products.

When it comes to end-to-end testing across several FT, even if Agilitest is not designed for pure RPA, some of our Customers use the tool to automate some of their processes. This little tweak may be of some help to facilitate testability across multiple FT.

To discover the whole set of practices, click here.

To go further

  • [Ambler 2012] : Scott W. Ambler et Mark Lines - « Disciplined Agile Delivery - a Practitioner’s guide to Agile Software Delivery in the Enterprise » - IBM Press - 2012 - ISBN: 978-0-13-281013-5
  • [Ambler 2012] : Scott W. Ambler et Mark Lines - « Disciplined Agile Delivery - a Practitioner’s guide to Agile Software Delivery in the Enterprise » - IBM Press - 2012 - ISBN : 978-0-13-281013-5
  • [Larman 2010] : Craig Larman, Bas Vodde - « Practices for Scaling Lean & Agile Development - Large, Multisite, and Offshore Product Development with Large-Scale Scrum » - Addison-Wesley - 2010 - ISBN-13: 978-0-321-63640-9
  • [Larman 2017] : Craig Larman, Bas Vodde - « Large-Scale Scrum - More with LeSS » - Addison-Wesley - 2017 ISBN-13: 978-0-321-98571-2
  • [Leffingwell 2018] : Dean Leffingwell - « SAFe 4.5 Reference Guide: Scaled Agile Framework for Lean Enterprises » - Addison-Wesley Professional - 2018 - ISBN-13: 978-0134892863
  • [Maier 2015] : Jens Maier - « The Ambidextrous Organization - Exploring the New While Exploiting the Now » - Palgrave Macmillan - 2015 - ISBN 978-1-349-69577-5
  • [McGreal 2018] : Don McGreal et Ralph Jocham - « The Professional Product Owner - Leveraging Scrum as a Competitive Advantage » - Addison Wesley - 2018 - ISBN: 978-0-13-468647-9

© Christophe Moustier - 2021