This presentation will focus on the topic of working in a distributed agile team. We’ll go over terminology (remote vs near shore vs offshore vs distributed vs satellite etc) and I will share three different examples of distributed teams I’ve worked on and how we managed to be agile with our practices around pairing, knowledge sharing, and minimizing upfront design. We will discuss why the notion of distributed teams is becoming more and more relevant for modern organizations, what advantages and drawbacks exist, and what leadership needs to carefully evaluate when asking if distributed is right for their teams.

1. Agile Anywhere in the
21st Century
Setting Up Distributed Teams
for Success

2. About the speaker
Name: Rose Fan
Company: ThoughtWorks
Title: Lead consultant
Hats I Wear:
- Delivery principal
- Project manager
- Scrum master
- Business analyst
Location: Denver
Recovering road warrior

3. Elevator pitch
For the practitioner who is already familiar with Agile, XP,
and scrum practices
And who is currently working in or thinking about working
in a distributed setting,
This talk will cover real-world examples of distributed
Agile software development teams and observed best
practices within each variation
In hopes that the practitioner will walk away with an
understanding of what an effective distributed Agile team
looks like, and feels inspired to set one up him or herself.

4. My story
6 years at ThoughtWorks
Travel to client site Sunday
through Thursday/Friday
→ This is so inefficient.
→ We’re losing technical talent.
This is not a problem that is
specific to consulting.
Everywhere, there is fierce
competition for technical talent.

5. Remote leaders

6. Terminology

8. Single-site/onshore/co-located team
Everyone on the team is in
the same physical building
or campus.
Ideal: everyone working in
the same room. No cubes.
Ancillary roles are a few
steps away.

9. Multi-site
Two or more co-located
groups at separate
locations within a larger
team, perhaps with sub-
team boundaries and
responsibilities.
Example: a development
team that is split
between Chicago and
Dallas

10. Multi-site nearshore & offshore

11. Satellite work
Most of the team co-located, but a few members working
remotely, either from home or in another office.

12. Remote
A working situation where an individual is physically
located apart from others on the team.

13. Fully-remote/100% distributed
Everyone works in a separate location, usually from home,
and all communication occurs online.
Example: open-source projects

14. Distributed
Any style of working that is not single-site.

15. Distributed Agile -
an oxymoron?

17. Distributed is not, in it of itself, an
advantage
All else being equal, a single-site team will almost always
work more effectively than a distributed team.
In-person conversations are best way to communicate
among (most) teams, but cannot be prioritized
unilaterally as the only way to enable individuals and
interactions.

18. Intimacy Curve

19. Individuals and interactions
over processes and tools
Credit: Martin Fowler
prioritize getting the best
people
helping them work well
together

20. The turtle, the hare and the rocket
All else being equal, a given team will
usually work more slowly when
working in a distributed way.
But if distribution gives you
access to more capable team
members, they will be faster
despite not being colocated.
Credit: Martin Fowler

21. Think about the best person you
have ever worked with
How did you feel when you interacted with them?
Motivated, fortunate, inspired?
What would you do to keep working with them?
Switch departments? Switch employers?
Would you want them on your team, even if you weren’t
physically co-located?

22. People matter. Technical talent is
scarce.
The effect of even a single knowledgeable, capable team
member - usually in some sort of team lead position - is
contagious and can make or break the success of a project
- 10x programmer
Distributed teams are often used to minimize costs;
what if they were used to maximize talent instead?

23. Three Examples

24. Example 1: Multi-site project
● Greenfield web app for Dallas-based
Fortune 500 company
● Team of 8 in Chicago, 4 in Dallas +
end-users and business stakeholders
○ Same time zone
● Motivation for distribution: Tech lead
in Chicago unable to travel
● Coaching/enablement was a desired
outcome in addition to delivery
○ Continuous integration, pair
programming, automated tests
○ Sprint planning meetings,
retrospectives, prioritization

25. Tools used

26. Things that worked well
● Kicking off the project on-site together
● Cross-location rotations (minimum 1 week/month)
○ Bi-directional travel
● Core hours for pair programming
● Not splitting up functionality by location
● BAs and tech leads having at least daily check-ins
● Demos of new features by person who anchored on its
development
● Keeping a physical card wall in larger team location in
addition to a virtual wall
● Coaching and enablement via pair programming and
lunch and learn sessions

27. Challenges and considerations
● Majority drowning out the minority
● VPN, infrastructure blockers
● Disagreements about tooling, tech

28. ● Custom application for Fortune 50 organization based in
Cincinnati, Ohio
● Team of 8 in Cincinnati, 12 in Bangalore
● 10 ½ hour timezone difference
● Motivator for distribution: drive down cost and access
talent that was not available locally
● Delivery-focused; working to hit strict deadlines
Example 2: Multi-site offshore
project

29. Tools used

30. Things that worked well
● Two daily stand-ups that were equally uncomfortable:
○ 9 AM EST/7:30 PM IST
○ 9 AM IST/10:30 PM EST
● Features divided by region
● Some cross-location travel (>=2 weeks at a time)
● Greater emphasis on documentation and
asynchronous hand-offs
○ Wireframes, annotations
○ JIRA comments
○ Confluence for feature wikis
○ Recording meetings
● Treating ourselves more like two teams collaborating
very closely than one unified team
○ Ran team-wide meetings mostly separately

31. Challenges and considerations
● Time zone/lack of overlap
● English not everyone’s first language
● Influencing client’s perception of offshore team
members as not just doers, but to also consider that
team’s ideas and suggestions
● External barriers to travel (visas etc)
○ No luxury of spontaneous visits

32. ● Creating cloud-native training material and workshops
for client to run with their customers
● Team of 10 spread across
→ SFO (4), ATL, JFK, DFW, DEN, ORD, ACC (Ghana)
● Motivator for distribution: access to SME talent
Example 3: remote-first project

33. Tools used

34. Things that worked well
● Weekly retros
● Autonomy over tooling
● Freedom to work from wherever
○ Lower commute time

35. Challenges and considerations
● Time zone
● Motivation, learning of less experienced developers
○ Feelings of isolation
● Decision-making/tie-breaking among SMEs

36. Platonic Ideal

37. People
Team size in any location does not exceed 9 members (2
pizza rule)
At least one business analyst, product owner or proxy who
is empowered to make decisions in each location
One tech lead for the whole team; one dev lead for each
location
Credit: Pat Sarnacke

38. Communications (hardware)
Basic infrastructure must be present: internet, VPN
tunnels, etc
Videoconferencing screen (at least 32”) placed at eye level
- Microphone muted, speakers left on
Desk phones with auto-programmed numbers
Dialing in via landline by default
Credit: Pat Sarnacke

39. Communications (digital)
Group chat with channels and integrations
E-mail, distributed groups, reply-all culture
Digital card wall with just enough documentation
Remote-first communication even among co-located parts
of the team

40. Rotations
Rotations should happen regularly in both directions, with
plenty of lead time and notice
Business analysts/product owners should rotate regularly
between both locations
Other roles (QA, developers) should send a pair at a time,
ideally at least 1x/month
Credit: Pat Sarnacke

41. Daily stand up/scrum
Stand up conducted via video conference, ideally with
cordless microphone
Aim to keep to 15 minutes or less
- Walk the wall
- Informal tech updates and discussions happen after
stand up as technical huddle
- For large teams, consider splitting stand ups and
having scrum of scrums
Credit: Pat Sarnacke

42. Sprint ceremonies
Backlog grooming sessions, iteration planning meetings
over web conferencing
- Use screen sharing for the board/user stories and
make it unmistakable what’s going on
- Add a quick note to the user story to describe changes
or decisions
Showcases over video. Let both teams drive and let
individual anchors talk about the story or feature, if they
are willing.

43. Fun
Carve out time and budget for team events, especially on
rotation
Bring back and forth local food, souvenirs, etc
Suggest attending conferences together

44. Common
Mistakes

45. Abandoning pair
programming

46. Ignoring satellite workers

47. Not budgeting for
rotations
ahead of time

48. Staffing teams with
individuals who do not
actively want to
collaborate

49. Parting Thoughts

51. Comparison to single-site agile
teams, distributed agile generally
requires more...
● scrum master and expert coordination & facilitation
skills
● sharing by default
○ better to overshare and filter than leave parts of the
team in the dark
● documentation
● self-sufficiency and maturity

52. Mentorship to less
experienced team
members works best in-
person

53. Consider Conway’s Law

54. Distributed motivators:
autonomy, mastery,
purpose

55. Empathy is crucial to the
success of any distributed
project

56. The Agile manifesto was
written 15 years ago, when
a lot of today’s tooling and
technologies which enable
distributed work did not
exist.

57. Today, remote-friendly
tooling is being developed
and adopted faster than
ever.
Distributed work will only
get easier and more
prevalent with time.

58. Further reading

59. Acknowledgements
Martin Fowler
mfowler@thoughtworks.com
www.martinfowler.com
Patrick Sarnacke
psarnack@thoughtworks.com

60. The end - thanks!
@ruosifan
rfan@thoughtworks.com
P.S. ThoughtWorks is hiring!