Scrum team is dependent on other team's work

Question

I'm working in a big project, where we're creating a standard software A for several customers and in parallel extending that software for one customer (software B). There are several Scrum teams. The teams, which work on A, are geographically and contractually separated from B teams.

Often we need to have something fixed or changed in A to complete our user stories in B. That causes a lot of friction, because we often cannot complete our planned tasks. We try to analyse user stories to avoid in-sprint dependencies on A, but when we discover a bug in A, we have to wait for the next sprint to get a fix.

Another problem is that we had to chose between long implementation cycles (sprint of A + sprint of B) or integrating mid-sprint deliverables with incomplete or buggy features. So far we've chosen to use mid-sprint deliverables, because we can continue our tasks faster.

Now we're rethinking our approach: How should we setup Scrum in teams, which depend on some other team's work? How can we reduce canceled tasks in mid-sprint?

Answer 1

Some ideas coming from working in the same environment:

Small Changes

1) Shorten the duration of iterations for team A so that they are required to ship product more frequently and in smaller increments. Shortening the iteration will allow for quicker response to changing priorities at a higher coordination cost. You're still doing scrum but basically marching towards CI and a more Kanban style.

2) Improve Team A's ability to promote to a staging environment frequently within an iteration. My last scrum team served lots of other teams with integration work. They started off having 1 big promotion to staging every 2-3 weeks where the integration could then be tested externally and consumed. With better prioritization, smaller stories, done criteria, and PO communication the same team was able to promote a release candidate every 2-3 days to staging. You're still doing Scrum, but it requires the team to have a very tight developing to QA cycle. Developers need to be able to write code on day 1 of the sprint and can't lose time clarifying requirements and story scope.

3) When dependencies arise, have members from team A attend team B standup when work is occurring in parallel. This will create a transparent dev-to-dev relationship and force a daily sync on the dependency at slightly higher coordination cost.

Big Changes

4) Merge team A and team B to deliver 1 backlog. Use something like a feature toggle framework to control which features are always part of vanilla and which features can be toggled on/off for certain customers.

5) Alternatively don't do scrum at all for Team A, do Kanban instead.

Answer 2

Make sure you are communicating. Make sure the Product Owners responsible for A understand the dependencies that B is relying on. Work with them to get agreement on prioritizing the items that are needed for the teams working on B to be able to make progress. If necessary, escalate this to whoever is in a position to care about both A and B succeeding.

Be more cautious in your sprint planning. If what you have described is a recurring problem, consider adjusting your process. Do not bring a story into a sprint unless you know that the dependencies from A have been addressed and that they are working as expected. If you are not sure, then bring in a technical spike to investigate. Depending on the outcome of the spike you can be more certain about the commitment to complete your task in the following sprint, or if the outcome of the spike is not positive, you'll at least know what needs to be addressed and can avoid that story until the dependency is fixed.

Have B help out A I've seen a similar situations where B was started while A was not actually far enough along. This led to the problems that you've described, and part of the solution was to have the teams working on B spend some amount of time helping the teams working on A (even if just addressing the issues that you run into). This will likely take a higher-level discussion, but it is likely a better use for your team than to have them constantly hitting roadblocks.