Adapt Scrum for Multi-Product Program with Overlap
Hi all,
I'd like to see if anyone has any advice or experience to offer for the following:
There is a program which is comprised of 4 main products (call them Product A, B, C, and D). The products contain some overlap. This means that there are some applications, services, etc.. (call them what you wish) that are used by multiple Products.
This has led some program leads to think that forming cross-functional scrum teams, one for each product, would be inappropriate. They would rather have a Product Owner for each Product, and then a few Scrum teams (where a Product Owner is not associated with a single Scrum team). The Scrum teams would take ownership of the various applications, services, etc... based on what function they offer (ex: Signal Processing, UI, Infrastructure (whatever that means)).
From what I've gathered, this would mean the teams would not be cross-functional at all. Furthermore, I see some issues arising where each Scrum Master would be dealing with 4 Product Owners. I also don't want to even begin to think of the priority and dependency webs created between these teams. I can't help but think there is either way too much complexity here or something really misinformed. Perhaps I'm wrong and this approach has some merit.
Does anyone have experience with this type of program structure? Is there a way to preserve cross-functional, autonomous teams while not duplicating development?
I appreciate any and all input!
Here is a visual example diagram of what I am trying to describe:
Is there a way to preserve cross-functional, autonomous teams while not duplicating development?
Yes. Reduce work in progress and apply focus, which is one of the Scrum values. In this case, rather than trying to work on four products for which a simultaneous capability does not exist, work on one one product at a time. In each Sprint work will then be finished.
The first thing that comes to mind is if the overlap is truly overlapping. I've seen organizations try to build out libraries or services much, much too early and then what they thought should be a common library or shared service ended up either being split into multiple services, each associated with a single product, or turning into a mess because it tried to do too much.
If they are truly overlapping, then I'd suggest looking at opportunities to follow inner source practices. The four products may be built using Scrum, but the shared components would be treated differently and use a different approach. There are plenty of open source projects that can be used as models for governance, along with some companies using inner source techniques to maintain shared services or libraries. Unfortunately, I only have a theoretical knowledge of inner source work, and it may not be the right fit. If you did go down this work, you can allocate some capacity each Sprint to inner source development as a timebox.
Thanks for the ideas so far. As may have been apparent from my post, I'm quite worried about what my program might be getting themselves into. I don't want there to be massive priority battles between products and tons of external dependencies between teams.
@Ian Mitchell
Interesting idea to focus on one at a time and cycle through development on each. This would keep us more focused and help with priority and organization.
@Thomas Owens
I will have to read more about Inner Source. This is a cool idea though that I might be able to adapt.
I didn't see your diagram when I posted my answer, but something else to consider is looking at techniques for managing product-line development. If you can organize your Scrum Teams around related services and make it easy to instantiate products using those services, you may be able to have an interesting organization.
The last time I did Product Line development, there was a single (on the larger side) development team responsible for the core product with its own set of requirements and then very small teams that handled configuration, implementation, and integration of specific products in the product line. So it was a slightly different organization than you present, but it's not clear how many people you have and how the necessary skills are distributed, so I'm not sure if this approach would work for you.
@Thomas Owens
The diagram I posted is what I've heard from my program leads as a possible way they want to organize things. It's what has been making me nervous, because I'm not sure they know what they are trying to accomplish.
I appreciate the extra thought. It sounds similar to what we have: multiple products comprised of services where some services might be "plugged" into more than one product while some services are unique to just one product. Things on my program have not yet restructured (that's currently what is being discussed). How much is similar vs different is not info I'm too aware of, but judging by their ideas it seems like quite a bit is shared.
We have about 20 engineers, some specializing heavily in certain areas (like Signal Processing for example). From the diagram, it seems they would want the Scrum Teams to be organized by functional area (Signal team, GUI team, etc...). I've seen some Agile resources that advise against this, but perhaps it's not terrible if set up correctly from top-to-bottom (Product to Backlogs to Teams).
They've mentioned SAFe as well, but my experience is that SAFe requires a lot of additional planning in order to manage dependencies. If there's a nicer way forward, I'd like to help spare my program of needless dependencies by getting our Agile structure to work for us and not against us.
Thanks again for your replies. They've given me some nice things to think about more.