TL;DR
Right now, you're trying to synchronize your teams without first determining whether they're really one logical team, two independent teams, or multiple interdependent teams. In my professional opinion, you really need to solve for that before determining the best way to proceed. That makes this a potential X/Y problem, for which the solution is always to re-evaluate X rather than simply chasing Y.
After re-evaluating your business and technical drivers, you have three basic choices:
- Have all teams work from a singular backlog, starting/ending the shared Sprint at the same time.
- Decouple delivery from deployment, allowing each team to work with a different cadence.
- Use continuous integration or another multi-team integration process to coordinate and collaborate on work independently of delivery/deployment cycles.
You can mix and match, but any successful multi-team approach will take elements from at least one of these options.
Fix Artificial Constraints
The managing organization has a strict policy around sprint dates, so our sprints are required to start on Sundays (effectively Monday) and end on Saturdays (effectively Fridays). There is one deployment for all teams and all teams kick off their sprints on that schedule.
Policies should have a purpose. If you don't understand the purpose of the policy, ask the management team! They set the policy, and should therefore be able to articulate how and why it's useful within your organization's unique context.
If you understand the policy, but find that it isn't working for your teams, then make changes to your process and your policy through inspect-and-adapt cycles until you gain the efficiencies you're looking for. Sticking with a sub-optimal process simply because it's the current process is about as non-agile as it gets!
Scrum is intrinsically a single-team framework. Unless you're using a scaled Scrum framework like Nexus or SAFe, forcing teams to work in lock-step is generally an anti-pattern because it creates depedencies and integration bottlenecks rather than real-world efficiencies. If you are using a scaled framework, then leverage that framework's inter-team or intra-iteration integration process.
Synchronize Your Sprints in Various Ways
A team (or teams) in multiple time zones can synchronize a shared Sprint by changing their preconceptions of the time box. If you have no other barriers to adoption, there's no reason why teams can't share the same core hours (e.g. both working the same 8-hour shift using GMT as a reference) or simply start/stop Sprints at roughly the same time across time zones.
For example, you could have both teams working 3pm-11pm GMT five days a week. Or have "core hours" from 10am-4pm PST (or IST) daily, providing crossover for several hours a day if teams need to coordinate.
If the teams don't have to actively collaborate, then teams can also simply share the same time box without explicitly syncing hours or days. For example, a weekly time box might look like this:
- PST: Monday to Friday (5 days)
- IST: Sunday to Thursday (5 days)
with both teams essentially delivering on Friday PST.
Alternatively, if the core hours or schedule can't be synced for whatever reason, then you can also achieve similar results by simply reducing capacity for one team or the other, or possibly even both. For example:
This approach is arguably sub-optimal, but has two key benefits:
- It accommodates inflexible company policies about scheduling, work weeks, or delivery targets.
- It makes the cost to the organization of inflexible policies visible to the Scrum Team(s) and senior management.
It's certainly worth considering a reduction in per-team capacity if other, more agile processes can't be implemented. However, unless "agile" is just a buzzword for your organization, it's always worth re-evaluating policies and processes as part of the agile practice of continuous improvement. Continuous improvement isn't just essential for Scrum teams; it's an absolute must for any organization that wants to remain competitive.
Decouple Team Cadences
Agile teams need to frequently (and ideally continuously) integrate work within the team, as well as cross-team work that is part of a coherent increment. You haven't actually articulated a business or technical need for cross-team synchronization, so maybe you don't need it!
If the teams can work from indepedent backlogs, then they aren't inherently tightly coupled with one another. Team PST could potentially deliver its stories separately from those of Team IST. Even if some work is sequential, e.g. Team PST can't plan Product Backlog Story B until Team IST delivers Product Backlog Story A, then the teams can simply factor that into the way backlog items are decomposed and when they are pulled into each team's Sprint Planning. This is mostly handled within each team's Backlog Refinement and Sprint Planning events, and it's ultimately the responsibility of the Product Owner(s) to adjust the priority of backlog items to reflect this decoupling.
If the work is tightly coupled for some reason, and the teams can't effectively slice the work up across team boundaries, then you decouple delivery from deployment using techniques such as feature toggles, rolling updates, or formal release cycles. In this model, teams deliver continuously during a Sprint, or at Sprint boundaries, but the work is not immediately deployed to (or enabled in) production until the cross-team feature is complete. This is definitely a more advanced set of techniques, and requires greater organizational and process maturity to pull off successfully. Nevertheless, this is a now considered a best practice by many agile and DevOps practitioners.
About Separate Integration Teams/Processes
Integration is often the first victim of decoupling, but this is usually the result of missing technical practices, poor tooling, or improper framework application. Whether teams are synchronized or decoupled, integrating work units during Sprints is the ideal.
Integrating within a surrounding process such as a Nexus, or through a separate integration cycle in some frameworks, are also options for teams that operate at scale. However, having external integration teams/cycles often involve a business decision to reduce per-team efficiency to optimize for cross-team flow.
You can't optimize a large system while simultaneously optimizing all its sub-processes. You can read more from Bob Lewis, who has been writing about this issue for years, but the truth of this is usually self-evident once an organization spends any significant time applying a scaled agile framework. It can't be done, so don't do it. If you want to optimize the whole, you often have to de-emphasize the efficiency of parts of the process. In a Scrum or scaled agile context, this often means reducing per-Sprint planning capacity for individual teams, or accepting integration work as drag on each team's delivery cadence.
You should definitely take a step back and consider the problem from a Lean process or whole-organization perspective. Once you factor in all the various business needs and technical drivers in play, the root cause and scope of your process problems should become clearer. After that, the solution space and the relative merits of each option will usually become self-evident.
