whitepaper: distributed agile - sqs · case study – offshore agile testing from south africa,...

Distributed AgilePointless or Possible?

sqs.com

Whitepaper

SQS – the world’s leading specialist in software quality

Authors: Julie Calboutin Senior Consultant

SQS Group Limited South Africa

Helmut Holst

Senior Consultant SQS Software Quality Systems

(Switzerland) AG Published: August 2013

Distributed Agile 2

JULIE CALBOUTINSenior [email protected]

Julie Calboutin has a degree in Computer Science and Physics and has been a Consultant at SQS South Africa since 2006. She has 17 years’ experience in software development and testing. Julie has success-fully delivered complex systems across multiple industries in multiple countries across Europe as well as in South Africa. Julie is also a Certified Agile Tester and South Africa’s second Certified Agile Tester Trainer. Julie’s primary responsibilities include test management, con-sultant coaching, and delivery assurance. This is backed up with the ISTQB Advanced Test Manager certification.

HELMUT HOLSTSenior [email protected]

Helmut has a degree in German Language, History and Political Science from the University of Lüneburg and has been a senior consultant for SQS for 6 years. During his time in the research and development group he has been instrumental in developing the learning zone modules for our methodology PractiQ. His achievement has been the develop-ment of a malaria data base for Africa under the medical council. He is fully bilingual and travels professionally between Europe and Africa. His practical experience includes banking, shipping, real estate and telecommunication. Helmut is a contributing member of the Test Management, Managed Services, Offshore, Global Delivery Model, Automation, Agile and the SAP innovation groups.

Distributed Agile 3

Contents

1. Management Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1. The Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2. Setting the Scene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1. Manifesto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. Market – Current Status and Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4. Agile Organisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5. Distributed Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.1. Common Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.2. Practical Guide to Succeeding in Distributed Agile Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.2.1. Communication Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.2.2. Additional Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.2.3. Onsite Coordinator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.3. Distributed Tools, Technologies, and Practical Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.3.1. Categories and Tool Samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.3.2. Practical Tools Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.4. Case Studies and Personal Experience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.4.1. Case Study – Mature Agile Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.4.2. Case Study – Offshore Agile Testing from South Africa, Utilities, 6 months. . . . . . . . . 16

6. Conclusion and Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7. Bibliographical References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Distributed Agile 4

Most of the significant challenges facing IT project management span the well-known triad of time, cost and quality. Growing complexity and increa-singly integrated solutions, in turn, exacerbate these challenges. In recent years Agile approaches have often been employed to meet these challenges. The core tenets of Agile, however, include colloca-tion and face-to-face collaboration – So how can the seemingly contradictory models of agile and offshore be combined to deliver the best of both worlds?

Agile methodologies and variations thereof have worked their way into projects around the world, and from those projects, the statistics have started surfacing. According to Scott Ambler’s Agile Adoption Strategies Survey 2011, collocated Agile projects are as successful (34 %) as near-collocated ones (34.5 %), which in turn are only very slightly more successful than those involving far-collocated (including globally distributed) (32 %) (Ambler and Gorans, November 2011). However, it is also becoming clear that an Agile approach does have advantages over traditional software development approaches. In fact, statistics show that the percentage of failures is decreasing: 55 % of projects recorded successes in 2010 while 63 % recorded successes in 2011. (Ambler S. W., 2011 IT Project Success Rates Survey Results, 2011)

Companies manage to work around the limitations of geographical space and time, and although they recognise that face-to-face collocation and collabo-ration is still the number-one choice and effective method of working, the overall benefits of reduced costs and the ‘follow-the-sun’ working hours approach associated with distributed Agile methodology seem to be paying off.

SQS has been involved in a large number of Agile projects, many of which have been successful in combining offshoring with Agile practices. This whitepaper will present a number of the lessons learnt from these engagements and share some of the practices which have led to successful off-shoring within an Agile model.

1. Management Summary

Distributed Agile 5

VALUES

VISIB

ILIT

Y2.1. The Challenge

Agile is still a relatively new development methodo-logy, but one with significant global traction. It is increasingly proving a popular and viable approach to software development. However, quite a few of

these companies also partake in distributed-team and offshore models. Due to the interactive and collocation approach of Agile, the big question that arises is: ‘Can an Agile approach be successfully applied to distributed teams?’

2. Introduction

Figure 1: Agile Software Development Methodology (Wikipedia)

Agility is ...

Agile Development

Accelerate Delivery

Continuous

Daily

Iteration

Release

Strategy

Adaptability

Burndown

Velocity

Burnup

Tests

Transparency

Simplicity

Unity

BuildTDD

Integration

Collaboration

Refactoring

Standup

Review

Iteration Plan

Release Plan

Backlog

Vision

Goals

Charter Funding

Retro- perspective

Estimation

Acceptance

Working Software

Distributed Agile 6

Agile processes have been implemented on a number of split site models, but it is possible to question if this is true Agile or just an adapted iterative approach. Regardless of the answer to this question, the solutions presented in this paper certainly honour the Manifesto for Agile Software Development: ‘We are uncovering better ways of developing software by doing it and helping others do it.’ Out of the entire manifesto, including the ‘12 Principles’, distributed Agile clearly violates only one stipulation: ‘The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.’ But if one out of twelve principles can invalidate a whole methodology – the name of which by definition means quickness, lightness, and ease of movement – then we are in more trouble than we think. Additionally, Agile should be seen as a journey rather than a destination – and as such offshore Agile is just another route to explore.

2.2. Setting the Scene

SQS has a long history of both Agile and offshore test service delivery, and we are continually looking for ways of building delivery models which offer our customers workable, innovative solutions which provide competitive advantage. Agile offshoring is a natural example of this and is driven from the adaptable, benefit-focussed approach of Agile and the cost-saving, efficiency drive central to offshore delivery.

2.2.1. Manifesto

The formulation of the Agile movement occurred in 2001 (Highsmith, 2001) when a variety of ideas and approaches with similar objectives were unified under the umbrella of a common set of high-level goals and values. These goals and values are embodied in what has emerged as ‘The Agile Manifesto’.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Definition 1: Manifesto for Agile Software Development (Beck, 2001)

Distributed Agile 7

The adoption of Agile methods is certainly a notice-able trend. According to a report from Klocwork (Landry, 2010), Agile methods have overtaken Water-fall as the development methodology of choice. This report, which cites information gathered from a Q3/2009 survey of IT professionals, states that 35 % of respondents said that Agile most closely re-flected their development process, while Waterfall processes came in at only 13 %. Many companies use both traditional and Agile methodologies in separate projects (for reasons like trialling Agile on smaller projects or because they fit the project style) and so practice a cleaner separation of ap-proaches. Thus, while most organisations are not completely Agile today, almost all of them will have some groups that are.

It ought to be kept in mind, though, that in many cases Agile has grown out of traditional approaches (Waterfall, V-Model, etc.), with projects often just adopting aspects of Agile that work best for them, as opposed to planned transitions to an overall, fully Agile approach.

The more common aspects of Agile that are easily implemented in combination with traditional ap-proaches are daily stand-up meetings, iterative processes, sprints, and reduced documentation. All of these aspects lead towards reduced cycle times of development, increased communication, and more frequent inspection of deliverables.

On the other hand, the gains associated with switching to Agile methods become clear when considering studies on the success of organisations that have fully transitioned to Agile. For instance, Agile expert Scott Ambler conducted a study on Agile Adoption, including the question “What

benefits, if any, do you believe your organization has gained from its adoption of agile? - Operational (post-delivery) effectiveness?” the results of which are shown in Figure 2.

Figure 2: Organisational gains of Agile transition (Scott W. Ambler + Associates, 2008)

In addition to the adoption of Agile, another trend has changed the way software projects are under-taken: offshoring work to dedicated offshore centres in Africa, Asia, or South America has provided at-tractive cost savings due to reduced cost of labour. As a consequence, many IT projects currently have to cope with adopting both approaches at the same time. According to the VersionOne survey, of the 6,042 respondents, a full two-thirds (65 %) said they had distributed team members working on Agile projects. The following section will highlight key challenges of distributed Agile and lessons learned from successful distributed Agile projects.

3. Market – Current Status and Outlook

Improved

Much improved

No change

Worse

Much worse

Don’t know

1 %3 %

6 %

48 %

22 %

20 %

Distributed Agile 8

One way of organising the twelve Agile principles is to consider them in four distinct groups:

1. Teamwork

2. Customer Satisfaction

3. Quality

4. Project Management

Although it is not necessarily seen as the number one priority, teamwork is especially critical to the success of Agile projects. Creating good products requires cooperation among all the members of the project team, including customers and stake-holders. Agile approaches support teambuilding and teamwork, and they emphasise trust in self-managing teams. A skilled, motivated, unified, and empowered team is a successful team.

Agile teams are capable of achieving shorter time to market, and therefore cost savings. They start development earlier than with traditional approaches because Agile minimises the exhaustive planning and documentation that conventionally is part of the early stages of a project, and it also brings forward defect discovery into earlier development phases.

The ideal Agile development team is completely self-organising and self-managing in that it deter-mines how much work can be accomplished in an iteration and commits to achieving these goals.Distributed teams are far more in line with this than they might appear at first glance. They are driven by a need to be self-organised and to make up for the geographical separation and still be effective during the times that the teams do meet (e.g. daily stand-ups). Any team that achieves the above-mentioned transparency, frequent inspection and adaptation will more often than not be identified as a self-organised team.

By definition, an Agile team is made up of ‘distributed’ members from various disciplines who achieve a ‘team’ status through constant communication.

A Development Team is made up of 3–9 people with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.).

Definition 2: Scrum development team (Wikipedia contributors, 2012)

The ‘Scrum Master’ is not the team leader but acts as a buffer between the team and any distracting influences. This can be achieved with entire teams that are remotely located or with individual mem-bers of a team that are distributed, as long as all distributed ‘elements’ are consistent in their vision and objective and continually communicate this.

4. Agile Organisation

Distributed Agile 9

5.1. Common Challenges

The most common challenges distributed teams (Agile or traditional) generally face are the following:

• Time zones and working hours

• Cultural and language differences

• Availability and access to tools

• File sharing

• Team dynamics

• Telephone dynamics

All these challenges are important to establishing the single element that is an essential ingredient for an efficient and successful project team: trust. Therefore, almost all of these challenges can be mitigated either partially or completely by maste-ring the greatest challenge of all: communication. As already discussed, co-located teams have the highest rate of success, but why?

• They communicate face to face

• Pros:

– Highest collaboration level

– Richest communication level

– No loss of non-verbal communication

– Promotes self-organisation of the team

– Permanent participation of the entire team

• Cons:

– Requires a collocated team

• They obtain instant feedback from team members

• They benefit from communication fidelity — the degree of accuracy between the meaning intended and the meaning interpreted (Petersen, 2007):

• 55 % of the meaning is conveyed by physical body language,

• 38 % is conveyed by culture-specific voice tonality, and

• only 7 % of the meaning is conveyed by words.

Much of the focus around communication and working side by side is about building trust.

5.2. Practical Guide to Succeeding in Distributed Agile Teams

5.2.1. Communication Solutions

This section covers the basic suggestions of how to overcome the communication challenges faced by a distributed Agile team. Although these are rather general suggestions, it should be noted that imple-menting the appropriate communication model is absolutely critical to the success of a distributed Agile approach given the nature of the iterative and continuous feedback approach that is the core of the methodology.

• Establish a synchronisation and communication plan:

• Define how the client, local team, and distri-buted teams will communicate and maintain synchronisation

• Define daily and distributed stand-ups, retro-spectives and sprint review time

5. Distributed Agile

Distributed Agile 10

• Use interactive communication software with a voice layer to assist in keeping all parties across distributed teams engaged, as well as easily being able to ask and answer questions. Also, talking is more efficient than typing – you can use hands- free headphones and web cameras to facilitate voice communication

• Use interactive communication software with screen-sharing capabilities for up-skilling and troubleshooting so that a visual relationship can be established which helps to improve trust

• Establish a central repository for project infor-mation so that it is permanently available to all team members and remains current, particularly for distributed teams that do not have a large time zone overlap. Ensure some sort of versioning is in place for project documentation in shared locations:

• Shared drive

• Document management tools

• Establish centralised wikis and discussion forums (knowledge base):

• They allow dispersed team members to post questions and receive answers quickly from team experts anywhere in the world; posts should be a searchable information source

• Use a teleconference facility. If you’re not using web cameras, then until everyone recognizes each other’s voice, try to introduce yourself each time before you start speaking:

• It is ideal for distributed teams with overlapping hours

• It provides a backup for collocated teams

• It allows team members to interact directly

• It allows permanent participation of the entire team

• Discuss blockers and remove them immediately

• Use a videoconference facility:

• It potentially enriches the communication experience

• It allows team members to interact directly

• It helps turn names into people

• Use enterprise tools (Quality Center, Commu-nicator, TeamForge, POD):

• Breeding synergy, transparency, productivity, and trust increases efficiencies across pro-jects and organisations

• When a tester updates an artefact, that up-date triggers a monitoring event, which sends an email to everyone monitoring that artefact

Figure 3: Daily Scrum (scalingsoftwareagilityblog.com)

East Coast Work Day

Denver Work Day

Moskow Work Day

Ireland Work Day

West Coast Work Day

11 AM Daily Scrum across team

Rules:

• Daily Scrum time is mandatory

• Offsite team members flex as necessary

• Meetings indexed to on-site team

• Core hours expectation support scheduling of online meeting

9 AM

7 PM

8 AM

4PM


• Account for language differences:

• Keep sentences simple and concise and use common words – do not get creative by using the most obscure words in the dictionary; de-velop a common low-level vocabulary where you understand one another and build from there. Remember: in US English, someone who is ‘blue’ is sad – in German, ‘blue’ is ‘blau’, and someone who is ‘blau’ is drunk

• Give everyone a chance to speak:

• The language barrier can make it more diffi-cult for non-native speakers to step into the conversation and supplement other team members’ ideas – Jean-Louis Marechaux shares his technique for engaging everyone on the team: ‘I usually facilitate the sharing of ideas by calling on each person to give them a chance to speak and to make sure each person’s contribution is captured. This is even more valuable when some team members speak a first language other than the one used in the meeting. The pause gives them time to translate their thoughts into words and to contribute to the conversation.’

• This also ensures that anyone using telecon-ference facilities does not get left out

• Confirm what team members understand:

• Ask leading questions or have members sum-marise in their own words to confirm their understanding is correct; typically, while one person summarises, others can quickly deter-mine if their own understanding was correct or ask additional questions to clarify

• Use solid, proven distributed development environment:

• In order to enable the team to focus on the communication challenges discussed above it is critical that shared, distributed access to code, environments, data and tools is estab-lished and working well. This means that from both a latency and access perspective the environments are fully available and proven

5.2.2. Additional Solutions

• Initially execute three to four sprints with the entire team at the local site:

• It is advisable to have the offshore team travel to the onshore base site for a period of time and work together with the onshore team in order to prove the operating model before taking it offshore

• It will take at least three to four sprints of two weeks each to build relations

• Use the time to define norms together, as well as setting up frameworks, initial architecture, and design

• This enables the distributed team to build a relation with the client, and business processes and requirements are explained

• Meet face-to-face to build trust:

• Budget in recurring face-to-face meetings between the client, local team, and distributed team

• Shorter than the initial visit but should be more or less regular: e.g. a one-week trip every half a year

• Plan for potential visits of key people when a significant change is planned, like a new system design or a major refactoring


• Establish a shared project vision:

• Participation in this activity by the whole team emphasises ownership of the project results

• Establish a rigorous norming and chartering plan to achieve high quality:

• Determine a set of activities the team will perform to ensure and maintain high-quality software

• Define a consensus-based design, coding standards, code reviews, Scrum-of-Scrums, pair programming, a source control philosophy, a defect tracking mechanism, and define ‘ready’ and ‘done’

• Use short sprints:

• Short iterations ensure visibility of the distri-buted team’s activities, and feedback can be given as quickly as possible

• Employ a Scrum Master at all locations:

• Most impediments will need to be addressed within the context and environment of each sub-team

• It is critical that the SM acts as an active coach for the entire team to embed the practices needed to support distributed agile

• Involve the entire team in the release planning, iteration planning, review, and retrospectives

• Use multiple clocks showing different time zones on the wall

• Know about local holidays for all of the distributed team members

• Work with an offshore provider with a proven retention track record. The agile delivery will be fundamentally undermined if the offshore personnel are regularly changing.

• Photos of the offshore team on the wall of the onshore office (and visa versa)

• Share social stories/updates from events

5.2.3. Onsite Coordinator

One of the methods to improve quality of com-munications with the offshore team is to have a dedicated person to coordinate and oversee its activities from onsite. This role is there to ensure the communication flow, act as liaison between the teams, and often interpret information from local to offshore languages. Even if both sides speak English fluently (e.g. outsourcing to India) there are lots of subtle differences in business lingo that need trans-lation. Add to it logistic challenges – this person typically ends up working long, odd hours – and you realize that it’s not an easy task to find someone who can do it (Krym). The onsite coordinator must be briefed by and work closely with the product owner and will find the following characteristics and skills very useful:

• Open-mindedness to absorb domain and busi-ness knowledge quickly

• Excellent communication skills

• Accessibility for the distributed team to discuss business processes

• Ability to assemble a training and knowledge transfer manual for possible distributed on-boarding


5.3. Distributed Tools, Technologies, and Practical Advice

Traditionally the level of importance around people, process and tools was considered to follow the de-picted order, reducing from top to bottom:

Distributed teams are one area where people, tools and process become very much entwined. Tools may become a key part of implementing your pro-cess in distributed teams. Availability of tooling and possibly bandwidth to support them may constrain how your team can work. Tools and how they affect a team’s activities is particularly important for distributed teams because they often adapt their processes quite significantly and make heavy use of tools to compensate for their distribution. In the case of distributed Agile teams the tools which become significantly more relevant are those which facilitate communication and replace communica-tion facilities used by collocated teams, such as physical Agile story walls.

The following section provides an overview of tools that were used successfully in the past to implement distributed Agile teams and projects.

5.3.1. Categories and Tool Samples

According to a study by Xin Wang, Frank Maurer, Robert Morgan, and Josyleuda Oliveira (Wang et al., 2010), the Agile tools reviewed (collected from tools published online, mentioned by interview par-ticipants (industrial agile developers), introduced by partner companies or described in relevant literature and marketing material) showed some diversity but they could still be categorised by design goals, func-tionalities, and supported platforms.

Category Sample Tools

Wiki MASE, PmWiki, MediaWiki

Web-form-based application

Rally, VersionOne, ScrumWorks, XPPlanner, Mingle

Board-based application

CardMeeting, GlueWiki, AgilePlanner, MASE, Mingle, Danube

Plugins for IDE IBM Jazz, JIRA+GreenHopper, Pro-jectCards

Synchronous Agile planning tool

DAP, CardMeeting

Tabletop-based Agile planning tool

APDT

Table 1: Categories and sample tools

Figure 4: Level of importance

People

Process

Tools


Explanation:

• Wiki: Utilises web technologies to publish, manage, integrate, and distribute Agile planning information

• Web-form-based application: Stands for advanced web technology supporting more sophisticated functions

• Board-based application: Uses visual repre-sentations resembling index cards to represent tasks

• Plugins for IDE: Stands for integrated project planning tools with an Integrated Development Environment

• Synchronous Agile planning tool: Takes care of the requirements of collaborative interactions, e.g. synchronous notifications

• Tabletop-based Agile planning tool: Employs the interactive features of tabletops to enhance the user experience

Criteria DAP

Card

Mee

ting

Agile

Plan

ner

MAS

E

Rally

Vers

ionO

ne

XPPl

anne

r

Scru

mW

orks

Glue

Wik

i

APD

T

Min

gle

IBM

Jazz

Creating, editing and deleting planning objects F F F F F F F F F F F F

Handling efforts estimates F N F F F F F F N N F F

Planning multiple iterations F P F F F F F F P P F F

Moving stories from one iteration to another F P F F F F F F P P F F

Authentication N F F F F F F F F N N N

Real-time updates of the plan F F F F F F F F F F F N

Visual characteristics for different types of stories F F F F F F N N F F F F

Integration with the development environment F N N N N N N N N N N F

Fluid transition between individual and collaborative work P P F P P P P P P F P P

Telepointers for pointing and gesturing F N N N N N N N N F N N

Real-time information sharing P P P N N N N N N P N N

Change notification P P N P P P ? P N P P P

Joining and leaving meetings F F F F F F F F F F F F

Fluid subgroup formation and dissolution P P P N N N N N P P P N

Simultaneous interaction F F P N N N N N N F P P

Table 2: Evaluation of distributed Agile planning toolsKey: F = Feature is fully supported, N = Not yet supported, P = Partly supported, ? = Not enough data collected


The evaluation shows that most aspects of Agile project planning are supported by the existing tools, except that the requirements for collaborative inter-action are not yet or only partly fulfilled.

This is however changing very fast with the likes of Hewlett Packard and Microsoft. Late in 2012 HP introduced HP Agile Manager. It leverages native cloud architecture for instant-on access, and offers technology innovations that remove latencies and bolster agile practices allowing for management across projects, teams and geographies. Microsoft have also introduced a highly integrated solution with Visual Studio 2012 and Team Foundation Server that allows for some powerful workflow solutions between testers and developers in distributed Agile teams by being able to trace to the line of code where a defect occurs which can be via live task notification, or trace files sent through other com-munication channels such as email. It also utilizes SharePoint as a reporting and dashboard platform, making use of web functionality for dynamic and fully distributed visibility.

5.3.2. Practical Tools Advice

Distributed project planning tools are well developed to support asynchronous Agile operation. However, the following restrictions apply:

1. Multi-cultural aspects and languages are gene-rally not supported; English is the dominating language.

2. Data exchange between Agile planning tools and MS project is problematic.

3. Existing tools hardly maintain synchronous Agile planning meetings.

According to Xin Wang, an analysis of existing tools shows that nearly all of them focus on and support

asynchronous features such as progress tracking and card management. The next step will require supporting synchronous project planning meetings, setting up ubiquitous project planning environments, and enabling data exchange between different Agile tools and/or with non-Agile planning tools.

5.4. Case Studies and Personal Experience

5.4.1. Case Study – Mature Agile Project

One offshore Agile project which has now been run-ning for three years enjoys fairly mature processes. Key to the success of this project – as has already been indicated above – are communication and tools.

The following factors have helped the project to succeed:

1. Daily stand-ups both in the UK and US, followed by a smaller stand-up with a smaller group of UK and US project leads

2. An online Agile project management tool (Rally) to manage and track tasks and defect manage-ment

3. Extensive use of Skype features like Group Chat, which keeps everyone in the loop

4. Stories, requirements / acceptance criteria defined and agreed in advance of planning

5. Clear and unambiguous acceptance criteria such as the Given, When, Then

6. Consistent sprint schedules (2 weeks) proved most productive

7. Three-way (BA, Development, Tester) discus-sions and meetings on stories

8. A daily defect management meeting to discuss and triage defects


9. In some cases, flying developers/testers over to be in one place for release planning/pre-releases proved effective

Due to experience with complex functionality where rework was required, our challenge is to get the functionality right the first time round. In order to address this issue, we are increasing end user involvement in sessions with business analysts.

5.4.2. Case Study – Offshore Agile Testing from South Africa, Utilities, 6 months

The challenge of this particular case study (Mthembu, 2012) was collaboration between the SQS South African offshore team and an onsite Agile test team in the UK.

It is in the nature of this kind of cooperation that the team members do not know each other personally and often do not even have faces for the names of people they have to work with. This makes it difficult to allocate statements to names or remember who gave which feedback. In this case, daily communi-cation was assured by MS Communicator sessions and emails, although the latter occasionally caused some delay in feedback. During the daily Scrum meetings, the offshore team was connected via instant messaging – but due to discussions in the background, bad technical equipment (e.g. low microphone quality, no videoconference facility), as well as the continuation of discussions after the meetings at the onshore counterpart, the offshore team missed out on important feedback and infor-mation. In terms of planning and estimation, only the onshore partner was involved, which eliminated any kind of feedback from the offshore site. The work distribution only scheduled complex user stories for the onshore team, which resulted in some expert testers for that team while the offshore test team

once again was left feeling second choice. Typically for Agile projects, the documentation was not in focus, so the offshore testers neither had a real chance to fully understand the user stories nor could they gain much of a business or domain knowledge.

The turnaround just came when one of the offshore team members was allowed to meet the onshore team in the UK and discuss the operational issues with the onshore Test Lead and the Scrum Master. The presence of this single team member was enough to change crucial issues. The ‘ambassador’ met with the entire UK team consisting of the Test Lead, developers, product owners, and the Scrum Master, which made it possible for her to gain more domain knowledge and learn about customer processes. Additionally, the personal bonds were strengthened at an informal team lunch.

Although only a single member of the offshore team was able to have this experience, the effect multi-plied when she was back in South Africa, sharing her thoughts about the onshore team and letting her colleagues participate in the knowledge she had gained in the UK. In terms of communication, some rules were established to ensure a better exchange of information over the cultural and geographical distance:

• Any issues reported by email and not receiving any feedback were to be raised in the next Scrum meeting.

• Teleconference equipment was to be used properly (e.g. moving the microphone or phone around for better audio quality).

• Everyone participating in the teleconference was addressed separately and asked for his/her specific update on the Scrum board, which allowed everybody in the conference to follow the discussion and progress accordingly.


• If necessary, meetings were scheduled in addi-tion to the daily Scrum meetings, where not only the Test Lead but all team members were to participate.

• The offshore Test Lead was now involved in the planning and estimation sessions, including the retrospections, to represent the offshore site.

• Live meeting sessions were scheduled to make up for the lack of documentation. In the context of the unit tests, the developers went through the user story functionality with the South African test team so that the offshore testers could go back and verify data documented on TDS and the product backlog in order to create test scripts with a better understanding.

Apart from these issues and challenges, it is worth mentioning that there were also many aspects which worked perfectly right from the beginning of the project:

• All kinds of update were visible on the electronic Scrum board and burn-down chart in an Agile shared location for all team members.

• Daily Scrum meetings were held, which were essential to raise issues, queries, and updates.

• Live meetings were used to support a better understanding of the process workflow (these should be favoured over old-fashioned teleconfe-rences where nothing can be visually presented).

• The time zone difference in this case was only a minor issue of one to two hours (for bigger differences, this would need to be properly managed).

• The Scrum Master as the key figure was very willing to address team as well as project issues raised by the offshore team in a timely manner, and organised implementation of the required changes.

• The product owners insisted on having the off-shore team involved in all discussions and did not mind spending time on the phone in order to clarify issues.

• A place where all team deliverables were saved was set up, and every team member had access to it 24/7.

In summary, this case study showed that distributed testing can work very well provided some precon-ditions are met and people remain open-minded to identify weak spots and fix them. In this context, proper planning starting from the first day of the project is a must. Moreover, the following should be considered:

• Provide room for the building up of good relation-ships within the team.

• Make adequate communication and knowledge- sharing tools available to share information properly.

• Provide a shared electronic location to save documents and make them accessible to every-one.

• Set up communication rules for teleconferences and meetings to avoid excluding individual team members.

• Be patient in building up trust within the team – this will only come step by step, with extended domain knowledge and well-rehearsed team processes.

‘Distributed Agile is somehow like any other offshore team, but needs a lot more team effort. The main differences from my point of view are the importance of daily team discussions, daily involvement of the product owners, a shared location with daily team updates, and adaptation to change.’ (Mthembu, 2012)


6. Conclusion and Outlook

Action is the foundational key to all success.

Pablo Picasso

SQS experience of offshore Agile deliver has taught us:

• The reality is that working with distributed teams can be a nightmare if badly structured. The challenges increase as the type of distribution spreads from collocated, to distributed with overlapping working hours, to distributed with no overlap in working hours.

• One important key to success as a distributed team is to ensure a high commitment level from all team members, and the best way to achieve this is to give them ownership over how they will work.

• Retrospectives help teams evaluate whether communication is working for them, as well as being responsive to their stakeholders’ needs.

• Teams should feel continually free to adjust any of the approaches and solutions to better suit their needs.

• Tight collaboration and coordination is imperative.

• Tools are critical, but they are not the only answer – having good processes in place is indispensable.

• Technology will help overcome most obstacles, therefore code review, wikis, discussion forums, bug tracking, requirements tracking, and conti-nuous integration are essential.

• An integrated platform to support synergies, transparency, productivity, and trust increases efficiencies across projects.


Ambler, S. (n.d.). Dr. Dobb’s. Retrieved 2012, from www.ddj.com/architect/200001986

Ambler, S. W. (n.d.). Retrieved from www.ambysoft.com/scottAmbler.html

Ambler, S. W. (2011, 10). 2011 IT Project Success Rates Survey Results. Retrieved 01 04, 2013, from http://www.ambysoft.com/surveys/success2011.html

Beck, K. (n.d.). Agile Manifesto. Retrieved from http://agilemanifesto.org/history.html

Highsmith, J. (n.d.). Agile Manifesto. Retrieved from http://agilemanifesto.org/history.html

Klocwork. (n.d.). Retrieved from http://www.klocwork.com/blog/2010/02/agile-adoption-an-update/

Krym, N. (n.d.). The Myth of the Onsite Coordinator. Retrieved from Pragmatic Outsourcing: http://pragmaticoutsourcing.com/2008/11/20/the-myth-of-the-onsite-coordinator/

Mthembu, N. (2012, 10 03). My experience working in a distributed Agile project. South Africa.

Petersen, G. (2007, 10 18). Mythos: 93 % der Kommunikation ist nonverbal - My Skills. Retrieved 01 08, 2013, from http://blog.my-skills.com/2007/10/18/mythos-93-der-kommunikation-ist-nonverbal.html

Scott W. Ambler + Associates. (2008, 06). Agile Adoption Rate Survey Results: February 2008. Retrieved 01 08, 2013, from http://www.ambysoft.com/surveys/agileFebruary2008.html

VersionOne. (n.d.). Retrieved from www.versionone.com

Wikipedia. (n.d.). Retrieved from https://www.google.co.za/url?url=http://en.wikipedia.org/wiki/Self-organised&rct=j&sa=X&ei=13liUI_pHpSLhQeItoGwCQ&ved=0CDEQngkwAA&q=self+organised&usg=AFQjCNGA5TlzKfNjgIPjheIgclKklEv16Q

Wikipedia. (n.d.). Retrieved from http://en.wikipedia.org/wiki/Scrum_(development)

Wang, X., Maurer, F., Morgan, R. & Oliveira, J. (n.d.). Retrieved from http://ebe.cpsc.ucalgary.ca/uploads/Publications/Wangetal2010.pdf

7. Bibliographical References

whitepaper: distributed agile - sqs · case study – offshore agile testing from south africa,...

Documents