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.

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.