Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

Some of the hallmarks of agile projects work best with a co-located team, perhaps all working out of the same bullpen where face to face interaction is the norm. In fact, some of the principles behind the Agile Manifesto underscore this point.

  • Business people and developers must work together daily throughout the project.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • The best architectures, requirements, and designs emerge from self-organizing teams.

As such, it possible to run an agile project when team members are located globally? Can a product backlog on a website make up for one in the room with sticky notes? Can conference calls with team members in a given time zone make up for a stand-up meeting with the whole team face-to-face? Can a team self-organize over e-mail?

Are there any recommendations for running agile projects with a global team or do the downsides outweigh the benefits?

share|improve this question

7 Answers 7

It IS possible. I've done an Agile project with 43 team-members across four time-zones. It wasn't easy, but it's possible.

Assuming your team is already fluent in Agile, as are you, you probably just need to know:

  • Communicate more. Way more. Call team-members more, check up on people more, and just keep in touch with people. You can't see them; email and phone is all you can do.
  • Use web tools. SaaS software (like GMail) is the best, because it's easiest to coordinate work across multiple people and timezones.
  • Co-Locate as much as possible. If you're not stuck with seven people in seven different timezones, try and bring people together into clumps as much as possible. That will mitigate the communication hit a lot.

I personally find (as many do) that working from home is a huge perk (for IT teams specifically), or working close to home. That's a great benefit to sell for virtual teams.

share|improve this answer
    
+1 for Communicate WAY more. Make sure you made yourself clear. When offshoring, you can't let margin for guessings. I'd suggest to lookup about communication: pm.stackexchange.com/questions/tagged/communication –  Tiago Cardoso Apr 5 '11 at 19:44

Is it possible? Certainly! Is it easy, not at all. A distributed team will never be as effective as a co-located team. A dispersed team is even more challenging. The tools recommended by ashes999 are some of the most important ones.

Others:

  • Consider forming the team in a way that each location has all of the skills required, and model the team more like two smaller teams.
  • Be aware the challenges are very different between a) having 4 people in the US and 4 in India or b) Having 4 people on the US West coast, 1 on the east coast, 1 in Russia, 1 in China, and 1 in India. Fully-dispersed teams have their own distinct challenges, and I recommend reading Matthew Heusser's writing at http://xndev.blogspot.com/ where he explores the challenges faced by SocialText.
  • Expect the problems and be prepared to work through them. It's very easy for frustration to be heard as browbeating, jokes to be heard as complaints, and so on. Be aware.
  • Be aware of Conway's Law and use it to your advantage. While it's not the best agile approach all of the time, structuring your team around the desired architecture can be powerful.
share|improve this answer
    
+1 - Thanks for the Conway's Law link. I do see that concept between different groups of people and the software they build. –  jmort253 Apr 10 '11 at 0:21

I'm answering this with respect to projects which have worked well using offshore suppliers, though these should be roughly applicable to in-house distributed teams or people working from home, too.

Make it safe to ask questions. A lot of suppliers and offshore developers feel like they can't show that they don't understand, particularly where requirements are concerned. Making it safe to communicate by being overly friendly helps. Send photos. Open video chat. Use the same IM. Make it easy to talk.

Establish clear tests for work. Use examples where possible. BDD scenarios are great for this, but even higher-level tests for capability, stakeholder goals etc. can be defined and have helped our offshore teams produce the right work, or define the right lower-level tests when offshore testing has been used.

Keep things which have never been done before in-house. Things which involve new aspects of a domain, process, technology or new people are risky, and aspects are likely to fail. It's easier to adapt to the failure when you can see it immediately. If only some of the developers are offshore, shipping the "boring" work can keep the more expensive onshore developers learning and exploring the risky areas.

Visualise the work. Either share an electronic tool, or point a video camera at the physical board. This helps make communication less about status updates and more about new issues, blockers and ongoing learning.

Hold daily stand-ups. Check that the offshore team is comfortable with the work, has the tools and access they need and know who to contact in case of difficulty.

Prefer video or voice to email or email will get clogged up. Ideally, email should just be a record of conversations or decisions so that everyone's in the loop. Make sure that everyone knows everyone else's name and has a photo so they can see a face; it helps make people more comfortable to reach out.

share|improve this answer

I have played with some 'spatial' tools for distributed teams since 2009. These can be 2d, or 3d like the tame 'the Sims'. I've watched how other companies use them too, and attended 9 conferences on the topic. I find these tools so useful I got a formal certification in this stuff (one year program, U Washington), and have 200 folks using this stuff for 2 years.

Most folks use a webcam to see facial expressions during meetings. I like tools that add a sense of venue or space. I get to see who else is in the context of the discussion, and some visual cues about how engaged they are. Adding iterative objects is also helpful.

1. Co-Locate?
Of course, if you can co-locate that's great. However, out of > 2,000 team members where I work only 21% have all their team members in the same building. 77% work at home at least some of the time.

2. Travel
Travel if you like. But I don't like the time I lose in airports (just got back from India - great to see folks, but 36 hours in planes and airports!!) Budgets are an issue, especially for international travel.

3. Traditional Webcam & Screen
A lot of tools do a mix of screen share, text messages, voice over IP, and webcam. I feel like I still lose communication context due to a lack of shared venue.

4. Two Dimensional spatial
Sococo is a 2d interface that supplies a spatial context. I like that for always on 'Osmotic Communication' for distributed teams. I designed a custom layout for my Agile teams. Sococo is easier to use than 3d environments.

5. 3d Immersive
3d tools let you 'immerse' more, or design and program some interactive objects. But they can be hard to use for newbies, are perceived as a game, and sometimes take expertise to modify the environments. Sometimes they are port hogs so can't get through firewalls. They let you do more, but is a much bigger culture change.

Bottom line:

  1. Webcam / screen share tools like Skype, Adobe Connect, GotoMeeting, Microsoft Lync, etc. Telepresence from Cisco gives you live size TV / webcam but is not cheap.

  2. 2d - Sococo

  3. If you are brave, 3d tools have some cool uses:

    • Terf Always on - great for collaboration on data,
    • VenueGen - setup a meeting for a fixed duration - great gestures for your Avatar" Avayalive engage

    • Advanced uses / Toolkits: 3DVirtual-Events, OpenWonderland (Java APIs), Jibe (JavaScript, C#, Boo), OpenSim (create objects dynamically at runtime)

    • Weaker recommendation: Second Life (expensive, branded for entertainment, but lots of content available for purchase), Blue Mars, On24, ProtonMedia,

I have some pictures and video examples of these platforms, but am a bit shy adding the link because i don't want to look like I'm spamming. I've used all these tools and approaches to do distributed since 2009, so please do let me know if you'd like more info! I hope I can save you some of the startup woes I hit.

Soft Skills
Don't forget the 'soft skills'. Beyond tools, we need to remember culture, timezone, language, basic facilitation, etc etc.

Infrastructure Tools
These tools compliment normal web based task boards / Kanban boards, which you can display as usual in your browser, or often inside the spatial context. Stuff like RallyDev, VersionOne, AgileZen, Trello, LeanKitKanban, SeeNowDo, Axosoft, Telerik, Sonic, RedCritter Tracker (which is gamified) are all key tools for those who can't gather around a white board filled with yellow stickies for their tasks.

share|improve this answer
    
Welcome to PMSE, Bill! Nice answer. –  jmort253 Oct 26 '12 at 19:48

Tools are your best friends in this situation, including (you can omit some of them in co-located team, but in distributed team their effective usage is mission critical):

  • Issue tracking systems
  • Version control
  • Code review tools
  • Mailing lists
  • Video conferencing (with recording!)
  • Wiki pages

24x7 open video Skype conference is really an option.

share|improve this answer

Running an Agile development shop between two offices located 12 hours apart was a challenge that actually created more opportunities for us to stand out as an organization. Here are a few things that we have accomplished as a result of being agile:

  • Improved communication:

We learned to use tools, like Skype, to facilitate face to face video calls. We talk with our overseas colleagues daily. This also led to us moving our contact center to an all-at-home model for our contact center agents, which resulted in lower turnover and increased quality of the employees.

  • Green initiatives:

Because of the lower commutes, we documented our impact on the environment. We've taken hundreds of cars off the roads and scaled down our main office in favor of work-at-home offices.

  • Independent Workers:

All of our employees are more well rounded and understand more about the core business model, which means we build better products that people actually want to use. We have a product backlog that developers work on in weekly sprints. They are responsible for gathering requirements and understanding the use cases prior to writing any code.

  • Stand ups:

Developers and project managers always meet face to face through Skype Video calls to discuss the project. We are also going to use a Google Site for each developer to document what he/she accomplished in the previous sprint, what he/she is going to accomplish in the coming sprint, and what challenges he/she is facing each day. The Google Site Announcements Template works like an intranet blog for keeping track of these Stand-ups.

Still, nothing beats a live call through Skype. It's free, and it encourages team members to collaborate and plan effectively.

In summary, this can be done with the right tools and the right people.

share|improve this answer

I've managed about a dozen projects over the years that have used Agile (and its forerunner - RAD) with offshore developers. It is hard work!

A few of the things that I would look to address include ...

First - common method. Don't let the offshore team use their own variant of Agile. Invest time and effort making sure everyone is calling the same things by the same name;

Second - put the right people in the right place. A core design team may be better placed onshore with the grunt work being done offshore. It might also be an idea to bring the offshore team onshore for a week or so at the early stages of the project so they can get to know the business and the people they're working with. Don't underestimate this;

Third -communicate clearly. Language barriers, misunderstanding, odd translations can all plague a project and limit its ability to deliver;

Fourth - and I think is pretty key - get someone offshore to act as a local Project Manager. They need to be ontop of things over there - but they shouldn't be making decisions, just ensuring that the team is working well.

I've covered this off in more detail in a white paper on managing Offshore Agile projects. You can download it from DalmenyClose.com

Managing Offshore projects is a huge amount of fun and very rewarding. You just need to keep your wits about you.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.