Agile Scrum and globally distributed teams

Agile Scrum and globally distributed software development

Challenges and Solutions

Joseph Vargheese PMP CISA CSM

Date: 2013-03-30

(Currently looking for consulting opportunities within USA.  Please contact

  • Communication is the single largest contributor of the failure of agile scrum in globally distributed teams
  • Scrum is not optimal for globally distributed teams, but it works better than many other processes.
  • Scrum aggravates the challenges faced by globally distributed teams
  • Globally distributed scrum requires few  other  roles compared to traditional Scrum
  • Agile process knowledge still very limited in several of off-shore locations. Hence resources trained in agile process are also limited and very high in demand
  • Many global vendors are very comfortable in water-fall process where deliverable is highly predictable. Ever changing agile process brings disruption to that flow.
  • But even with all of the above Agile Scrum in globally distributed teams are here to stay because benefits outweighs challenges

 1.       Background

With wide acceptance of Agile SCRUM from Silicon Valley startups to every day software development, several organizations with globally distributed operations have already switched to agile or on the process of switching. This presentation mainly focuses the challenges of North American companies to do globally distributed software development in countries with 10-12 hours of time difference. Several techniques are listed in the article to resolve every day issues faced by these teams both off-shore and onsite. This article is based on practical experience of resolving different challenges.


2.       Off-shore and Near-shore teams

Software development teams from India, China, Russia, Poland and few others in the same region are generally referred as off-shore software development teams. Eastern Europe and South American companies also provide cheap software development solutions which are normally referred as near-shore teams.

3.       Not optimal but works well

It is not optimal to do agile development in a globally distributed team environment.  But benefits of the agile process outweigh the challenges faced compared to any other process like waterfall or RUP.

4.       Challenges and Solutions in a Distributed Scrum

4.1   Country based

Every country brings some natural challenges to software development. Agile by its nature of requirements like close interaction and communication within a team, aggravates some of these issues.

India and China brings the disadvantages of 10-12 hours of time difference with any of the North American companies. China and several others bring the disadvantage of English language.

But china has advantage over India and several others to do business in Japan, South Korea because of the language knowledge.

4.2   Communication

If an off-shore agile SCRUM project fails, single largest contributor of the failure will be communication due to 10-12 hours’ time difference between North American companies and off-shore development countries. North American companies having off-shores teams in Eastern Europe or South America have a better overlapping hours between both off-shore and onsite teams.

Some of the solutions are as follow:

i.        Video based meetings

ii.        One Instant  messenger  for onsite and off-shore staff

iii.        Overlapping working hours

iv.        Common sprint management tool including query escalation and resolution

v.        Automated daily status reporting

vi.        Shared source code repository

vii.        Common Build and deploy infrastructure

viii.        Share Drive

ix.        Shared Wiki for Information exchange

4.3   Resource Challenges on off-shore locations

Staff get selected in most agile development team’s is 1 in 5 interviewed. Most off-shore locations have very high demands for highly trained software developers and their low availability. More so in agile, it is better to select the candidates with better fit for agile process.

4.4   Team Layout Changes

Most effective team for agile off-shore development is combined off-shore onsite team 7 onsite and 5 off-shore. In my experience none of the other team layout are as successful as above.

4.5   Additional Roles Required

With the time difference there are additional role in the off-shore scrum team.

4.5.1 Off-shore scrum master

Senior member of the team assume this responsibility to resolve queries and status.

4.5.2 Proxy Product owner

There will be only one Product Owner in the team located generally onsite.  Off-shore should have equivalent proxy product owner role reporting to product owner. This role will speed up the development process

4.6   Additional Meetings  and Process Steps

Release planning (onsite)

Sprint backlog (combined)

Story pruning meeting (Add more details to excite meaningful discussion)

Sprint Planning (onsite)

Sprint Planning (off-shore)

Combined sprint planning (Off-shore and onsite)

Daily Stand-up off-shore

Daily Stand-up Onsite and off-shore together

Sprint Retrospect (Combined)

Burn down chart (Combined and/or separated)

4.7   Process Knowledge

Agile process knowledge is very minimal in several off-shore locations and many teams are learning fast. Besides China still lags overall delivery framework. Travel of resources both direction will help with this.

4.8   Agile contracts

Most off-shore units are run by vendors of the client organization of North American Countries.  Both vendors and clients like fixed process contracts whereas agile is ever changing and fixed price is not much of possibility rather T&M contracts are used.  It is overly difficult to commit deliverable within T&M

4.9   Onsite Knowledge Travel

Bringing people to onsite will speed up knowledge transfer and it is important to do onsite knowledge transfer to several of the key employees.  This also helps to attract right talent to the team.

4.10      Sending regular Ambassadors to off-shore

Occasional travel (Once in 6 month at least) is very important to build trust between onsite and off-shore teams.

5.       Opportunities

5.1   Low cost and reasonable quality

Lower cost and comparable quality are still reasons for outsourcing software development to off-shore locations.  Some arguably say the availability of man-power, which is difficult to validate.

5.2   Better overall results

In my experience overall quality for several stakeholders are good compared to the traditional waterfall fixed price projects. Often the entire project is executed on a lesser cost than waterfall.

6.       Conclusion

As mentioned earlier off-shore software development using Agile SCRUM is here to stay.  It is adopted by many development teams every day and early adopters are beneficial from cost advantage as well as earned value.


Roles and Responsibilities in Onsite Off-shore Agile Scrum

Roles and Responsibilities in Onsite Off-shore Agile Scrum Teams

(Joseph Vargheese PMP CISA CSM,

(Currently looking for consulting opportunities within USA.  Please contact

  • Role and responsibilities of offshore and on-site scrum teams are different.
  • Difference is mainly due to time difference and cultural issues.
  • Because of these differences sprint process requires several additional process steps to make off-shore scrum working
  • Proxy Product owner is almost a must for off-shore scrum team success
  • Product owner talents very limited in availability in many of off-shore countries
  • Strong, independent, self-organizing scrum teams will not be reality in the near future (there could be one-off)
  • To some degree, culture differences make it hard in creating self-organizing teams. But help is on the way.

1.     Introduction

Distributed agile teams are always a challenge to work together. Even more so when it comes to 10-12 hours of time difference to off-shore location like India and China. Absence of a product owner in an off-shore location makes very hard for an off-shore team to perform. But it is a reality that, these teams will have to be located different parts of the world due to cost reasons. The successful formula has to take different approach.

2.    Scrum work flow

  • Release planning (onsite)
  • Sprint backlog (combined)
  • Sprint Planning (onsite)
  • Sprint Planning (off-shore)
  • Combined sprint planning (Off-shore and onsite)
  • Daily Stand-up off-shore
  • Daily Stand-up Onsite and off-shore together
  • Sprint Retrospect (Combined)
  • Burn down chart (Combined and/or separated)

3.    What is different and why

Traditional off-shore work culture is very much adapted to water fall process, which includes well documented requirements and very well defined deliverables and contractual obligations controlling delivery components.

Agile comes with exact opposite of these requirements which makes it very hard for the team to operate. Some of the challenges will be as follows

3.1 Undocumented requirements

It will be difficult to conceptualize the business problem on a faraway off-shore location without strong domain knowledge. The presence of strong product owner with lots of domain knowledge can help to bridge the gap.


3.2 Work Culture

Generally off-shore has strong committed work culture.  Most off-shore location like India and china has very young work force with 1-5 years of experience. This young and dynamic workforce can contribute very well if fewer variants are placed on them.  Strong leadership is a necessity in that case.


3.3 Interaction Requirement

Off-shore teams are built mostly not to have many interactions because of time zone difference. Agile enforces that interaction.   This demands requirements of after-hours telephone connectivity as well as equipment to carry-out the work.


3.4 Process Structure

Off-shore teams are very familiar with strong process culture. Agile in essence is very lean on processes. Process ensures the quality even in the absence of strong leadership. Therefore off-shore agile teams require some amount of process.


3.5 Metrics

Off-shore teams are very familiar with performance metrics.  Defining and distributing those metrics can set goals for productivity, performance and thus overall improvement in sprint process.

4.    Off-shore Team structure, Roles and Responsibilities

4.1 Off-shore team structure

Dual-shore Teams Structure:

Dual shore team functions as one team at multiple locations with one scrum master and meetings with all of the members from different parts of the world.

Shared-Shore Teams Structure:

Shared-Shore team will have one scrum master; teams mostly function as multiple teams where daily standup area attended only by core members of team from multiple locations.

4.2 Roles and Responsibilities

Onsite agile catalyst:

This role is very similar to off-shore coordinator role in waterfall except responsibilities are different.  Agile catalyst is a member of off-shore team located onsite. His main responsibility is communication between teams and attending all team meetings from off-shore as well as onsite.  This resource will not have direct sprint task rather works reviewer of deliverables.

Off-shore proxy Product Owner:

This position is very confusing to several of agile teams.  But this is an important position for agile scrum success. This resource works very closely with actual product owner to understand product owner vision and then direct the off-shore team based on the vision.  One of the important point to note here is that this resource will not have any decision making capacity.  Ownership of every decision goes back to actual product owner only.

Off-shore sprint team:

Off-shore sprint team layout is very similar to onsite.

5.    Hand-off between onsite and off-shore teams

Hand-off is an important part of success of teams from multiple locations. Story acceptance to offshore sprint team to be clearly discussed on requirement standpoint as well as on assumptions made. Sprint planning is good place to clear those doubts.  As like in any environment, expectation management is an important part of the hand-off both ways. Daily stand-up is good place to reiterate the decision taken and most importantly assumptions not validated. Impediments and their impact have to be clearly discussed. Expectations on every deliverables have to be discussed.

6.    Cultural difference

Every country has cultural difference of its own.  Education, induction to work force, work culture is very different in many countries.  India and china are prime example of hierarchical work culture to some degree closes opportunity to voice bigger concerns, sometime even opinions.   Scrum requires open and honest opinions and discussions to take advantages of self-organizing team.  To some degree lot of times off-shore sprint teams have to put to test to question solutions and ideas floated by others.

7.     Strong Independent Agile teams, Myth or Reality

Rapid advance in collaboration tools and gaining acquaintance of work culture in different countries will make independent agile teams possible in few years.

8.   Conclusion

This discussion is to communicate that, scrum teams on an off-shore location is still a challenge, but can be done.  It takes lot of effort to make it work.  If not managed properly time in managing an off-shore team will eat into sprint tasks with in onsite team members.  Often some of best talents in the team will be pulled to solve problems from off-shore which also can create a team moral issue and of course productivity.

Practical Approach in Creating Agile Test Cases

  • Test case discovery happens throughout the sprint process.
  • Exploratory testing will uncover the hidden cases and expand to better coverage.
  • Overall, finding test cases in agile is a challenging process.
  • Definition of “done” of a story/feature is not clearly quantifiable.
  • Start with happy path and take following step by step approach to expand coverage.
  • Full step by step test case documentation is overkill, rather use summary test cases.
  • Most part, acceptance criteria defines the “done” for a Sprint story.


Identifying test cases in Agile is a somewhat difficult task.  In traditional waterfall or RUP, there will always be galore of documents to deduce this information from and in most cases every test case can be traced from some kinds of documented business/ system/ technical/ functional requirements.  Agile by its nature is very lean in documentation. This will create an issue in defining completion point for a feature distributed across several stories. This article defines the process of finding most test cases documented and undocumented with in a feature/story.

Step 1: Input points for test case scenarios

Traditional Agile scrum has following input points where test case scenarios can be uncovered. Every input provides different information. The list below is not conclusive.

  • Story documentation: Generally very slim.  Intention is to start conversation and get confirmation on requirements and definition of “done”.
  • Acceptance criteria for story: Talks about final intent of the story and definition of what makes story “done”.
  • Use cases /Requirement docs (if any)/UI specification (if any): Most cases use cases can be converted to test cases. Well written requirement will be very rare in agile stories.  If it exists, mapping every requirement to test case is an easy task.
  • Sprint planning discussion: Discuss almost all flows including happy path, alternate flows and exceptions flows. Discussion also includes boundary conditions, business rules, existing functionality changes etc.
  • Sprint standup: Discuss daily issues.  Always listen to change in flows as well as corner conditions.
  • Discussion with Developer/Product Owner: Works as a confirmation on numerous information received.
  • Sprint retrospect: Why test coverage is not enough for stories? Test case modification happens after the fact.
  • Exploratory testing: Testing through system without a specific test case.  This is the most effective method to find missing test case. This is method has been very successful with several agile teams.

 Step 2: Collecting Data

  • Tester is involved in all steps of sprint process. Following information should be sourced during all meetings in step 1.
  • Change in any existing functionality: This will results in modification/adding of existing test cases.
  • Happy path:  Tester will hear this several times during the process. Similarly alternate path/flow is also important.  Identify the number of alternate flows and make sure all flows are working.
  • Path of failures: Popularly called exception flow, flow terminated due to errors
  • Guard conditions: Example, login time out
  • Boundary Conditions: Also called as corner conditions. This will make sure that application will work for intended range of input data.
  • Business Rules: Group the business rules and test for one group at a time
  • Event based notifications: Any trigger point for any of the available functionality
  • Non-Functional requirements: Like performance or load of the system
  • Data mapping documents: Test cases can directly be derived from data mapping document.
  • Assumptions
  • Constraints
  • External Dependency: Is this dependent of any external interface for data pull or data push.

Even though all of these conditions (if exits) will result in test cases, every story will not have all of the above scenarios

Step 3:  Organizing the test cases

Since agile input points are many, it is possible that test cases closely related to each other will duplicate across locations.  Always organize test cases by functionality if possible.

Step 4:  Examining coverage

Most testers like to have 100% test coverage. Exploratory testing is the most viable solution to reach 100% test coverage. Since traditional RTM is missing in agile, acceptance criteria will also determine the coverage of test cases required.  Creating an “Acceptance Traceability Matrix” will help to cross check the coverage.

Step 5: Review

After completing test cases, always make sure to be reviewed by product owner or scrum master/developer.  Any coverage miss derived during the review process will be added/updated to test cases.

Step 6: Continuous integration from defects and enhancements

Product defects as well as enhancements will add/modify test cases. Defects generally indicates overlook of test coverage during the sprint testing.

More details contact author: Joseph Vargheese PMP CISA CSM,,