How to deal with losely coupled sub projects in Scrum?

Question

We are a project that for external reasons has to run in a Scrumish fashion. We consist of two subprojects : A backend data and services provider that I am a part of, and a UI+BPM layer that interacts with it.

The backend also serves a few other consumers and both parts are implemented in two completely separate stacks (by different vendors). The developers of either side are experts on the tool set of their vendor and have no knowlege about the respective other technology or functional design. It's to the point where we don't have the slightest idea what the others are talking about at the daily standup meetings and we are completely incapable of estimating stories from the other side of the aisle.

On the other we still have to release together, have a lot of points where we interact and sit in the same room. We have the same PM, PO and SM and some of the testers work both sides. In total we are 7-9 developers and 3-4 testers and a few other roles at the meeting each morning. We cannot easily be trained on the respective other stack or functional design, for budget, licensing and time reasons. So from a budget and project sponsorship point of view this is one big project whereas from the inside it is more likely two.

In the beginning we had our standups, review, retro and planning as one team but with separate refinements. After a while the discontent with the boredom at sprint changes led to the review, retro and planning being split into two different appointments and the sprints are now ending one week apart.

How would you implement something like scrum better in this setting? Is there a value in continuing to run an inclusive daily or should it also be split? If we keep it together how do we improve it? If we split it, how do we make sure the important interteam questions get addressed?

Answer 1

I would actually take a step back and ask the question - for your own satisfaction - as also of the team's - "Is there a problem?" and "What is the problem?", if the first answer is Yes.

Next, the question - "Why Scrum?" Even if there are external reasons, it might be worthwhile to see what will work better for the team. How can you make changes in the process to address specific problems you are facing, so that rather than look from the point of view "How can I implement Scrum better?", you can look at "How do I deliver software better/ faster? And the teams happier, less bored, more engaged and productive?" - and get the team to collaborate on solving that problem.

If this makes sense, then one approach I would suggest is to apply Kanban principles (visualize your work/ workflow, implement Pull and WIP Limits, and manage/ optimize flow) to improve your Scrum team's performance. It is possible I might be accused of using a "Kanban hammer" for every software nail, but I do believe your situation needs greater analysis and understanding before concluding that "doing Scrum better" will help you get to a better place.

Some specific things that the application of Kanban principles will do for you -

1. Help you manage the two teams' work in separate swim-lanes on a Kanban board and just provide an easy visual understanding to both teams of what the other is doing, how loaded they are, where the bottlenecks are, etc.

2. Since their delivery is decoupled, you can look at multiple options to sync. up, integrate and make customer releases in a cohesive manner, while providing opportunities to both teams to take up "intangible" work such as technical debt reduction. In the process, you might decide to change or remove an artificial time-bucket of 2 or 3 weeks that an arbitrary process definition imposes on you.

In the example shown below - each of your teams could drop code for integration at their own cadence and post-integration processes could follow at a business-required cadence. If any of the teams had any slack between release events, they could pick up work in the Intangible lane (technical debt) - and do those while waiting for the other team to complete their work.

Over a period of time, you might either continue to make releases in this manner - or move to a more continuous delivery model, if the cost (effort) of making the release is lower than the cost of waiting (opportunity cost/ time to market). (If you have not yet come across this approach (Scrumban/ Kanban), you might be interested in reading more on this here - "What is Scrumban?"

Answer 2

The situation

You describe the project as being very loosely coupled, and af they were two different projects:

• different team members, each team being highly cohesive (we vs.them)
• different technical stacks
• sprints ending apart
• different focus on requirements

On the other side these projects are very interrelated:

• the back-end user stories can't be conceived in total isolation of the front-end. This is why you have only one PO for both
• testing must be integrated, this is why some testers work for both.
• could the one exist without the other ?

In fact they are so interelated that there's a single PM, PO, SM and everybody outside the project seems to view it as one. There is no smoke without fire...

How to improve ?

Experience shows that having distinct teams not speaking to one another ends up in bad architecture problems. Integrated components need integrated design and mutual understanding.

Of course, boredom and waste of resources have to be avoided.

So start with the daily scrum. The daily scrum is 15 minutes and no more. That's at most 7'30" in which one half of the team could be bored. With the size of your team, it's 1 minute per teammate to speak. How could you be bored here ? And if there are changes or delays in one team, shouldn't the others know ?

So keep the common daily standup. But make sure it's 15 minutes and no more. If this is not achievable, organize a daily sub-team standup, in which you select the topics for the joint meeting, and make each 10 minutes. That's 20 minutes efficiently used per day.

Now sprint planning should go hand in hand, so that front-end get what it needs from back-end in due time. But each sub-team should provide the estimates for its own work. It's ridiculous to estimate the work of the other side: this would only make data unreliable, cause wrong decisions, and hence cause troubles. And in each planning, there are a part which is too detailed to be of general interest. This could also be done by subteam.

Review and retro similarly require a common understanding across the whole project, after a first discussion inside the subteams where it could be decided what to escalate.

What if it's still too long

I was heavily involved in large cross-functional projects, with usually 4 to 7 sub-teams. In this case, it's difficult to do frequent meetings with everybody. So the alternative is a cascading approach: Every team makes its meetings, and a representative of the team attends a global meeting (and give feedback of global outcome if it's different from expectations). However, this might be overkill in your current context.

Answer 3

If this is a long running project, split the teams. Yes, that's quite drastic. However, you yourself are already acknowledging that you're basically dealing with two teams:

how do we make sure the important interteam questions get addressed

Looking at the number of people involved...

we are 7-9 developers and 3-4 testers and a few other roles

... it should be no problem to create two teams. Scrum advocates no more than 9 people in one team. Yes, you're doing Scrum-ish, but still.

After the split, each team can have full focus on their respective products. You could still have the same product owner and scrum master for both teams. Having the same PO will make it easier to line-up with stakeholder expectations, as there's only one source of requirements.

Now for integrating the two parts. Yes, that will require some effort. From a technical perspective, a continuous build system which integrates the two parts would be great. Far more important, teams need to communicate, talk to each other and realign on a regular interval. Appointing a member per team to be the integration ambassador to the other team could be an option. Empowered teams will find a way to efficiently integrate their work with work done by others. They're already doing so, right?

If you find this hard, I'd recommend reading the Scrum Nexus guide. It's aimed at larger multi-team setups and may seem like overkill, but even for two teams the guide contains a number of great concepts for streamlining integration. You can always cherry-pick some ideas and experiment what works for your teams.