Top 5 things to master when making Scrum work across time zones
Drastically different time zones do create a big challenge for Scrum. Scrum gains its effectiveness through synchronized and collaborative planning and preparation; therefore, coordinated Daily Scrums, Sprint Planning, Sprint Reviews, and Retrospectives are important. So Scrum depends on teams working in unison, which usually requires overlapping daily work schedules. If that is not practical, then the team would likely benefit by considering another framework such as Kanban or ScrumBan.
The Law of the Instrument is a cognitive bias that states:
“ I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” — Abraham Maslow, 1966
Scrum is the most common and popular Agile framework; but, it is not the only framework. If Scrum doesn’t fit, then that is not a failure of Scrum; instead, it is an indicator that you may have selected an inappropriate approach. Therefore, you should consider other options.
Scrum — Overlapping work schedules:
I work with a team where the PO, SM, and Tech SME are in the Eastern time zone, and the rest of the development team are in the India Standard time zone, 11–1/2 hours ahead. The team in India has shifted their work schedule to end at 7 pm and the US team has shifted to start at 8 am. We hold the daily Standup at 8 am Eastern to prep for the start of the day in the US and the next day’s work in India. When we run Sprint Review, Sprint Planning, and Retrospectives, the team in India works later but delays the start of their next day to compensate for the additional time. Consideration for the remote team members actually helps to keep these ceremonies focused.
I’ve also been Scrum Master to a team that was much larger, so we did not overlap everyone’s work schedules. Instead, the PO delegated some responsibilities to a local PO (Yes, this is allowed in Scrum!). The local PO worked adjusted hours that ended at 9 pm local time which gave her plenty of time to remotely participate in all the US-based Scrum ceremonies.
Kanban: Managing Work in Progress
Kanban is all about establishing a flow of work and continuously improving that flow. It is a highly visual process, so when working across time zones, an online tool like Jira or Azure DevOps is essential. The team’s priority is to optimize the flow of work (stories and tasks) through the development cycle. So instead of using Sprints, the PO queues up stories and the team pulls the prioritized stories from the backlog. They work the backlog items one by one, thereby creating a continuous flow of completed stories.
Kanban can be a more effective practice when working with distributed teams. It does require more focus on team efficiency — usually through regularly scheduled Retrospectives. Kanban works even better when the team has a working DevOps environment with automated testing and continuous build and deploy platforms. The team gains the most efficiency when manual activities are eliminated through automation.
ScrumBan: The Hybrid Approach
When Scrum practitioners first began to bump up against Scrum’s limits, many of them recognized that Kanban would be a big help. But how do we transition from Scrum to Kanban? In the process of creating different transition strategies, some discovered a “ Reese’s Peanut Butter Cup “ moment: they did not have to fully transition to Kanban in order to realize its benefits.
Using small iterations, on-demand planning, prioritization, and a visual medium (usually a Kanban board), teams can use the best features of both frameworks without disrupting the team’s rhythm. The Scrum features of planning, review, and retrospectives help to maintain consistent prioritization. At the same time, the Kanban features of WIP Limits, the Pull Principle, and continuous delivery allow for greater work flexibility.
These alternatives help to keep the team running efficiently, even when team members are spread across disparate time zones. I have seen detractors take a framework like Scrum out of context as evidence that it does not work. The reality is that Scrum is not, and has never been, a cure-all. It does not work in all situations — no framework does. So organizations are much better served by consulting an experienced Agile Coach who understands the strengths and weaknesses of different frameworks. That person can help to design strategies that match the organization’s needs and contribute to high-performing teams. (edited)
The law of the instrument, the law of the hammer, Maslow’s hammer (or gavel), or golden hammer is a cognitive bias that involves an over-reliance on a familiar tool. As Abraham Maslow said in 1966, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”The concept is attributed both to Maslow and to Abraham Kaplan, although the hammer and nail line may not be original to either of them.
Take the free Agile training course here
Originally published at https://anthony-software-group.com on May 6, 2022.
