Here is a short post on a practical problem for my readers who use agile. My client is in Dallas, and most of the developers are in Poland. That’s a seven-hour time difference. We have enough overlap that daily scrums are not a problem.
“What I’m fixing to do today,” in Texas, comes at the end of the team’s workday in Poland. This is a little weird, but not a problem. Sprint planning is a problem.
With everyone in the same time zone, I like the rhythm of closing the sprint on Friday, doing the review, and then sprint planning on Monday. If your idea of “sustainable pace” includes working weekends, the team gets that weekend off. Then, we start Monday with a fresh scrum board. This is probably everyone’s favorite rhythm, if you have the luxury of cotemporal teams.
By the way, I write “cotemporal” here instead of “collocated” because it’s the time zone that matters, not physical distance. I know of at least one F&I company based in New York with developers in South Florida (an F&I “tech cluster” thanks to AutoNation and JM&A).
Replacing the initial eight-hour session with two separate four-hour sessions conducted over consecutive days is more practical.
With widely separated time zones, the problem is that you can’t leave the scrum board empty. Unless the next sprint is planned immediately, one team or the other will have a day with no work. So, we have adopted what Mike Cohn calls the two-call method. The quote above is from his book, Succeeding with Agile.
We close the sprint on Friday, do the review, and begin sprint planning with the Dallas cohort. We have the scrum master here, the product owner, and the lead developer. So, that’s a quorum. The downside is that the Polish team misses the initial discussion of the sprint goal. Cohn lists pros and cons in the book.
Relating the big picture falls to the lead developer, who conducts a second session on Monday during the overlap period, and develops the sprint plan. This approach doesn’t allow much debate over scope, so it places a premium on good stories with good estimates. For more on agile, read my post Sales Driven Development (or buy Cohn’s book).
Virag Consulting 