— New online course!  Getting Started with Azure DevOps — Special launch price 50% off —

Scrum vs. The Time Zone

by

I had a call from a prospective customer about a month ago — let’s call him “Bob” — asking for advice about rolling out Scrum at his organization.  It didn’t go well.  I guess I shouldn’t have been surprised that it didn’t go well because Bob started by asking pointedly, “are you one of those strict, dogmatic Scrum guys?”  The answer was and still is “no.”  (It turns out that Bob had contacted several other Scrum coaches in the Northeast US, discussed his problem, and since he heard the same answer each time, assumed “dogma.”)

Bob is a fairly senior manager at a large financial services institution.  Like most large institutions like this, their software development organization is geographically distributed across time zones and national borders.  Bob’s struggle is rolling out the Scrum process to the 4 or 5 teams he’s responsible for.  One of his biggest motivators is cutting out all the wasted time spent writing requirements documents.  Bob wants to be Agile and understands the benefits of favoring “working software over comprehensive documentation.” 
   
By this point in my conversation with Bob, I’m thinking that this sounds great and that it’s a fairly straightforward Scrum coaching engagement.  But then Bob drops the bomb — “my managers, business analysts, and architects are in New York and all my developers are in Bangalore.  How do I make Scrum work?” 

Ouch!  That’s hard.

Part of why I say that I’m not a “dogmatic Scrum guy” is that I (like many of my peers in the Scrum community) think less and worry less about whether you’re doing Official Approved Standard By-the-book Scrum and more about 1) are you delivering high-quality, working software and 2) how efficiently are you delivering high-quality, working software.  It’s “Acceptable Scrum vs. High-Performance Scrum.”  It takes practice and there’s almost always room for improvement.
   
High-performance Scrum teams have great communication.  Whether they sit in the same room or they do lots of Skype and instant messages — they’ve figured out how to communicate.  Most importantly, they’ve figured out how to communicate in real time.  If a developer needs to clarify the acceptance criteria for a PBI, that developer needs nearly immediate access to either the Product Owner (PO) or a Business Analyst (BA) who will have the answer.  If they don’t have fairly quick access, they either wait for the answer causing a potential delay or, worse yet, they build the wrong thing while they’re waiting for the official answer potentially causing waste and rework.  The ability to have lots of quick, informal interactions between the PO/BA and the developers is what allows you to break away from comprehensive, Waterfall-style requirements documents and go to the lightweight requirements that you see used by Scrum teams. 
   
Bob’s New York-to-Bangalore problem is deadly because the two halves of the team(s) are practically never awake at the same time.  Worse yet, standard business hours don’t overlap at all.  There is practically zero opportunity to interact during business hours.  This means that almost any question is going to take a minimum of 24 hours to get an answer.  Plus, when the two parts of the team do interact, unless one team is entirely composed of “morning people” and the other team is completely composed of “night owls”, no one is ever feeling mentally fresh. Someone’s always up early or up late.  Someone’s either just getting going with work and someone’s always just exhausted and ready to head home.  Scheduling those Sprint Planning, Sprint Review, and Sprint Retrospective meetings is going to be a trick, too.

New York business hours vs. Bangalore business hours. 

Apart from the time zone problem, this setup is nearly guaranteed to breed an “us vs. them” mode of thinking between the two halves of the team.  In Scrum, the Team should have all the skills it needs to deliver the required functionality.    Even though it’s supposed to be *one team*, it’s way too easy to describe it as the “US team” and the “India team”.  (For those of you who are following along and counting at home, that’d be two teams, not one.)

Bob’s options aren’t great.  He’s really only got one option: find a way to put the Product Owner and Business Analysts in the same time zone as the developers.  Not surprisingly, Bob’s New York-based crew wasn’t especially interested in moving to India and, even if the developers in Bangalore wanted to move to New York, the immigration issues would be beyond daunting.  His team members can’t communicate properly and, because of it, his group is going to have to keep on writing those requirements documents.  It’s not a “dogmatic Scrum” problem, it’s a shape of the Earth problem. 

That wasn’t the answer that Bob wanted to hear. 

(…and that pretty much wrapped it up for working with Bob.)

-Ben

 

— Looking for help adopting Scrum at your company?  Are you already doing Scrum but want to become one of those “high-performance Scrum” teams?  Drop us a line at info@benday.com


7 Responses to "Scrum vs. The Time Zone"
  1. Ben,

    I’d start by saying that there is nothing sacred about the 24 hour clock in scrum. I’ve worked with scrum teams with members in NA, SA, Europe, India, and Australia and it still works. We don’t use a day of work but rather look at each 24 hour period as a cycle of activities. We also combined as much technology as we could manage to make it workable for everyone. We have Jive as our internal async communications thread (over email), IM when the timezones cross, and an occasional early morning or late night teleconference.

    You are right to avoid the us vs. them. When we absolutely needed to talk then we alternated times so that no one group always got the ‘bad’ time. It is not perfect but it was workable.

  2. It’s a fairly common problem, and as with most fairly common problems there are fairly common solutions. In cases like this they usually involve time shifting, with one team or agreed representative(s) of the team working hours that overlap with the other team, taking turns with the other team so that they share the pain and feel equally important (like Rick said). Where the developers are located somewhere other than the BA then you could consider a proxy BA onsite with the developers who coordinates with the other one. Googling “distributed scrum” brings up a reasonable amount of advice.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: