So, I've been working for a bank for the past 4 years. My main responsibility has been online banking. Over the past year, we've been implementing the scrum methodology. We've also changed to domain driven design.
Now, my problem is regarding what management is planning on doing. They want to split the online banking team between the domain teams, so one developer from the online banking team will go into each domain team and work on online banking projects that are part of the domains. For example, if software development gets a project to create a new loan overview in the online bank, the loan team will handle it all the way from from database to UI.
My problem with this is that there is no focus on the online bank as a product anymore. There is no way to veto any new feature. The product owners in the domains can just dump any obscure new feature into the online bank that they want to. There is also no work happening to revamp core features that our users use all the time. Every project is to make something new and once it's release, developers have to start working on a new project immediately. There is no teamwork, each web developer has to work on a separate UI for a separate domain. No hardening.
Our suggestion to management is that the online banking team be it's own scrum team focusing on the online bank as a product. That team would have it's own scrum master and the online bank would have a product owner. That product owner would coordinate with the product owners of the domains and prioritize projects that have to happen in the online banks. If a project from one domain has higher priority than a project from another domain, he would explain to the domain PO that we have to work on the higher priority one first.
Management hasn't listened to us.
My question is, what is the right way to do this?
Best Answer
The approach you describe is what is commonly termed a Scrum of Scrums...except there doesn't appear to be collaboration between the teams in terms of integration. Without that, you do risk having a hodgepodge of features without any consistency between them. The transition might be noticeable and jarring to the users as they go from say managing their mortgage to checking their savings balance. Basically, you'll end up with a series of Silos with few of the benefits of either approach (Scrum or DDD).
That being said, it's tough to judge from a few paragraphs what counterbalances have been put in place to avoid this scenario. For example, if the Product Owners do regularly meet and collaborate on features and approach then hopefully, they will address the system as a unified whole and the separation of teams is really just for simplification from a management perspective.
I'd say, give it a chance you might find that they know more than they're letting on at first ;)