• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Agile and distributed teams

 
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How can we use Agile methodology, via SCRUM, with geographically distributed teams? be it with small or big integration style projects? What are the best practices to follow?

Thanks
praful
 
author
Posts: 46
Python VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My first thought is to have each team be independently agile, and avoid trying to be a single team across timezones and continents. So far, I've not seen "one team, multiple locations" work well. In fact, I've seen it fail when the two teams were only one hallway away from each other.

I think that you can have Scrum of Scrums and try to plan work in such a way as to minimize dependency, but you are going to be victim to conway's law or you are going to exploit it. Multiple products that integrate might work, but sharing one big project is not something I would bet on.

In a related topic, Jeff Langr and I recently spent time as remote pair programmers on a team that was centralized. We were able to use technologies to pair with the collocated team members, so we could do TDD together, attend meetings, and be regular members of the team. Technologies for doing that are always improving. It is best when you're not very much separated by cultures and time zones.
 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The distributed teams question is always an interesting one. We did one card, The Only Agile Tools You'll Ever Need, which ruffled a few feathers. Basically we suggested that moving in the direction of more distributed is moving in the opposite direction from agile values--primarily the value of "high levels of face-to-face communication."

Tim's right, there are many technical solutions that help. But recognize that you are making a concession to a sweet spot that can really work well, and the technical substitutes pale in comparison to just being there. The better answer is "shift your teams so they don't have to be distributed." One team in Dallas, one team in Krakow, one team in Bangalore, etc., instead of three teams each distributed across three geographies.

Agile aside, there are studies that show it takes years to obtain true positive return on investment with a distribute teamd. While the bean counters looking only at hire rates may quibble, it takes a long while and a lot of wasted effort to work through the inevitable issues of distributed teams (which do include quality).

As a remote guy for a year, I realized there were so many things I missed out on, to the point where I felt I wasn't as real a part of the team. It's also a lot harder to obtain consensus and enact lasting, positive changes in such a team.

You can make it work, and Tim provides a few suggestions. (Cameras are essential, and not just face-to-face cameras--you need to be able to see the teams as well in their work areas and in meeting spaces.) But is that really what's best for your company and product?


Regards,
Jeff
 
Praful Gupta
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the info and tips, shall put these together and run it by the teams, hopefully we will act in some direction.
 
Ranch Hand
Posts: 1211
Mac IntelliJ IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have done at least one distribted Agile (Scrum) project at my company that worked quite well (see http://www.xebia.com/distributed-agile). One of the critical factors that made Agile work for us was that the whole team was collocated for the first four weeks (2 sprints) of the project, and we kept on bringing the whole team together at regular intervals afterwards (1 sprint every 4 to 6 months).
 
Jeff Langr
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sonny Gill wrote:One of the critical factors that made Agile work for us was that the whole team was collocated for the first four weeks (2 sprints) of the project, and we kept on bringing the whole team together at regular intervals afterwards (1 sprint every 4 to 6 months).



Great point, thanks for adding it Sonny! Same thing--agile or not, it does boil down to building a good team that understands each other and can work together well. That's best done with co-location; the more, the better.

Jeff
 
reply
    Bookmark Topic Watch Topic
  • New Topic