Question about Integrations
I work in a hospital that has 3 major verticals: healthcare, pharmacy and billing/administration.
The idea is to have 3 SCRUM teams (one for each vertical) sharing the SM, but each with a PO and a Development team.
If a feature depends on an integration between a system from one SCRUM team and another from another team (medical care entails billing and in turn a new purchase of supplies), how should that be handled? Should the two SCRUM teams work together? Should their POs look after each side of the integration?
Thanks in advance!
The idea is to have 3 SCRUM teams (one for each vertical)
Shouldn't the idea be to have teams each of which has all of the skills needed to build a Done and immediately usable increment every Sprint?
It’s challenging to provide a definitive solution based on the limited information available in your question, but I can offer some guidance to help you determine the best approach. You mentioned organising the teams by verticals (healthcare, pharmacy, billing/administration), but it’s important to clarify whether these teams are truly product-focused or if they are functioning more as feature or component teams.
If these teams are more aligned with feature/component responsibilities and you frequently encounter features that require cross-team collaboration (such as the integration between medical care and billing, or billing and pharmacy supplies), then this setup might lead to frequent dependencies and potential bottlenecks. Understanding how often these cross-team dependencies occur is crucial to deciding on the best way forward.
Based on the scenario you’ve described, there are three potential approaches:
Option 1: Treat the verticals as a single product.
If the verticals are closely interconnected and the teams frequently need to collaborate on integrated features, it might make sense to view the entire system as a single product. In this case, adopting a framework like Nexus (https://www.scrum.org/resources/online-nexus-guide) could help manage the scaling and cross-team dependencies effectively. Nexus provides a structure for multiple Scrum teams to work together on a shared product backlog, facilitating synchronised sprints and shared goals. This is particularly beneficial if your teams often need to integrate their work, as it minimises duplication and enhances collaboration. However, be aware that Nexus requires more coordination and may involve additional overhead in managing multiple teams.
Option 2: View each vertical as a separate product with dependencies.
If each vertical functions as a distinct product with occasional dependencies, consider using Scrum@Scale (https://www.scrumatscale.com/scrum-at-scale-guide-online/). This approach allows each team to maintain its focus on its own product while providing a framework for coordinating and managing inter-team dependencies. Scrum@Scale is ideal when teams have distinct product goals but need a mechanism to align and collaborate occasionally. The trade-off here is that while teams can remain more autonomous and focused on their specific product areas, dependencies might not always be seamlessly managed, especially if they are more frequent than anticipated.
Option 3: Treat the teams as largely independent, with occasional collaboration.
If the teams are generally independent and cross-team dependencies are rare, then allowing each team to operate autonomously is likely the best approach. When dependencies do arise, the teams should leverage Scrum’s emphasis on self-organisation to collaborate and resolve these dependencies as needed. This approach requires minimal overhead and allows each team to optimise for their specific vertical, but it relies on effective communication and collaboration when dependencies do occur.
To help you choose the best approach, consider these questions:
• How often do cross-team dependencies occur?
• What impact do these dependencies have on delivering value to your customers?
• Are your teams currently able to manage these dependencies effectively?
By reflecting on these questions, you can better understand your specific context and choose the approach that will foster effective collaboration and maximise value delivery. Remember, the goal of any Agile framework is not just to organise teams but to enhance agility, collaboration, and the ability to respond to change.
Regardless of the approach you choose, it’s essential to remain flexible and be willing to adapt as you learn what works best in your specific environment.
Scrum is designed to have a single PO that is accountable for a single product backlog that is shared by the teams. A single product backlog gives one list of prioritised work items, else there will likely be competing priorities.