Why businesses need it, questions they ask and 7 principles for success. In the past 10 years, Agile has become the defacto method for cost-conscious businesses to build and launch beautiful, working software. Increasingly though teams looking to accelerate or scale operations are stymied by the scarcity of available technical talent. More companies are looking for staff out-of-state or even out-of-country to grow. The move toward distributed software teams begs the question, “Can they pair with Agile methodology?” Naysayers will argue no, citing co-location and collaboration as barriers. For teams willing to consider the potential, the savings extend beyond revenue gains and increased capacity. They revolutionize the business. With over 15 years managing distributed Agile software teams, we share how.

1. mentormate.com | 3036 Hennepin Avenue, Minneapolis, MN 55408 | 855-577-1671
Agile Software Development
with Remote Teams
Why businesses need it, questions they ask
and 7 principles to make it possible

2. Intro 1
Why do businesses today need 2
distributed teams?
Beat scarcity 3
Scale faster 5
Test safely 6
Jump-start evolution 7
Can Agile pair with distributed teams? 9
History 10
Frequent check-ins 11
Face-to-face interactions 12
Adjusted working hours 13
Table of Contents
What 7 principles distinguish the 15
successful distributed Agile teams?
Divide teams and members by feature not function 16
Distributed team org. chart sample 17
Pair 1 embedded leader from the host 18
business with 6 remote team members.
Provide your remote team meaningful work. 19
Choose a location where the adjacency 20
is sustainable for both teams.
Choose a location with a legacy in software development. 23
Abandon traditional working hours 24
Choose team leads carefully 25
References 27

3. Too oftensoftware projects built with offshore resources begin
with a corporate team stateside calling a meeting to solve a need. They
draft the requirements, choose a vendor, send the bloated spec
to a low-cost geography, clap their hands and await the final result.
Resources allocated, the team returns to business as usual.
Meanwhile, the vendor team begins executing on the spec. No
communication happens with the host team. No questions are answered.
When the development is delivered, it differs dramatically
from the expectations of the team stateside. If they are among the
lucky ones, it meets all the requirements. Likely, that too falls short.
This is the scenario most teams imagine when they hear “remote software
development”. Successful teams experience a very different reality.
Intro
1

4. Why do businesses
today need distributed
teams?
2

5. Why do businesses today need distributed teams?
Beat scarcity.
Business demand continues to outpace available technical talent. Companies today aren’t
content to identify challenges and add them to a list for future completion. We live in a culture
of instant gratification. Complex business challenges are no exception. The problem? The US
market lacks the volume of technical minds needed to quickly think through each solution.
The increased demand for developers, architects, quality assurance engineers and software
testers has driven prices higher than most businesses outside the top echelon of consumer
brands can afford. While some companies are attempting to “buy their way out of the
problem” and offer salaries far above the market average or add-in lavish benefits to attract
and retain talent, others, even top regional powerhouses, have begun to seek alternatives.
Even if a company can find the right people, they are usually in the wrong place and
must be relocated. Many companies aren’t willing to assume this cost so they end up
managing a distributed workforce even without offshoring.
A:
Q:
3

6. 9.8 million jobs
will be added to the US economy between 2014-20241
1 in 4
will be technical or healthcare-related
4

7. Why do businesses today need distributed teams?
Scale faster.
You need to grow your capabilities but maintain the same expense objectives. For
many businesses, adopting a distributed culture offers the only option to keep pace with
competitors who are willing to spend larger sums on development talent. To avoid adopting
an on/offshore model, it may seem like a viable option to simply work harder, smarter, faster,
better. It’s not.
Your team will only be willing to work 70 hour weeks and miss family commitments for
so long. Sacrificing your comparatively smaller team to meet business goals simply isn’t
sustainable. Eventually the talent you need to grow your business will begin to look
elsewhere — maybe to a competitor who has embraced distributed teams.
A:
Q:
5

8. Why do businesses today need distributed teams?
Test safely.
Remote teams are more risk-effective when exploring new ventures. Consider this scenario:
An enterprise has done preliminary research and decides to enter a market with a new product.
They choose to hire a software team to support the effort including a project manager, two
developers, a solutions architect, a designer and a business analyst. The project takes a year to
complete after which time it is introduced to the market. It fails. Suddenly the enterprise is
faced with a grueling decision: Find new work for the six team members, or let them go.
Alternately: An enterprise decides to develop a new project and re-allocates existing
employees. The outcome is the same. Only in this scenario, all the other projects
these team members were responsible for have fallen out-of-focus.
Distributed teams provided by a third-party offer the flexibility to spin-up a staff
augmentation team quickly or dismantle it with as much velocity and a far less taxing emotional
toll. It also protects the status of current projects and ensures they aren’t forgotten about.
A:
Q:
6

9. Why do businesses today need distributed teams?
Jump-start evolution.
Flexible staff offer a degree of separation needed to “shock the system.” Anyone
who has worked at an organization offering a technical product for a period of time has
likely observed a curious phenomena. The hostage taking of an enterprise by the very
people it employs. There is no violence and little discord, just a series of conversations and
recommendations that occur over time steering the business away from technologies
the employees don’t want to work in or learn. In this way, structures, methodologies
or languages considered current 10 years ago — might be vastly outdated in the current
technical climate. Initiative and innovation in the enterprise stalls.
Working with a team that exists outside the physical office space can introduce the degree
of literal and metaphorical distance needed to generate support for more current
tactics and thus educating current staff in the process.
A:
Q:
7

10. These challenges aren’t core to the enterprise.
Though, they are certainly felt by large businesses
most acutely. The need to source talent, scale up, test
and evolve affects all businesses with a development
team or development project.
8

11. Can Agile pair with
distributed teams?
9

12. Most businessesby now have heard of, attempted or
succeeded developing software using Agile methodology. In the past 10
years, Agile has become the defacto method of conceptualizing and
delivering beautiful, working software with shippable functionality in
two week increments.
Naysayers of using Agile with distributed teams will ask, “How can you run
Agile with one team in one place and the rest of the team in another? It’s
not like you can sketch on a whiteboard spanning the Atlantic.”
History
How can Agile distributed teams be
anything more than an oxymoron?
10

13. How can Agile pair with distributed teams?
Frequent check-ins.
Agile enables discussion around blockers and progress via daily and weekly ceremonies.
It’s true that “individuals and interactions over processes and tools” is a core tenet of Agile
methodology. It is realized through practices like co-location, pair programming and daily scrum
check-ins. Their inclusion serves to increase the number and quality of team interactions.
Daily scrums are a rapid-fire chance to call out blockers or report progress meaningful to the rest
of the members. Sprint planning and reviews are a time to prioritize tasks in scope or report what
works and what should be adjusted. Each ceremony is short or infrequent enough encouraging
even the meeting-averse to stay engaged.
The purpose of these ceremonies holds true for distributed Agile teams and is even more
meaningful — connecting team members that don’t share the same physical space each day.
Though, they are realized differently.
A:
Q:
11

14. Evolving technology makes frequent communication nearly seamless. The increase in
computerized call, video and messaging services have made it even easier. The options
to connect with remote team members are overwhelming in their ubiquity.
January 25, 1915
The first transcontinental conference call was achieved between San Francisco
and New York.2
Since then, business culture has made a more general move
toward distributed work.
No one will argue Agile works best with co-located teams. Though, other
efficiencies of distributed teams make up for accommodations made elsewhere
in the software lifecycle.
How can Agile pair with distributed teams?
Face-to-face interactionsA:
Q:
Oovoo JiraUberConferenceHangoutsGoogle ChatSlackSkype
12

15. How can Agile pair with distributed teams?
Adjusted working hours
Teams have been collaborating with each other across time zones for the better part
of 100 years. Even if businesses have never considered onshore/offshore work, chances
are they have worked with remote team members. Contractors. Agency teams across the
country. Employees who work at home on given days to accommodate childcare, health or a
variety of other personal reasons.
Agile project teams are already delivering work stateside. Businesses with offices on the
east and west coast are already navigating the distributed lifestyle — shifting working hours
to accommodate frequent meetings in different time zones.
A:
Q:
13

16. Distributed onshore software teams running Agile
build on the successful practices of stateside teams.
Offshore teams exaggerate the scale of each shift.
14

17. What 7 principles
distinguish successful
distributed Agile teams?
15

18. How should I organize my Agile distributed team?
Divide teams and members
by feature not function
There is a natural bent to structure teams within organizations functionally. Designers
reporting under the same leader, project managers, developers and on. Many teams assume
this same structure translates to working with internationally distributed Agile teams.
While this approach captures the reporting structure, it bears no relation to how work
flows during the project or how commitments are conceived and delivered. Internationally
distributed teams report more success dividing by functional delivery objectives with the
most important goal to group the developers and testers delivering on specific requests. In this
way, detailed stories and requirements can be given to the remote team to work on as well.
Rather than allowing designers and developers to work in a vacuum, this approach allows
all functional team members to ideate together and select a go-forward plan sympathetic
to both disciplines.
A:
Q:
16

19. VP
Engineering
Director of
Development
Developer
Feature Team 1 Feature Team 2
Tester
Technical
Product
Owner
Customer
Response Lead
Stabilization
Lead
Automation
Developer
Automation
Tech
VP Product
Strategy
Senior
Product
Owner
Senior
Product
Owner
Developer Developer
DeveloperTeam Lead
Scrum
Master
Distributed team org. chart sample
Scrum
Master
Team Lead Developer
DeveloperDeveloper
Tester
Technical
Product
Owner
17

20. How should I manage my Agile distributed team?
Pair 1 embedded leader from the host
business with 6 remote team members.
Finding the right leaders to connect the host company and the remote workers is the key to
successfully realizing an internationally distributed Agile software team. That way, the company
has an intimate pulse on progress and challenges faced by the remote team to reprioritize, trim
from scope or pivot directionally.
Most managers can comfortably connect with six direct reports.
Ratios of eight to one can be achieved with exceptionally talented managers.
A:
Q:
18

21. What types of projects should I send to my remote team?
Provide your remote team
meaningful work.
People are the same everywhere. They like to be challenged, and they don’t like tedium.
Organizations are only as strong and satisfied as their people are. When you first
approach the move toward Agile software development with your local team, they will
likely cling to interesting work and advocate sending the rest to the new team. Avoid
this. Embracing a mentality of shipping undesirable work abroad only serves to increase
attrition rather than boosting the bottom line.
Team turnover is a real concern ­— no matter the geography. Backfilling technical roles is
also the number one expense for development teams. Know that every member on
every team needs the same things — a mix of interesting work and an aerial view of the
impact their contributions will make organization-wide.
A:
Q:
19

22. Where should I locate my remote team?
Choose a location where the adjacency
is sustainable for both teams.
Stateside businesses sourcing a location for their remote team have several options to
consider from India to China, Chile to Bulgaria. Avoid the temptation to think in terms of
median salary alone when choosing a geography from which to source your team. Instead,
consider how the inevitable timezone adjacency will impact both workforces. Replacing
high-value employees who resign due to unsustainable work conditions ranks among the
number one costs for businesses reliant on technical labor.
Most teams opt to achieve 4 hours of overlap. Teams with an overlap of 2 hours can
succeed with efficient meeting time management.
A:
Q:
20

23. Let’s consider the adjacency between Minneapolis, MN
and New Delhi, India. New Delhi is 10.5 hours ahead of Minneapolis.
To achieve an overlap, US managers working with a remote team could begin work at 4 AM
when it would be 2:30 PM in New Delhi. They could achieve 3.5 hours of overlap until the
remote team leaves at 6 PM. The teams could overlap working schedules again at night for US
employees and early in the morning for Indian employees. The US team could sign on at 8 PM
when it would be 6:30 AM for the remote team.
21

24. Managing a schedule like this would require dramatically shifted schedules for either the host
or remote team. Other European locations (Bulgaria included) offer more overlapping work
time and sustainable schedules for both teams. If US teams begin at 7 AM, they can achieve
six hours of overlap with minimal inconvenience. Only by putting sustainability first can
organizations hosting a remote team decrease the chance for high turnover.
22

25. Where shoud I locate my remote team?
Choose a location with a legacy
in software development.
Some available geographies offer teams more than just the ability to achieve cost savings.
Rather they boast a deep well of technical expertise dating back over fifty years. Bulgaria
is one of these unicorns.
Bulgaria served as the Soviet center of technical excellence during and after the Cold War.
It’s established legacy of software development continues into the present with HP, IBM,
Microsoft and Oracle all outsourcing technical work to the Eastern European powerhouse.3
A:
Q:
23

26. Q: How often should I visit my remote team?
A: Every 6 months at a minimum.
How should I adjust the culture of my host company to
accommodate managers working with the remote team?
Abandon traditional working hours.
For some organizations, this will be obvious. For others, it’s revolutionary.
Managers embedded on remote teams will be responsible for making a number of
sacrifices related to their new roles. In return, a sacrifice must be made by the host
business, the abandonment of traditional working hours for these managers.
Flexibility and understanding will be critical in helping your new tier of leadership make
this shift. Don’t expect these embedded managers to work early and late in addition to
the typical office face-time from 9/5. Let them determine what will work best for their
sanity and their team’s productivity. It might mean you see them less. If they deliver
results, that’s OK.
A:
Q:
24

27. How can you maximize the productivity
of an Agile distributed team?
Choose team leads carefully.
Nothing poisons a project’s potential quicker than leaders who aren’t fully invested in the new structure.
These new embedded leaders are the lifeblood linking the strategic and development arms of your business.
They are the axis of new initiatives and decisions being communicated from both directions. They must be in
sync with managers on the remote team and decision-makers driving the change stateside.
There’s no denying, project work is taxing. Leaders looking for an excuse to fail won’t go the extra yard any
new structure needs to be successful. Blaming the remote team offers an easy out. Successful managers look
forward to working with others to realize the big goal. Leaders who embrace this mentality of collective
success are critical to establish on your remote and host teams. Managing fewer, larger groups improves the
chances you will find leaders comfortable working in the style you need.
Good managers assume responsibility for:
A:
Q:
• Daily communication • Work direction • Team structure
25

28. mentormate.com | 3036 Hennepin Avenue, Minneapolis, MN 55408 | 855-577-1671
POV
Teams crafting the best experiences for
remote and host teams don’t use a recipe.
Instead, they rely on a deep understanding
of their needs and the type of sustainable
lifestyle all employees require to thrive. We’ve
successfully managed distributed Agile
software teams for over 15 years.
Craig Knighton
VP, Strategic Consulting
craig.knighton@mentormate.com
Twitter: @MentorMate
www.mentormate.com
26

29. References
1
2
3
Hogan, Andrew and Roberts, Brian. (2015).
Monthly Labor Review. Bureau of Labor
Statistics, U.S. Department of Labor.
Retrieved from:
http://www.jstor.org/stable/
monthlylaborrev.2015.12.003.
http://www.computerworld.com/article/2874390/
this-1915-conference-call-made-history.html
http://www.zdnet.com/article/when-a-tough-histo-
ry-becomes-your-asset-bulgarias-plan-to-be-a-ma-
jor-force-in-technology/
27