How to transform from multiple product teams to feature teams?
Difficult one. I guess.
I work for an educational publishing company. In the last ten years we build four seperate learning applications (different for primary education, secundary education, etc) and these applications are still very much in use today. In hence sight building seperate applications was a mistake because of further dev. coast, maintenance and not being able to react quickly to changes in the market. Above all, there's a LOT of functional overlap between the applications. Turns out that the learning and monitoring experiences don't differ that much between the educational levels. (disclaimer: this is a bit high level talk)
A new architecture was proposed -which really makes sense: Functional verticals (from back-end to customer facing functionality) instead of complete complex integrated products that enable us to be much more flexible. You can see these functional verticals as features. I hope this is a clear enough case to come to the real question...
Which is: How to transform from multiple product teams to feature teams? I am thinking about it a lot, but so far I can only see a really slow transition where you let the teams decide how to 'cut' the product in logical features and divide the features. But how to do all this when you don't want to disturb the day-to-day business to much?
Any advices is much appriciated. Thanks in advance. I will reply as fast as I can.
Mark
Why is having a product orientation seen as being contrary or counterindicative to having feature teams? It’s quite reasonable for feature teams to deliver minimum viable products, or MVPs, each sprint. The issue to be resolved isn’t moving from “product teams” to “feature teams”, rather it is minimizing and controlling integration dependencies.
@Ian, thank you for your reply! You got me thinking and you are right about this; the problem is that we aren't able to minimize and control integration dependencies - and therefor make too many costs because we build more or less same functionality several times (for each product).
The reason we are thinking in terms of feature teams is that we want to step away from having multiple products and move towards a platform that's usable by all our business units (primary, secundary, higher education). The platform must be adjustable to meet the specific needs of the business units, but by far most functionality will be shared.
This brings me back to the challenge here. How should I think about this transition from an organizational viewpoint?
Anyway, Ian thanks again, sometimes it's easy to take your eye of the real underlying problem.
Caveat: You gave us very little context, so be careful how much weight you give to our suggestions.
First, I'm hoping you intend to incrementally change the architecture, not all at once or as a parallel effort. Incremental is the Agile way.
Second, how experienced are these teams at Scrum? at Scaling Scrum? How many people in the effort are certified in Scrum? in Scaling Scrum? How experienced/certified are you?
The reason I ask is that what you are asking is a scaling question, and my advice would be heavily skewed by the answers to the above questions.