Heavy cross-dependence between teams
I'll try to keep this light of details if I can, but I wonder if anyone has some advice to share.
Imagine an online shop relies on two software products, which are different layers within the technical architecture of the website.
Both products have their own Product Owner and one Scrum Team.
Some features can be added/improved in each product in isolation, but others require the co-ordination of both teams in their respective products.
Many within the teams feel that this adds unwelcome complexity, and inhibits their ability to quickly get something to the customer.
Does anyone here have experience of a similar situation, or advice on how to resolve it?
Do the teams only work for this shop? If so, the software products could be perceived as components.
How are they currently working together in order to minimize the dependencies between them? Are they sharing a sprint cadence for example, with a joint goal to aim for, and is there an overarching Sprint Backlog where dependencies are managed and from which team Sprint Backlogs are formed? Are they using frequent or continuous integration to give transparency over the state of work?
Yes. Although I think they're generally seen as different products, you aren't the first person to suggest they may be components.
How are they currently working together in order to minimize the dependencies between them? Are they sharing a sprint cadence for example, with a joint goal to aim for, and is there an overarching Sprint Backlog where dependencies are managed and from which team Sprint Backlogs are formed? Are they using frequent or continuous integration to give transparency over the state of work?
Both sprint for 2 weeks and they start/end at the same time. There is one Sprint Review which involves both teams, because the majority of stakeholders have a stake in both products.
There's nothing like a shared Sprint Backlog or goal. These teams are structured very much as though they work on two different products, but they do work in the same room, and the reality is they do talk to each other to align work.
Continuous Integration is something that both teams are working towards. Primarily there is a focus on adding automated regression tests. But in reality, I don't think either team feels it is ready for CI yet. Releases typically occur every 4 weeks.
They need a shared view of their dependencies, and a joint backlog of what is in the current Sprint and/or being refined into upcoming ones is likely to help. To avoid complexity, you could think of this as a shared view or window onto their existing backlogs, and not as a separate artifact.
I’m sure they are right to put a focus on regression tests, as it can be hard even for independent teams to sustain development without them. However, continuous integration gives transparency over undone work in each increment, and achieving that state may need to be given a higher priority than it is right now, even if it means taking on less development work.
They need a shared view of their dependencies, and a joint backlog of what is in the current Sprint and/or being refined into upcoming ones is likely to help. To avoid complexity, you could think of this as a shared view or window onto their existing backlogs, and not as a separate artifact.
That's an interesting approach, and I can immediately see how that might be helpful. It's not the answer I expected, which I'm glad of, because it gives me more to consider.
I'd now like to add a bit more detail, because I think it's relevant, and I'd be interested to see whether that leads to different advice.
There has been a suggestion from some Developers that they would like to have teams with mixed skill-sets to work in both products, so a single team can complete an entire feature.
I don't see how a team working on two 'products' could work well within Scrum, so it has led me to wonder whether the issue ultimately lies in the definitions of products.
Given that there are two Product Owners, and there seems to be enough work to keep them busy, could it make sense to define two separate products that both cut across both code bases?
For instance, could a product focused around customers, and a separate product focused around internal users of the website, be a viable alternative?
Having mixed skill-set feature teams, each of which can wholly complete a feature, is generally the best way to reduce dependencies. Organizing by component or layer will usually lead to more cross-cutting concerns if a functional increment is to be built.
It sounds to me as if you have a product and a sub-product, in which case each ought to be represented by a clear Product Backlog and Product Owner. Assuming features align per product, so should feature teams.
What is my product, what are the boundaries of my product are actually not easy questions. It's worth a few brainstorming session.
It will probably give the teams some clues.
If you take the internal user approach. Will resplitting the union of current backlogs result in independent user stories that one team can deliver?
Does it make sense business wise to split vision of internal/customer parts of the shop?
Is the priority of developing both 'products' similar? Will it be beneficial to have fulltime teams on both?