Feature Teams vs. Product Teams? Organizational Implications of False Dichotomy.

This post is an extension of an older discussion and therefore, briefly, about the history:

Back in 2019, the Founder and Partner of SVPG (Silicon Valley Product Group), Marty Cagan wrote the post “Product vs. Feature Teams”, where he defined two types of teams: product and feature, and then compared-contrasted them.  He also contrasted them with the third type of teams: delivery teams. His writing had a lot of great content.  Later, the same year, the co-creators of Large Scale Scrum (LeSS) , Craig Larman and Bas Vodde wrote the post “On ‘Product Teams’ and ‘Feature Teams’ “, in response to Marty’s original post, giving their own perspective (also, shared by many LeSS coaches and trainers) on the subject and pointed out some weaknesses in reasoning (logical and terminology) in Marty’s original post (pointing out false dichotomy/binary), while still acknowledging that it was a strong post.

This post is NOT a summary of the above writings. Therefore, before you proceed reading the below, you are strongly recommended to read both original posts.

Instead, this post is an extension to the debated topic, a slightly deeper dive into the subject and reflection on practical, first-hand experience, working with a number of organizations (mainly, large investment banks, insurance and pharmaceutical companies) that, after being influenced by the “market trends”, started making a distinction between product teams and feature teams, in the context of their traditional organizational settings, well-known for their “agile terminology re-labeling” games.

Lets take a closer look at some of the most common omissions companies encounter:

 

Trivializing Scrum and Feature Teams

Rightfully, in his post Marty describes that majority of teams that companies use today are traditional ‘development’ teams or  ‘delivery’ teams.  True. Especially, companies that have gone down the path of SAFe adoptions, or any of its home-grown variations (e.g. internal SAFe-based “operating  models”), face this:

• Scrum is no longer viewed as a light-weight agile framework, used to build products and deliver business value to a customers/users, in short time increments. Instead, Scrum-butt, is something that traditional component/delivery teams try to imitate, by instituting Scrum events/Scrum playing roles/Scrum mimicking artifacts, while heavily relying on electronic tools (e.g. Jira, Rally, Version1, VSTS).
• A feature is no longer viewed as a small slice/piece of a product that is delivered to a customer at the end of each sprint. Instead, it is a ticket captured in a digital tool, at times, loosely called a ‘user story’, that describes technical work (component development or development phase). These, so called, “features” are not shippable, as they require lots of post-sprint integration work, through heavy coordination and dependency management, by multiple teams, with reliance on coordination and integration managers.
• A feature team is no longer a team that can deliver a real, customer-centric feature, while working across a stack of multiple components and/or technologies. It is a team that delivers on committed scope of work (so called “features”), described by a ticket in a digital tool. Most likely, such a team has a traditional reporting structure, limited skill-set and domain expertise. Creating “feature” teams does not require any major organizational re-structuring (flattening/de-scaling) and, therefore, does not challenge managerial status quo and sphere of control, and therefore this choice is often made.  Notably, organizations that are in pursuit of such ‘quick wins’, to meet year-end goals/numbers (e.g. “how  many agile teams have we stood up by year-end?!?!”) that are tied to compensation and bonuses, are frequently seen taking this approach.

To relate this all back to the original point: trivializing scrum and feature teams’ purpose, makes it easier for organizations to fake both and assign to their traditional processes and structures a trendy, populistic (also, very diluted) agile terminology. A quick win – AMAZING!

 

Trivializing Product Owner Role

While trivializing Scrum to the point that it becomes just a mechanism to produce output (not outcome), companies also trivialize one of the key Scrum roles – the role of Product Owner.  It is not surprising that majority of “team-level” product owners are, ex-BAs or ex-PMs that are responsible for output, ironically a.k.a. Team Output Owners (TOO).  These people are not empowered to control strategy, mission, vision, OKRs and budget.  They are usually found at the lower end of organizational structures, reporting to technology managers (R&D side) or program managers (business side).  This further drives towards the problem of local optimization, by single-function specialty and component teams that work for fake POs, on fake ‘products’ (really, just components), leading to unnecessary complexity in product hierarchies (e.g. so, called, sub-sub products, sub-products, product-families, product-lines, etc).

In his post, Marty does not mention the role of Product Owner.  This could be due to the fact that he has a lot of experience working with Silicon Valley product companies, where real, truly empowered product managers are in charge of action, setting strategic direction to teams that work on products, essentially, playing the role of a product owner, towards development teams.  This is my (Gene’s) good-faith assumption of Marty’s experience.  By the way, if this assumption is correct, then this line of thinking is consistent with LeSS recommendation on who would be the most suitable candidate for the role of product owner role in externally facing (external client) product development – it is a program manager.

Not surprisingly, if we read Craig’s and Bas’s response to Marty’s original post, we shall be reminded that properly staffed and empowered feature teams should be able to work on a large product, front-to-back, incrementally developing product features. Essentially, there should not be any distinction, such as: feature teams build features, whereas product teams build products.

On the other hand, if such distinction is explicitly made and the idea of it is promoted, for any large organization (bank, insurance, pharma), there is a [very] high chance that a feature team becomes a intermediate stepping stone/level in ‘agile maturity journey’, that a team goes through on its way to become a product team.  This is usually coupled with vanity metrics, measurements and other system-gaming elements.  Most likely, such weakened-by-definition ‘feature team’ will become an output-focused component team that works only a single product component, using Scrum, as a ‘wrapper’ to describe its ways of working (likely, optimized for speed of delivery, a.k.a. rate of output).

 

Relabeling All Ex-“P” Managers Into Product Managers

In Scrum, Large Scale Scrum (LeSS) and Nexus – used for small- and large-scale product-centric/customer-focused development, a product owner comes from business, where his/her day-to-day role is, most likely, a product manager (at least, at companies that build externally-facing products).  As mentioned above, this person will be in charge of strategy, mission, vision, OKRs and budget for a product.  In large organizations that have complex, multi-layered product management structures it very common to see business-side people being designated for the role of ‘THE Product Manager’, because they have a ‘senior X manager’ in their HR title, where X is one of the following: ‘project’, ‘program’, ‘portfolio’, etc. – a classic title-switching (relabeling).  None of them, actually, have a true product management experience or product vision or required empowerment. When these people are put in charge of providing a product definition, companies often end up with many interim, “inter-dependent” quasi-products that lack customer-centricity and remind, in essence, the aforementioned projects, programs and portfolios.  This further leads to having too many component/delivery teams and/or weakened-by-definition ‘feature’ teams, that need to align to quasi(fake)-products, creating their own private backlogs, while fulfilling on output requests, presented by a “team-level” POs (a.k.a. TOO).