0

Doing my best to make this an "answerable" question and not just a discussion. While it might not be a perfect question, I think it fits the overall SO guidelines.

I'm looking for best practices (or the best I can find) for an Agile Sprint cadence with multiple teams in different time zones (PST & IST).

I'm new to this group and am managing several teams -- management and 3 teams are in PST, the remaining 4 teams are in IST. Our framework is Agile (utilizing Scrum and XP to define processes -- User Stories, Story Points, etc.). We use Azure DevOps and run two week sprints. I'm inheriting an existing cadence.

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.

If I could I would have our sprints run from Wednesday to Tuesday. Then we could do Retrospective/Review/Refinement on Tuesday (last day of sprint) and Sprint Planning on Wednesday (first day of sprint).


The existing cadence is: - Wednesday PM PST: Grooming/Sprint Planning - Thursday PM IST/Thursday AM PST: Sprint Planning (actually, a group coordination meeting -- as actual planning is expected to have occurred beforehand) - Friday PM IST/Friday AM PST: Deployment/Retrospective - Friday PM IST: Sprint Planning - Monday AM IST/Sunday PM PST: Sprint begins

The problem I'm encountering with this cadence is the IST folks are basically attending a "planning" meeting on Thursdays they're not ready for. They wait until after deployment/retrospective to do their planning, so aren't really ready to have that discussion until Monday, PST.

Another problem is the PST teams can't fully know what they're planning for, as the sprint is still in-progress. So any carryover stories on Friday immediately are impact the sprint plan they did on Wednesday. There's a tremendous amount of churn the first few days of our sprints as re-prioritization/re-planning occurs due to this.


What I THINK would be most ideal: - Each team does Backlog Refinement (after deployment/retrospectives) on Friday (last day of sprint). - Each team does Sprint Planning on the first day of the sprint -- Mondays. - Tuesday (evening IST, morning PST) have a Sprint Planning coordination/review meeting.

Pros: - PST teams will know the actual state of work because deployment will have occurred and they'll be able to plan more accurately. - IST teams plans will also be accurate when meeting with the rest of the teams.

Cons: - IST teams will have already completed two full days of the sprint before the coordination meeting (their Monday and Tuesday).


An option would be to have the PST teams do their Sprint Planning on Friday with the IST teams doing theirs on Monday. Then we could have the overall meeting Monday AM PST.

3

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:

  1. Have all teams work from a singular backlog, starting/ending the shared Sprint at the same time.
  2. Decouple delivery from deployment, allowing each team to work with a different cadence.
  3. 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:

  • PST: Tuesday to Thursday

    Sprint length and capacity are reduced to only encompass IST weekdays.

  • IST: Monday to Wednesday

    Sprint length and capacity are reduced to fit inside the PST time boxes.

This approach is arguably sub-optimal, but has two key benefits:

  1. It accommodates inflexible company policies about scheduling, work weeks, or delivery targets.
  2. 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.

  • 1
    You've given some really good thoughts for me to consider. I'm reflecting, meeting with one of my managers and will get back to you for more insight. But I wanted to at least acknowledge your answer. To answer at least one question, we're doing a scaled framework (essentially SAFe). – richardlpalmer Sep 30 at 17:57
  • By and large teams are not interdependent, although sometimes they are. At best, I'd say we have multiple interdependent teams. But if we consider their interdependencies as only exceptions, then I'd call them individual teams (5). – richardlpalmer Oct 2 at 21:17
  • All teams work from the same backlog (different Area Paths) and are on the same cadence. – richardlpalmer Oct 2 at 21:17
  • We're a team of teams. The policy is understood and generally agreed upon (makes sense organizationally even if we'd rather have a slightly different cadence). We are using a scaled agile framework (essentially SAFe). Your point about leveraging, "that framework's inter-team or intra-iteration integration process" might be hitting closest to the mark -- although it's not realistic to get the teams together to plan out increments of work. – richardlpalmer Oct 2 at 21:17
  • 1
    While there isn't a large technical reason, there is a business reason for needing the synchronization amongst teams. But decoupling the team's cadences is really the answer I think I was looking for. This decoupling is very possible and looks to be the solution. – richardlpalmer Oct 2 at 21:17
2

I think there are two answers to your question:

1) Different teams can absolutely have their sprint events at different times. There is no problem with this from a Scrum standpoint.

2) The challenge you are describing doesn't seem to make sense. If I know that my sprint ends on Thursday morning, I set to finish my work by then. There may be times that are more or less convenient, but I could decide the sprint ends at 3:47 on a Tuesday and I can work to that. It sounds like there is some other challenge that people are pinning on the Scrum events.

  • Hmmm, I see what you're saying. It's not clear enough. I'll add an edit to the post -- and of sprint (and subsequent deployment) is done for all teams Friday IST. – richardlpalmer Sep 27 at 22:44
  • I largely agree with Daniel (so +1), and admire his ability to express the core ideas succinctly. I have a more-detailed take on this that goes more into why, but I think Daniel's answer is essentially correct. – Todd A. Jacobs Sep 28 at 22:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.