Loading ...
Sorry, an error occurred while loading the content.

US/India time zone difference and daily scrum

Expand Messages
  • hhroark
    We have some projects with a dispersed team in the US Central Timezone and Pune, India. This is a very large timezone difference with no work day overlap.
    Message 1 of 9 , Jun 28, 2007
    • 0 Attachment
      We have some projects with a dispersed team in the US Central Timezone
      and Pune, India. This is a very large timezone difference with no
      work day overlap. Does anyone have any suggestions for how to deal
      with the daily scrum in this scenario?

      Cheers,
      Hank
    • David H.
      ... Recording the Daily Scrum and making those files available to all has helped me with another team. Bringing some of the people from the team on-shore to
      Message 2 of 9 , Jun 28, 2007
      • 0 Attachment
        >
        > We have some projects with a dispersed team in the US Central Timezone
        > and Pune, India. This is a very large timezone difference with no
        > work day overlap. Does anyone have any suggestions for how to deal
        > with the daily scrum in this scenario?
        >
        Recording the Daily Scrum and making those files available to all has
        helped me with another team.
        Bringing some of the people from the team on-shore to make sure tacit
        knowledge is shared at once has helped as well.



        --
        Sent from gmail so do not trust this communication.
        Do not send me sensitive information here, ask for my none-gmail accounts.

        "Therefore the considerations of the intelligent always include both
        benefit and harm." - Sun Tzu
      • gsknan
        Hi Hank We have been doing this for more than two years now. I ve experience in working with teams from India and Teams from Pacific Time, USA as well as from
        Message 3 of 9 , Jun 28, 2007
        • 0 Attachment
          Hi Hank

          We have been doing this for more than two years now. I've experience
          in working with teams from India and Teams from Pacific Time, USA as
          well as from Mountain Time, USA.

          Our practices:

          1. Daily status report is shared with info on What was Done
          (Accomplished) , Plan for next day, Any hiccups for next days plan and
          Remarks

          2. A tracking tool is used (in our case JIRA) for issue (similar to
          product backlog)tracking. We do it with estimation for every issue at
          the beginning of a Sprint (week) and re-evaluation at the end of
          Sprint (Week).

          3. With these information in place for anybody to access and track, we
          take a conf call everyday with most of the team members participating.

          4. We work out an overlapping time of one hour every day. Say 8:00 AM
          to 9:00 AM PST with 8:30 PM to 9:30 PM IST. We, Indian team start the
          day late around 12:00 noon.

          5. In our case, Product Manager takes the role of Product Owner and he
          is there in every call.

          We could establish communication channels in a short period without
          much difficulty.

          In fact, I'm planning to write an article on this soon.

          Thanks
          SK
          --- In scrumdevelopment@yahoogroups.com, "hhroark" <Hank.Roark@...> wrote:
          >
          > We have some projects with a dispersed team in the US Central Timezone
          > and Pune, India. This is a very large timezone difference with no
          > work day overlap. Does anyone have any suggestions for how to deal
          > with the daily scrum in this scenario?
          >
          > Cheers,
          > Hank
          >
        • matt gelbwaks
          Hank, I have had experiences with separate efforts with partial teams India, Russia, Japan, and Argentina from both the US East Coast and the US West Coast.
          Message 4 of 9 , Jun 28, 2007
          • 0 Attachment
            Hank,

                I have had experiences with separate efforts with partial teams India, Russia, Japan, and Argentina from both the US East Coast and the US West Coast.  In the first three efforts, it really turned out that we had multiple teams doing separate scrums on the same iteration cycle.  We did the majority of our reviews and planning sessions together, but our retrospectives separately.  We tried to do overlapping work days, but someone was always working outside of their circadian rhythm and that, as we know is first - unsustainable, and second outside of the preferred agile norms. 
                When we found the option of working with an agile team in Buenos Aires, it was like heaven! There is a 7 hour overlap from the east coast and 4 from the west.  The language is much less a barrier than in some of the other locations and the culture very similar to at least my team's. 
                Although we were able to make the scrum of scrums concept work, I still don't feel we achieved optimal velocity.  Now with the 'near-shore' solution, I feel we are much more productive.  Rather than find ways to mitigate the constraint; we chose to relieve the bottleneck and move forward.

               Check out other locations if you have the option - that is my recommendation.

               m
          • Gleb Arshinov
            ... Hank, We work with similar time difference (10 hours), and Scrum meeting at 8:30am Pacific corresponds to 6:30pm EEST and that works OK. What kind of
            Message 5 of 9 , Jun 28, 2007
            • 0 Attachment
              --- In scrumdevelopment@yahoogroups.com, "hhroark" <Hank.Roark@...> wrote:
              >
              > We have some projects with a dispersed team in the US Central Timezone
              > and Pune, India. This is a very large timezone difference with no
              > work day overlap. Does anyone have any suggestions for how to deal
              > with the daily scrum in this scenario?

              Hank,

              We work with similar time difference (10 hours), and Scrum meeting at
              8:30am Pacific corresponds to 6:30pm EEST and that works OK. What
              kind of sucks is that this Scrum meeting effectively marks the end of
              the day for offshore developers. This is not ideal.

              Gleb
            • srinivas chillara
              I am not sure if a distributed Scrum team is a good idea at all! Why not have 2 teams (2 Scrums) at one at each location. Daily scrum (face to face) is a very
              Message 6 of 9 , Jun 29, 2007
              • 0 Attachment
                I am not sure if a distributed Scrum team is a good
                idea at all!
                Why not have 2 teams (2 Scrums) at one at each
                location.

                Daily scrum (face to face) is a very improtant part of
                Scrum, and diluting it will possibly result in reduced
                effectiveness. I suppose it'll be very very difficult
                to achieve hyper-productivity.


                regards
                Cheenie

                > --- In scrumdevelopment@yahoogroups.com, "hhroark"
                > <Hank.Roark@...> wrote:
                > >
                > > We have some projects with a dispersed team in the
                > US Central Timezone
                > > and Pune, India. This is a very large timezone
                > difference with no
                > > work day overlap. Does anyone have any
                > suggestions for how to deal
                > > with the daily scrum in this scenario?
                >
                > Hank,
                >
                > We work with similar time difference (10 hours), and
                > Scrum meeting at
                > 8:30am Pacific corresponds to 6:30pm EEST and that
                > works OK. What
                > kind of sucks is that this Scrum meeting effectively
                > marks the end of
                > the day for offshore developers. This is not ideal.
                >
                > Gleb
                >
                >


                Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php
              • Gleb Arshinov
                ... Distributed teams are suboptimal, no question. It s a little different for us -- Product Owner & management is in Silicon Valley and engineers are based
                Message 7 of 9 , Jun 29, 2007
                • 0 Attachment
                  --- In scrumdevelopment@yahoogroups.com, srinivas chillara
                  <ceezone@...> wrote:
                  > I am not sure if a distributed Scrum team is a good
                  > idea at all!
                  > Why not have 2 teams (2 Scrums) at one at each
                  > location.
                  >
                  > Daily scrum (face to face) is a very improtant part of
                  > Scrum, and diluting it will possibly result in reduced
                  > effectiveness. I suppose it'll be very very difficult
                  > to achieve hyper-productivity.
                  >

                  Distributed teams are suboptimal, no question. It's a little
                  different for us -- Product Owner & management is in Silicon Valley
                  and engineers are based in Ukraine. So, short of me moving to Ukraine
                  distributed Scrum is a fact of life. I do find it very useful for
                  developers to visit HQ here.

                  If you do have enough people to do it, having a team per location is
                  the way to go.

                  Best,

                  Gleb
                • Gleb Arshinov
                  ... And having a single location is best :-) Gleb
                  Message 8 of 9 , Jun 29, 2007
                  • 0 Attachment
                    > If you do have enough people to do it, having a team per location is
                    > the way to go.
                    >

                    And having a single location is best :-)

                    Gleb
                  • Venkatesh
                    Hank, I am not sure if there is any way to avoid the late night or early morning burn out meetings. But I have observed distributed teams trying out following
                    Message 9 of 9 , Jul 2 5:01 AM
                    • 0 Attachment
                      Hank,

                      I am not sure if there is any way to avoid the late night or early
                      morning burn out meetings. But I have observed distributed teams trying
                      out following strategy:

                      I have seen teams in India and US doing separate Scrum meetings locally
                      during their working hours, and on a regular basis (or on a need basis)
                      they do Scrum of Scrums(SoS). The teams update Wiki quite frequently
                      with impediments.

                      Teams conducting Scrum or SoS meetings between Indian and US teams,
                      generally stay either late in the night or come to work early in the
                      morning.

                      I have seen a variant of this, where the teams update Wiki or some tool
                      with impediments info. before hand. Both onsite and offshore teams
                      glance through the Wiki before attending the Scrum or SoS meetings to
                      improve the effectiveness of the meeting.

                      Venkatesh
                      http://agileworld.blogspot.com









                      --- In scrumdevelopment@yahoogroups.com, "hhroark" <Hank.Roark@...>
                      wrote:
                      >
                      > We have some projects with a dispersed team in the US Central Timezone
                      > and Pune, India. This is a very large timezone difference with no
                      > work day overlap. Does anyone have any suggestions for how to deal
                      > with the daily scrum in this scenario?
                      >
                      > Cheers,
                      > Hank
                      >
                    Your message has been successfully submitted and would be delivered to recipients shortly.