This site uses cookies and by using the site you are consenting to this. We utilize cookies to optimize our brand’s web presence and website experience. To learn more about cookies, click here to read our privacy statement.

The Agile Tester on a Distributed Team

The Agile Manifesto is a set of 12 principles designed to allow teams to be self-organized, self-sustaining, and focused on the most important thing: the work to be done.  It is viewed by many as a revolutionary change in how software projects are executed within the computer industry.  Implementing these principles, however, may be hindered by how businesses are organized.  Decisions made in boardrooms make the work in the Scrum room, and consequently the agile tester on a distributed team, far more complicated.

Take, for example, the three principles organized under Manifesto Statement #1: “We value Individuals & Interactions over Process & Tools”:

  1. Build projects around motivated individuals. Give them the environment they need and trust them to get the job done.
  2. The best architectures, requirements and designs emerge from self-organizing teams.
  3. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Now, think about each of these in the context of software development and testing organizations across the United States, Europe and Asia.  There may be many reasons why a Scrum team has personnel spread out around the world: financial, corporate mergers, marketplace alignment.  While it may make engineering sense for everyone to be together, it may not logistically or from the bottom line.  When engineering sense is overruled, all three of those principles are negatively impacted.

It is difficult enough to establish a sustaining environment for an Agile team in the best of circumstances.  Where does the team sit: individual offices, cubicles or an open room?  How do we network and access a data repository?  How do we synchronize schedules, deliverables, and documents?  What information security policies are required?  The answers to each of those questions, and many others, are far more complicated when the team is working out of multiple locations across the country, or around the world.

Geography also impacts how a team self-organizes and defines itself.  The structure of a corporate office in Bangalore, Guangzhou or Kiev may be very different than what is expected when one is only exposed to working in the United States.  Local management will often override the needs of the team when determining what is most important for an employee.  Cultural biases prevent some people from wanting to take ownership of their own tasks and direction, something absolutely critical when the team is trying to organize itself.

The impact of distance and time zones is obvious when considering face-to-face conversation.  How is face-to-face conversation more efficient and effective when the faces in question may be 10,000 miles and 10 time zones apart?

The easiest way to address these issues is through a consistent and widespread use of technology.  Most online meeting systems, like GoToMeeting and Webex, can incorporate the video camera built into new laptops.  The current generation of IM systems, such as Microsoft Lync, can do the same, as can the granddaddy of online chat platforms, Skype.  All of these applications can be run on any platform of laptop, tablet or phone.  The days of requiring expensive equipment and dedicated ISDN lines to video-conference between rooms in an office are long gone.  Distributed teams need to aggressively embrace the tools available to them to feel connected in a way that the traditional conference call cannot achieve.

Employees also must be more flexible in finding times to communicate and have more than E-mail exchanges.  Unfortunately, there are only four overlapping hours in the traditional “9 to 4” block of core hours between the Eastern and Pacific Time Zones.  Between the West Coast of the U.S. and Eastern Europe?  None.  Between anywhere in the U.S. and anywhere in Asia?  None.  People’s schedules have to give a little bit, adjusting to meet the team’s needs in one direction or another.  If it means having your team in Dallas have their daily standup at 7 AM local time, and the corresponding team in Mumbai stays to join the meeting at 5:30 PM local time…then so be it.

That team, however, needs the support of their corporate structure.  If that team starts early, don’t expect them to be staying as late, or being as productive later in the day, as others who arrived to the office 3 hours later.  Coffee and donuts for the early birds, or pizza for the team who stays late in the United States to interact with their morning counterparts in China or Australia?  What a simple and effective way to show the company recognizes the sacrifice they are making to remain inclusive.

If neither party in its entirety, either the distributed Scrum team itself or the larger corporation, are fully supportive of the adjustments that need to be made to overcome the obstacles blocking team integration, an individual team member (tester or otherwise) can take steps to connect efficiently.

  • Mix up the communication method: E-mail, voice, IM, Skype…use different tools for different needs. Something involved or details might require something in writing. But if you have a quick or simple question, a call might also provide a chance to talk a little bit about something else other than work, get to know the person aside from the Scrum teammate.
  • Lean heavily on the pronouns “we” and “us”, not “you” and “them”.
  • Take the time to learn how others prefer to handle their communication. Some people like to work in small, frequent bursts; others would rather you store a list and do it all at once. Communicating in this environment is hard enough as it is; do what you can to not make it worse.

In every aspect of a project, every Agile team member has to do their part to make things go as smoothly as possible.  As much as we strive for simple perfection in planning and executing per the Agile Manifesto…we value making things work in the real world more.