Scrum, DDD, and front-end development in an enterprise environment

Question

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?

Answer 1

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 ;)

Answer 2

I'm currently in the process of reading Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. I've read several other books on agile/scrum before this one, but one thing I find unique about this book is that author takes the agile process and extends far beyond a single team (100+ within organization)

This books points out that when there are many teams working on the same product, someone has to make a decision on how those teams are structured. The two approaches are:

1. Feature Teams - Team consists of members from different layers of the product (DB, Web, Business logic, etc.). And the whole team is working on a single feature.

2. Component Teams - Team consists of members who all work on a single layer. This team is especially preferred where same component is shared by many different features. To ensure that the code stays consistent you wouldn't want 20 different people modifying the same code base over and over.

The author points out that whenever possible, organizations should be leaning toward feature teams because when you have one team working on a full feature, everyone is aligned to delivering end-user value. If you only have component teams, you run the risk of each team performing local optimization, potentially at the expense of the feature itself. Furthermore since component teams only see part of a feature, now you need to have system-level integration/QA teams to assemble the components.

It seems that your management is taking the approach of making everyone part of a feature team. However, as the book is pointing out this decision should never be black and white. In the end, most organizations should have some combination between feature and component teams and structure them in such a way that benefits from having both are maximized. This needs to be a balance and there are many factors that would shift the balance toward one side or another (for example, absence of comprehensive unit tests would shift it towards component teams).

Having said all that, I think your management is going down the same path as many other companies which tried to go Agile only to fail miserably. I'm saying this based on this:

Management hasn't listened to us.

Traditional methodology has quite some overhead and when traditional companies move to Agile they introduce more overhead of the agile process without giving up the traditional way of doing things. The cornerstone of agile and what actually makes it tick is that you have engaged, self-thinking team members. And in the end the only way that is going to work is if THE TEAM decides that feature or component team would be a better fit and the management simply acts on THE TEAMS recommendation. Otherwise, why would you strive to deliver anything or work any harder than bare minimum when in your eyes the management already set you up for a failure by mandating a decision that you believe is wrong.

Answer 3

Domain-Driven Design has some interesting informations about how to recognize and deal with emerging team collaboration patterns. You might want to check out the section on Context Mapping about that.

...But the scenario you described has more to do with some organizational antipattern: DDD mandates to achieve an overall vision and to implement a sustainable way of collaborating between different teams in different contexts. At the same time Scrum would establish a coordination level between teams (with Scrum of Scrums, as said above) and also among POs. If there's no shared vision among Product Owners (be it implemented by a "super Product Owner" or by a close collaboration among the PO) ...you'll be very likely to deliver a visionless product.

Interestingly the other roles interested in applying a vision to a complex product are normally Information Architects and Interaction Designers which seem to have a hard time in the situation you described (but that's not uncommon in banking industry). Probably the best candidates to "glue" things together a little better are Enterprise Architects, which should be available in banking industry.