This article explores what happens to a feature team that is part of a product group when product demand runs dry. In particular it is about the purpose of the team diminishing and looking what options there are for the team going forward.
Let’s assume that at some point in the past the product demand for a product resulted in the product group having grown large enough so that more than one team work on the product in parallel, each owning a coherent customer-value-oriented area of the product. An overall Product Owner works with a team of Area Product Owners that look after a number of teams each, and cover a specific area of the product. You might recognise this from the Large Scale Scrum Framework.
Suppose that the user demand for one of these areas has flattened and attempts to reinvigorate the product area (e.g. with new ideas) hasn’t resonated with the users for some reason. The team and their Area Product Owner are facing reality and feel this one product team is not in a position to deliver business value anymore. Let’s call this team “Horizons”.
In the product management team, the Area Product Owner has been keeping the Product Owner and the other Area Product Owners up to date about the situation. The Product Owner agrees with the assessment of the Area Product Owner and decides a change. This change could go into multiple directions.
Option 1: change product area
Another product area of the same product that Horizons worked in is growing beyond the sustainability threshold of the teams covering it. This is rather handy and an easy choice. “Horizons” simply moves on to join the other product area. When doing so they may swap a few Team Members with another existing team to get some knowledge seeded in.
Option 2: change product group
The organisation has another newer product that is maturing beyond what the one existing team can support and product demand there warrants the addition of another team. “Horizons” moves on to join the other product group. Again, when doing so they may swap a few Team Members with the existing team to get some knowledge seeded in.
Option 3: and now for something completely different
This is where it gets interesting. There is no other immediate product demand that “Horizons” could support. However the organisation is committed to retaining the team as a whole to benefit from their knowledge and productivity. Good on them!! The organisation have invested in the team for some time and benefited from some of the 2000x improvement potential of a team. So what are they to do then? “Horizons” is put on a quest. This quest needs to deliver customer-oriented business value. Well, again there are several ways this could go. The product management team will want to review team “Horizons”’ situation every iteration or so as they might want to sequence these sub-options until Option 1 and 2 become viable.
Option 3a: improvement quest
For a limited short period of time (say, 1 or 2 iterations), “Horizons” supports their original product group with bug fixing or paying down technical debt in some way. The reason for keeping this time-limited is that we want to avoid ending up with a ‘maintenance’ team. This would likely result in this team disbanding.
Option 3b: innovation quest
For a limited short period of time (say, 2-4 iterations), “Horizons” gets free reign, removing many constraints, and harnessing them as a greenfield innovation team. This may result in new feature ideas for existing products or validated ideas for altogether new products. The reason for keeping this time-limited is that we want to avoid ending up with an ‘innovation’ team. While in the short term exciting, many people like to see their ideas go live and in an innovation team, the team might end up doing prototype after prototype, many of which not seeing the light of day. Outside of the team, the fact that there is a team doing this kind of work, might inhibit organisation-wide culture of innovation.
Option 3c: Quest for the Holy Grail
Remove all shackles, as in, remove the constraints and let them figure something to do out for themselves. In this option I’m drawing inspiration from the old adage of self-organising teams, but also from Cynefin. In Cynefin there is the concept of a ‘shallow dive into chaos’. As guiding constraints, the team has it’s composition and the only guidance is that whatever they do, they ought to produce some value for the organisation. The contained enabling of a bit of chaos can surprise us with strong results. I’m fascinated by what team “Horizons” could come up with.
What do you think about this view? What other ideas for options do you have?