Keywords

1 Introduction

The process of requirements elicitation is one of the most challenging tasks in software development. In traditional software development methodologies, the client would predefine all their requirements to the development team before the start of subsequent phases. The team would then analyse the requirements and finalise a software requirements specification (SRS) document. Once the client has approved the document, they would start the development phase. This process of requirements elicitation has problems such as; a long time is spent in preparing this documentation, which causes issues in dealing with future requirements change requests from the client once the actual development phase starts. Over decades of software development we have learnt that requirements change is inevitable during the development stage, because neither the client nor the developers are 100% sure of all the requirements of the system at the start of the project.

In agile software development, this problem is solved with the use of story cards, which is a lighter process for the definition of very high-level requirements and is an artefact of methods such as SCRUM and XP. They contain just enough information for the developer to be able to estimate how much effort and time will be required to develop them and can handle change requests with little effort. There is also an agile requirements change management process to control changing requirements throughout the software development lifecycle. Based on this process, new requirements can be added and reprioritized based on the client’s request [1]. Figure 13.1 illustrates the agile requirements change management process:

Fig. 13.1
figure 1

Agile requirements change management process

Full size image

However, in distributed agile software development, as the team is distributed over different time zones, the process of gathering and documenting requirements becomes more complex. As any change in the requirements need to be communicated over different locations and due to cultural and language differences, requirements can be misunderstood.

In this chapter we will discuss how agile methods are used in offshore software development, what are the challenges facing the requirements elicitation process in agile offshore software development and how we can use distributed agile patterns to overcome these challenges.

2 Agile Offshore Software Development

Since the creation of the agile manifesto it has brought unprecedented changes to how software is being developed [2]. The manifesto focuses on four points, which are:

  1. i.

    Individuals and interaction over processes and tools

  2. ii.

    Working software over comprehensive documentation

  3. iii.

    Customer collaboration over contract negotiation and

  4. iv.

    Responding to change over following a plan.

Nowadays many companies are using agile for developing their offshore projects [3]. However, the use of agile methods on offshore projects is not a straightforward process. Taylor et al. [4] claim that projects that use agile for offshore development go through many problems because of the differences in the development practices and the complex development environments. Table 13.1 shows a characteristic comparison of agile and offshore development, done by Šmite et al. [5], showing the differences in the development styles.

Table 13.1 Comparison of agile development versus offshore development [5]
Full size table

Table 13.1 shows that the application of agile methods is not a straightforward process in offshore development. Based on extensive literature review on offshore software development four key challenges have been identified that affect the adoption of agile practices. Table 13.2 shows the results of how these challenges affect agile practices.

Table 13.2 Agile practices affected by offshore challenges
Full size table

Table 13.2 summarises the agile practices that cannot be used as they are in offshore software development and that the requirements engineering process is affected in offshore development. In the next section we have identified how these challenges affect the requirements engineering process in agile offshore development.

3 Challenges in Requirements Engineering Process in Agile Offshore Development

This section discusses the challenges and effect of agile offshore development on the process of gathering and documenting requirements. Table 13.3 shows the effect of agile offshore development challenges on the requirements elicitation process. As the table demonstrates the four challenges identified in our study have direct impact on the gathering, analysis and change management of requirements.

Table 13.3 Requirements engineering process affected by challenges of agile offshore development
Full size table

4 Distributed Agile Patterns

Based on the previous section we can see that applying agile on offshore project is not a straightforward process. We studied over 200 cases from the literature and interviewed practicing professionals involved in distributed teams, which resulted in observing a number of solutions addressing common agile issues in offshore software development settings, which we presented as Distributed Agile Patterns .

The term “pattern” is commonly referred to as a reusable solution for a recurring problem within a given context [6]. Based on this definition, we defined Distributed Agile Patterns as, adaptation of an agile practice that is being repeatedly applied in order to solve a recurring challenge in a distributed project scenario.

Generally a pattern has four essential elements [6]:

  • The pattern name: to give a high level of abstract to the pattern. It gives us the idea of what problem the pattern is providing a solution for in a word or two. Giving a name to a pattern makes it easy for us to talk about it with people and for documentation.

  • The problem: helps in describing when the pattern can be applied. It provides details of the problem and its context. It may include lists of conditions or scenarios, which must be met in order to apply the pattern.

  • The solution: describes the elements that make up the agile patterns, their relationships and responsibilities. The solution does not describe a particular concrete agile practice or implementation, because a pattern is like a template that can be applied in many different scenarios. A pattern does provide an abstract description of an agile practice problem and how a general arrangement of elements/practices can solve it.

  • The consequence: describes the outcome of applying the pattern. They are critical for evaluating a pattern and for understanding the benefit of applying a pattern to see if it helped in solving the problem and if yes, up to what extent. For software the consequence often refer to space and time trade-offs. In distributed agile patterns, the consequence includes flexibility, extensibility and team coordination and collaboration.

The Distributed Agile Pattern’s catalogue is developed based on literature and interviews and adopted Gamma’s pattern template in order to preserve familiarity, as they are perceived as the first pattern catalogue documented by the software community. A customised template was then developed to capture the specific findings related to distribute agile practices. The distributed agile patterns template contains the following sections:

  • Pattern Name: As patterns represent generic knowledge it is vital to give a good name that would make it recognisable and reusable. A good name also helps in facilitating communication among practitioners about the pattern.

  • Intent: A short statement that highlights the issues and problems that are required to be solved by applying the pattern.

  • Also known As: The pattern’s other well-known names, if any are mentioned in this section.

  • Category: Based on the similarities of the patterns we grouped them into different categories to be able to provide an abstract view of all the patterns.

  • Motivation: It consists of the description of the problem and why the pattern should be used in order to avoid the problem from recurring. It provides scenarios that help understand the abstract description of the pattern.

  • Applicability: Under what conditions the pattern can be applied.

  • Participants: The participants are those people that are required in applying the pattern.

  • Collaboration: How participants will coordinate with each other in order to fulfil their responsibilities that are required to complete the projects.

  • Consequences: Discuss the trade-offs of applying the patterns such as advantages and difficulties faced when applying it.

  • Known uses: Examples of real scenarios found that follow the pattern in order to provide clarity of how the pattern can be used.

  • Related Pattern: List of similar patterns in order to identify which patterns can be used together to improve a particular situation.

Following is the summary of list of the identified distributed agile patterns [7]:

  1. 1.

    Distributed Scrum of Scrum Pattern: To apply scrum, sub-teams are formed based on location. Each team has its own scrum. Scrum of scrum meetings are arranged to discuss the progress of the project, which is attended by key people.

  2. 2.

    Local Standup Meetings Pattern: To discuss daily updates on work done, each local team will conduct their own stand-up meetings.

  3. 3.

    Follow the Sun Pattern: Onshore and offshore teams will work 9 a.m–5 p.m according to their own time zones.

  4. 4.

    Onshore Review Meeting: The onshore team will present the demo as they are located where the client is.

  5. 5.

    Collective Project Planning: Both the onshore team and the offshore team will collectively work in the project planning phase.

  6. 6.

    Project Charter Pattern : Before starting the project planning activity, agile teams use project charter in order to have a central document between the onshore and offshore team that defines the project.

  7. 7.

    Collaborative Planning Poker: Only Key people will hold this activity from onshore and offshore team.

  8. 8.

    Global Scrum Board: There will be an online-shared Scrum board, which, both onshore and offshore team can use to view product backlog, storyboard, task board, burn down charts and other agile artefacts using online tools such as wikis.

  9. 9.

    Local Sprint Planning: Each team will have their own sprint planning meetings.

  10. 10.

    Local Pair Programming: Make pair programming teams from the same location.

  11. 11.

    Central Code Repository: The whole team will maintain a central code repository so that both team can see each other’s code and see the progress of the work done.

  12. 12.

    Asynchronous Retrospective Meetings: Teams conduct separate retrospective meetings based on location and share the key information via email. The Scrum Masters discuss possible improvements with the team based on the feedback from the client.

  13. 13.

    Asynchronous Information Transfer: Due to the time difference between the onshore and offshore team use online tools to exchange information with each other. Each team should response to queries within 12 h.

  14. 14.

    Synchronous Communication: In order to discuss issues the teams used synchronous tools for voice, video conferencing, document sharing, application sharing, etc.

  15. 15.

    Visit onshore–offshore Teams: Both onshore and offshore teams should quarterly/annually visit each other in order to build trust, exchange cultural values and improve team coordination.

Fifteen distributed agile patterns were identified and organised into four categories based on the type of problem they solve, which are management, communication, collaboration and verification patterns. Table 13.4 shows the 15 distributed agile patterns according to their categories.

Table 13.4 Categories of distributed agile pattern
Full size table

  • Management patterns help in managing the onshore and offshore team members and their activities to effectively apply agile in a distributed environment.

  • Communication patterns focus on providing solutions to how distributed team members can maintain an effective communication channel in an agile setting using different online tools which provide both synchronous and asynchronous method for communication.

  • Collaboration patterns provide solutions regarding which activities the onshore and offshore team members should conduct together to improve team coordination and project progress.

  • Verification patterns focuses on how efficiently the clients can get a distributed project developed according to their requirements and monitor the progress of what has been developed.

The identified distributed agile patterns are spread across the Scrum software development lifecycle as shown in Fig. 13.2. In this chapter we have only presented the patterns that map to the requirements engineering process, however, the full catalogue is available online [8].

Fig. 13.2
figure 2

Distributed agile patterns application of software development lifecycle

Full size image

5 Distributed Agile Patterns Used for Requirements Engineering Process

In this section we present the selective Distributed Agile Patterns that are used in the Requirements engineering process, which are further explained in the following section showing how they are used to gather and document requirements.

5.1 Project Charter Pattern

In project management, a project charter is a statement that defines the scope, objectives and participants of a project. It is used to explain the roles and responsibilities, outline of the project objectives and identify main stakeholders. It has been observed that while starting a distributed project using agile many organisation use project charter to clarify the goals and objectives of the project to both onshore and offshore team [8] (Table 13.5).

Table 13.5 Project charter pattern
Full size table

5.2 Collective Project Planning Pattern

Agile focuses on individuals and interactions over processes and tools. While planning for the project the whole team is present. Unlike the traditional development where a project manager hands a project plan to the team, in agile the whole team takes part in the planning activity in order to determine when and how the project will be developed. It has been observed that even if the project is of a distributed nature it is better to co-locate the onshore and offshore teams for the project planning activity. The motivation of this pattern is to address the trust, socio-cultural, communication and coordination and knowledge transfer challenges. For example, consider a team that is divided into sub-teams that are located on different time zones and both the teams at the beginning of the project come to one location to do the project planning activity; this helps the team members to understand each other and establish working standards for the project. The detail table for this pattern can be found in Appendix 1.

5.3 Local Sprint Planning Meeting Pattern

In agile, a scrum consists of many sprints. The duration of a sprint varies from 1 to 4 weeks depending on the size of the project. At the start of every sprint the team has a sprint planning meeting in which the team defines the goal of the sprint and prepare the sprint backlog. When the team is divided and is working on different modules of the project it has been observed that the onshore team members and offshore team members conduct their own separate sprint planning meetings. The motivation of this pattern is to address the communication and coordination and knowledge transfer challenges. For example when a project is distributed to a team that is divided over different time zones, it is better that each location has their own sprint planning as it helps each team to decided their own tasks without having to wait for the other teams to be present. The detail table for this pattern can be found in Appendix 2.

5.4 Collaborative Planning Poker Pattern

An agile team plays a planning poker to put point estimation on each story card. The product owner also takes part in this activity. He/She tells the team the intent and value of a story card based upon which development team assigns estimation on the card. Based on the points assigned, the team members who assigned the lowest and highest estimation will justify their reasons. The team will have a brief discussion on each story and assign a fresh estimation upon which the whole team agrees on.

It has been observed that even when the team is distributed the planning poker activity is conducted when both teams are co-located for the project planning activity. The motivation of this pattern is to address the trust, socio-cultural, communication and coordination and knowledge transfer challenges. For example when a project is distributed over different locations, team members located at different locations, do not know each other’s skill set so with the help of collaborative planning poker, each member can assign estimation points according to their skills. The detail table for this pattern can be found in Appendix 3.

5.5 Global Scrum Board Pattern

Agile has many artefacts such as product backlog, sprint backlog, storyboard, task board, team velocity and burndown charts which help the team in managing the project. It has been observed that when the team is divided to different locations they maintain an online record of all these artefacts so that they can share them with each other using online tools such as Wiki’s, Rally and Jira [9,10,11]. The motivation of this pattern is to address the trust, socio-cultural, communication and coordination and knowledge transfer challenges. As the team is distributed over different time zones, any change in the requirements and sprint can be viewed in real time with the help of the global scrum board. The detail table for this pattern can be found in Appendix 4.

5.6 Central Code Repository Pattern

In agile, when a team is using Scrum and XP, the team members are divided in pairs of two and are working on different tasks during a sprint. When a task is completed the team members commit their code to a share repository for continuous integration of the code. It is observed that even when the team members are geographically apart they still use a share code repository where they commit their code so that all the team members can see the code as well as determine the progress of the project. The motivation of this pattern is to address the communication and coordination and knowledge transfer challenges. As the team members are distributed over different locations, with the help of the central code repository, all the team members can see the progress of the project. The detail table for this pattern can be found in Appendix 5.

5.7 Asynchronous Information Transfer Pattern

Agile emphases on close face-to-face communication between the team members rather than detailed documentation. When a team is distributed on different time zones it has been observed that the teams adopted asynchronous tools for sharing information with each other such as emails, Wikis, SharePoint. The motivation of this pattern is to address the communication and coordination and knowledge transfer challenges. Due to different time zones, the team members can use asynchronous communication methods to share information with each other. The detail table for this pattern can be found in Appendix 6.

5.8 Synchronous Communication Pattern

Agile emphases on close face-to-face communication between the team members rather than detailed documentation. When a team is distributed on different time zones it has been observed that the teams adopted asynchronous tools for sharing information with each other such as emails, Wikis, SharePoint. The motivation of this pattern is to address the trust, socio-cultural, communication and coordination and knowledge transfer challenges. For example, in case of any confusion, team members can communicate with each other using real time synchronous tools for communication. The detail table for this pattern can be found in Appendix 7.

5.9 Visit Onshore–Offshore Team Pattern

As agile emphases on close face-to-face communication between the team members it has been observed that when the team is divided on different time zones, the team members travel quarterly or annually to visit each other. This activity helps build trust among the team members and helps them understand each other’s cultural differences [12,13,14,15]. The motivation of this pattern is to address the trust, socio-cultural, communication and coordination and knowledge transfer challenges. For example, in order to establish trust and understand each other’s culture, team members should quarterly/annually travel and do team activities. The detail table for this pattern can be found in Appendix 8.

6 Use of Distributed Agile Patterns in Requirements Engineering Process in Agile Offshore Development

In order to verify and validate the identified distributed agile patterns, we conducted a reflection workshop based on Norm Kerth [16], ‘The keep/try reflection workshop’. Based on the workshop we designed Table 13.6, which shows how Distributed Agile Patterns address requirements engineering challenges in offshore development, which were mentioned in Table 13.3, to the relevant distributed agile pattern addressing them.

Table 13.6 Using distributed agile patterns to address requirements engineering challenges in agile offshore development
Full size table

7 Mapping Distributed Agile Patterns on the Requirements Engineering Lifecycle

In this section we map the distributed agile patterns onto the traditional requirements engineering lifecycle, to show how these patterns facilitate the requirements engineering process. As shown in Fig. 13.3, the four key features of this process are as following:

Fig. 13.3
figure 3

Mapping distributed agile patterns on traditional requirements engineering process

Full size image

  • Feasibility Study : In this process, we decide whether or not the proposed system is worthwhile. By writing down the Project Charter document in the beginning of the project, we can achieve this. As stated in the Project Charter we define the aim, objectives and core functional requirements of the proposed system.

  • Requirements Elicitation and Analysis : The purpose of this process is to identify the application domain; the services it will provide and what are the limitations. Three distributed agile patterns are applied in these phases. Collaborative project planning helps the team to find out what the requirements of the application to be developed. Local sprint planning helps team members in their respective locations to discuss in detail the user stories allocated to them and determine the constrains associated with them. Collaborative Planning Poker, allows the team members to discuss the services that the system will provide and estimate how much effort is required to develop them.

  • Requirements Specification : Once the requirements have been identified, we document them in the SRS document. As in agile software development, requirements are documented using user stories, in distributed agile software development; we use a Global Scrum Board, where all the story cards are placed. Hence any change or modification in the requirements will be updated on the Global Scrum Board, which is accessible by all the team in real time.

  • Requirements Validation : In this process, the requirements are validated by reviewing them to make sure that the identified requirements are in accordance with what the client wants. Four distributed agile patterns make sure that the correct requirements are identified. Central Code Repository helps the client verify that the code being developed is according to requirements. Asynchronous Information Transfer provides a platform to the team members and the clients to communicate and coordinate the progress of the system being developed and in case of any confusion, the team can either use asynchronous or synchronous tools for communication, according to the communication standards defined using Synchronous Communication Pattern . For further clarification of requirements, distributed agile patterns suggest that both onshore and offshore team members should visit each other.

8 Conclusions

In this chapter we have discussed the requirements engineering process and highlighted the issues practitioners face in agile offshore development such as incorrect user story estimation, problems in identifying the core functional requirements and vague requirements. Based on our observation and literature, we found that these challenges affect the whole requirements engineering process. Using distributed agile patterns, practitioners can avoid these challenges. They can use them at the beginning of their offshore projects and make informed decisions about how to adopt agile approaches to gather and document requirements, as generalised patterns make it easier for other companies to reflect on and to apply the results to their own cases.