Empirical Research on Customer Communication Challenges in the

Companies Adopting Agile Practices

Paolo Ciancarini

2 a

, Shokhista Ergasheva

1 b

, Ilyuza Gizzatullina

, Vladimir Ivanov

1 c

Sergey Masyagin

1 d

and Giancarlo Succi

1 e

Innopolis University, Innopolis, Russia

University of Bologna, Italy

Keywords:

Software Requirements Engineering, Software Metrics, Customer Communication, Agile Methodologies.

Abstract:

One of the most critical aspects of Software Development Process is the Requirements Engineering process

and deﬁning the correct and understandable requirements in Agile methodology. Hence, Requirements Engi-

neering in agile directly effect the overall project success. This paper demonstrates a research study about the

usage of Agile methods in the set of industrial companies located in Russia. The survey gives insights about

different aspects of the method: communication challenges and issues arising during the Software Require-

ments Engineering phase in particular the challenges in the communication with the customers. To investigate

these issues the paper presents an analysis of the state of the art done with the help of the research survey. The

results of the interview sessions are summarized and the set of suggestions to overcome the challenges are

proposed. 30 representatives from 20 different companies who are mainly Product owners and Product Man-

agers participated in the survey. As the results indicate, the communication is always a key challenge for the

companies. The analysis of particular qualities of the communication ﬁeld in the context of rapidly changing

Software Development environment helped to deﬁne the outcomes related to the customer communication.

1 INTRODUCTION

Agile methodologies were formalized a couple of

decades ago to address the so-called “Software cri-

sis” (Maurer et al., 1999; Kivi et al., 2000; Succi

et al., 2001a; Sillitti et al., 2002; Succi et al., 2002;

Pedrycz et al., 2011; Sillitti et al., 2012; Janes and

Succi, 2014; Coman et al., 2014). One of their key ap-

proaches has been a close and continuous interaction

of the customer throughout the Requirements Man-

agement phase. The practise introduces customer col-

laboration and receiving the feedback on each devel-

opment iteration, as well as adaptiveness and response

to change. Despite the fact that both Agile and tradi-

tional methodology practises have been adopted dur-

ing decades, still the Requirements Engineering phase

of the Software Development Life Cycle appears the

issue of paramount importance (Baruah, 2015). Ac-

https://orcid.org/0000-0002-7958-9924

https://orcid.org/0000-0003-0241-5640

https://orcid.org/0000-0003-3289-8188

https://orcid.org/0000-0002-6010-8764

https://orcid.org/0000-0001-8847-0186

cording to the recent studies conducted in the Re-

quirements Engineering of Agile methodologies con-

cerning the customer collaboration, most of the stud-

ies are centered around the customer collaboration

challenges. Some of the authors emphasize the im-

portance of face-to-face communication over written

speciﬁcations and described the challenges occurring

in customer-related agile requirements engineering

activities(Cao and Ramesh, 2008). Mainly the chal-

lenges claimed in the paper include customer avail-

ability, consensus among customer groups and cus-

tomer trust to the agile team and many others.

Most of the researches done till this time around

the issue of collaboration of the customer with the

production can turn to deﬁcient because of the aging

of the methodology taken towards the communication

between customer and development team. Because

the development of the modern communication pan-

els like social networks, messengers and platforms for

easier connection does not require taking under con-

sideration the physical availability.

The research survey mainly focuses in the issues

related to the customer communication in Agile prac-

tising companies during Requirements Engineering

Ciancarini, P., Ergasheva, S., Gizzatullina, I., Ivanov, V., Masyagin, S. and Succi, G.

Empirical Research on Customer Communication Challenges in the Companies Adopting Agile Practices.

DOI: 10.5220/0010526401390150

In Proceedings of the 23rd International Conference on Enterprise Information Systems (ICEIS 2021) - Volume 2, pages 139-150

ISBN: 978-989-758-509-8

139

process. It includes the deﬁnition of the challenges

in the customer communication, gives suggestions to

overcome and minimize the issues.

The paper starts with the discussion of the related

works done in section 2, which includes contribu-

tions done in the area of Requirements Engineering

and collaboration of customer with the development

team. Following, section 3 illustrates the methodol-

ogy underlying this paper, research experiments, in-

terview process and evaluation details. All the results

and analysis concerning the conducted interviews, de-

rived challenges in the area and suggested solutions

to the stated issues were explained in details in sec-

tion 4. Finally the section 5 discusses the validity and

threats of this study, concludes the results and gives

directions for future research in section 6.

2 RELATED WORK

In the science of domain dozens of publications have

described the activities to be conducted in the Re-

quirements Engineering process which requires the

customer collaboration. According to the research pa-

per Paetsh at al. (2003), agile methodology adopting

practise includes conduction of the following main

activities during the Requirements Engineering pro-

cess (Paetsch et al., 2003):

1. Requirements Elicitation - requirements which

can be derived in the form of interviews, use

cases, user scenarios, observation and social anal-

ysis, focus groups, prototyping of the software.

2. Requirements Analysis - the main techniques for

analysis can be Joint Application Development

(JAD), requirements prioritization and modeling.

3. Documentation - baseline for evaluating the sub-

sequent product and process.

4. Requirements Validation - requirements review,

requirements testing and validating the require-

ments whether they are acceptable for the system

to be implemented.

5. Requirements Management - concerns with the

change and version control, requirements tracing

and requirements status tracking.

Whereas (Abdullah et al., 2011) identiﬁes three

major activities of requirements engineering in the

context of user stories exploitation: gathering, clari-

fying, and evolving a story card . Each of these ac-

tivities involves active collaboration with customers.

Bjarnason et al. (2011) also highlighted the core Re-

quirements engineering process activities performed

in collaboration with the active customers (or their

representatives) (Bjarnason et al., 2011) in particu-

lar (1) One Continuous Scope Flow where the prod-

uct backlog prioritization and update for both busi-

ness and development site is performed, (2) Cross-

functional Development Teams where customer is in-

cluded in the requirements deﬁnition, implementation

and testing phases, (3) Integrated Requirements Engi-

neering, where both requirements deﬁnition and doc-

umentation is done simultaneously with design and

development phase, (4) Gradual and Iterative Detail-

ing of requirements reﬁnement process, (5) documen-

tation of requirements in the form of User stories and

Acceptance Criteria.

Another research Korkala et al. (2006) describes

the importance of the effective communication and

feedback in agile development and investigation of

customer-developer communication. As the authors

conclude, the main challenge is in the selection of

communication channel. The less informative com-

munication channels give higher defect rate. As a re-

sult, paper suggests agile teams to pay much attention

on the means of communication they select in order

to understand client needs in a proper way..

There are also several Systematic Literature Re-

views investigating the challenges of the Require-

ments Engineering process in Agile. One of that

SLR’s was held by Irum Inayat et al. (2015) (In-

ayat et al., 2015).The paper describes some particu-

lar challenges traditional compared to agile method-

ology practise during Requirements Engineering pro-

cess. Traditional methodology challenges in the

RE process were mentioned as communication gaps,

over-scoping, requirements validation, requirements

documentation, rare customer involvement. How-

ever, agile RE process challenges were also addressed

in the paper include - customer availability, cus-

tomer inability and agreement, contractual limitations

and requirements volatility, requirements change and

change evaluation, and the associated prediction of

quality and productivity (Marino and Succi, 1989; Va-

lerio et al., 1997; Vernazza et al., 2000; Mus

ılek et al.,

2002; Sillitti et al., 2004; Clark et al., 2004; Scotto

et al., 2004; Pedrycz and Succi, 2005; Ronchetti et al.,

2006; Scotto et al., 2006; Moser et al., 2008a; Moser

et al., 2008b; Pedrycz et al., 2012).

Another SLR Schon et al. (2017) (Schn et al.,

2017) reviews the papers concentrated on the stake-

holder and user involvement. The authors high-

light the several activities to involve customers to

participate in agile requirements engineering pro-

cesses where The combination of XP with co-design

session(Bellucci et al., 2015),Qualitative/Quantitative

Customer-driven Development (QCD) (Olsson and

Bosch, 2015), to organize the additional roles in

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

140

agile development such as business users, Agile-

UCD specialist (AUS) who use usability-pattern-

based requirement-analysis method (Dragicevic et al.,

2014), and Agile Software Development (ASD) with

Participatory Design (Liskin et al., 2014).

(Sillitti et al., 2005) mention problems re-

lated to customer’s uncertainty in requirements

engineering in ASD (Agile Software develop-

ment) which shows more signiﬁcant results com-

pare to document driven Software Development.

The problems listed in the papers are Cogni-

tive limits of the memory-attention-understanding,

Lack of information-knowledge, Problems of the

communication-language-communication channels,

Emotional and relational limits or difﬁculties and

Lack of clarity in business objectives.

(Pikkarainen et al., 2008) dive more into the com-

munication details and divide it into 2 types: internal

and external. Where internal communication includes

only team members, while the external communica-

tion is the communication between the customers and

the development team. As the main activities requir-

ing the communication in agile were mentioned itera-

tion planning meetings, iteration reviews, daily meet-

ings,iteration retrospectives and refused formal tools/

media type communications.

Customers are involved in collaboration with de-

velopment team in the following RE activities: Feasi-

bility study, Requirements Elicitation, Analysis, Vali-

dation.

Following customer communication challenges

are found in each RE activity:

1. Feasibility study - right choice of the customer

or the customer groups. It inﬂuences directly

on overall customer collaboration process during

further requirements engineering activities result-

ing in not so well-deﬁned requirements elicitation,

prioritization and validation.

2. Requirements Elicitation - the important factor is

means of communication used.

3. Requirements Analysis - prioritization of require-

ments.

4. Requirements Validation - presence of the cus-

tomer and his involvement into QA process (sprint

review).

5. Requirements Management - analysis, prioritiza-

tion, validation of the requirements.

According to most of the research publications,

Requirements-Driven customer collaboration is one

of the central ideas behind RE activities in agile. Fur-

thermore, there is a big need in further investigation

of case studies of the customer communication prob-

lem in agile requirements engineering due to the lack

of such researches and not enough qualitative data.

3 METHODOLOGY

This section describes the methodology that was cho-

sen for the research study starting from the questions

generated till the results revealing process.

3.1 Rationale

The review of the literature showed what kind of

customer communication challenges in agile require-

ments engineering activities exist and require solu-

tions.

Objective behind conducting this experimental

survey can be stated as exploratory and explanatory

purposes as described below:

• Exploratory purpose activities: to reveal existing

communication problems in Requirements En-

gineering processes within Agile methodology,

Scrum, modiﬁed Scrum and an exploitation of ag-

ile practices with no deﬁnite methodology, high-

light the existing procedure, ﬁnd correlation be-

tween agile in theory and in practice, explore new

hypotheses for further research.

• Explanatory purpose activities: to build a frame-

work and a language based pattern on the col-

lected data, issues and root causes of the issues

during the process, emphasize the most com-

monly repeatable activities. To ﬁgure out usual

algorithm of events.

3.2 Research Questions

To proceed with the research study we deﬁned the es-

sential questions need to be answered. The research

questions are the followings:

• What communication challenges occur between

customers and development team in the context

of agile requirements engineering?

• How communication challenges revealed in RQ1

are being solved in the context of investigated

companies?

To answer these aspects the questionnaire with the

set of questions devised according to the best practises

in the ﬁeld. It was submitted to the 40 senior IT spe-

cialists (managers, CTOs, CEOs) of the companies.

The companies considered in the research survey are

located in Russia, in particular Kazan, Innopolis and

Moscow.

Empirical Research on Customer Communication Challenges in the Companies Adopting Agile Practices

141

As the ﬁrst degree contact in the interviews it was

used a semi-structured interview model according to

(Lethbridge et al., 2005) . Moreover, in comparison to

the structures interview sessions where it is suggested

strictly follow the pre-written script, a semi-structured

interview session seems more natural. Furthermore, it

is more applicable when the interview session is orga-

nized by the researcher himself.

This method is considered as one of the most ﬂex-

ible ones because it is impossible to predict interview

process and having some freedom during the process

allows interviewer to adapt according to the inter-

viewed person and ﬁnd out more relevant information

generating natural environment during the interview

session (Myers and Newman, 2007).

The scientiﬁc validity of the research depend on

the the minimum of the biased results during the data

collection process. Therefore, in order to decrease the

level of biased data during the interview sessions, we

tried not to interrupt the interviews. Based on the

ﬁrst interview session outcomes the ﬁnal version of

the questionnaire was formed.

3.3 Experiment Design and Planning

As the base plan for this research experiment was cho-

sen the plan suggested by (Robson, 2002). This re-

search experiment can be considered as a single-case

study with multiple units of analysis. Single case -

customer communication challenges within agile RE.

Multiple units of analysis - multiple people from mul-

tiple companies.

During the research we have studied the Soft-

ware development teams in the Information Systems

and Technologies related companies. Closely worked

with the experienced IT experts in the companies

such as POs, PMs, team members performing the role

of a customer representative, team members directly

communicating to a customer. The study is single

case with multiple units of study designs according

to (K Yin, 2003) investigating different teams in dif-

ferent companies (different units of analysis) in one

context.

The collection of the data from the companies un-

der consideration was done with the help of direct

methods:

• Interviews, informal personal communication,

• Questionnaires and informal Q&A (question and

answer) sessions.

Selection Strategy and Criteria. The selection of

the data needed for the research was collected from

Russian IT companies located in mostly in Innopo-

lis, a high-tech city in Russia, Kazan and Moscow.

The size of the industrial companies considered can

be separated into a few large companies and major-

ity of small companies. The exact distribution of the

companies can be separated into:

• Large - at about half of the companies can be con-

sidered as large (more than 250 employees)

• Small - quarter of the companies in the survey

(10-49)

• Medium - the rest of the companies can be con-

sidered as medium (50-249) and micro-sized (<

10).

In the selection criteria for the company represen-

tatives we have chosen a requirement that the repre-

sentative should be wither PO or PM or performing

the role of a customer representative or directly com-

municating with the customer. The team is required

to adopting the agile methodology practises or prac-

tising Scrum or modiﬁed Scrum.

Despite the fact that the respondents had different

scopes of the projects (see Figure 1), products, never-

theless all of them relate to the production of software.

(Runeson and H

ost, 2009) proposed a checklist

for the validation of the case studies. Based on this

checklist questionnaire for interviewing and interview

planning was made in 2 iterations. It was applied

for the analysis of the state of the research before the

overall interviewing phase. It helped to reveal exist-

ing weak points and modify the interview questions

in case of necessity.

3.4 Interview Process

The 30 interviews with the representatives of the com-

panies were conducted during 6 weeks period each

taking on average 20 minutes. Interviews were face-

to-face ofﬂine or online using Skype video call de-

pending on the accessibility of the respondents to the

authors. All the interviews were recorded on a voice

recorder with the permission of the respondents. In

order to establish comfortable atmosphere that could

let respondents go beyond the question borders and

give unique phenomenon in the area, it was decided

not to take notes directly during the interview. The

notes were taken after the interview based on the

record. The very ﬁrst interview was conducted as a

test interview, checking applicability of the question-

naire to the process and relevance of the questions and

the test interview is not included in the results of the

survey. As a result of the test interview, a few updates

were made on the questionnaire and before its ﬁnal

form.

Interview transcripts were analysed based on the

Google voice-to-text extension and pattern coding

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

142

Table 1: Scope of the Respondents Work Projects (Products).

ID Product Type Industry Sector

R1 Inner bank product for the bank employees Communication System

R2 Internal technological platform for the product teams of the com-

pany

Communication System

R3 Virtual analytics AI, Machine Learning

R4 Music streaming platform Search engine

R5 Marketplace Retail

R6 Product for inner use in the group of companies Communication System

R7 Product for the inner use of the employees to control and manage

customer accounts

Management System

R8 Checks scanning application

R9 Robots for houses/apartments construction Robotics

R10 Online cashbox Trading

R11 Inner bank product for the bank employees Banking

R12 Mobile games Gaming

R13 Bank software for legal entities, retail paying system for Individuals Banking

R14 Platform for the work of distributed teams, AI agents Banking

R15 Saas product to work with geo-data Geo-information system

R16 Cloud geo-information system Geo-information system

R17 Platform for the ministry of ecology to reveal violations in the nature Geo-information system

R18 Inner digital platform for bank Communication System

R19 Robots Robotics

R20 Software products delivery Service

R21 Inner bank product for the bank employees Communication System

R22 Contact center (operator assistant app) Management System

R23 Digital solutions for airlines Management System

R24 Platform for HRs to make ofﬁce corporate bonuses customizable

and motivate employees

Management System

R25 B2B platform for the ﬁsh retail Retail

R26 Portal for the communication with the company partners Communication System

R27 Dispatching system for autonomous vehicles Robotics, AI & Machine Learning

R28 Voice recognition, artiﬁcial intelligence AI & Machine Learning

R29 Chatbots AI

R30 Autonomous computer vision trafﬁc analysis system AI, Machine Learning

with the help of manual notes of the Interviewee. The

challenges encountered in the process of pattern cod-

ing as a ﬁnal step of the qualitative analysis is de-

scribed in Section 4.1.

3.5 Questionnaire Construction

In the challenging process of creation of an effective

survey, the way how the questions are deﬁned, orga-

nized and put in the context can inﬂuence the results

of the survey signiﬁcantly. To address these limita-

tions we followed the rules suggested in the literature

(Basili, 1992; Basili et al., 1994; Bond and Fox, 2013;

Empirical Research on Customer Communication Challenges in the Companies Adopting Agile Practices

143

Vannette and Krosnick, 2014; Krosnick and Presser,

2010; Lietz, 2008; Thayer-Hart et al., 2010). Be-

sides,the usage the approach helped us to avoid re-

dundancy and replication and leading questions dur-

ing the interview sessions. In particular, we put a sig-

niﬁcant attention in preventing biases in the responses

and conﬁrmation, based on the approach described in

(Furnham, 1986; Podsakoff et al., 2003).

The ﬁrst part of the questionnaire contains back-

ground questions to know the environment of the case

that is studied - to get the information about the re-

spondents and the company. This part of the ques-

tionnaire is mainly consists of the single-choice ques-

tions because such background research requires di-

rect and unambiguous answers. However, ”Product

scope” questions require plain text answers. As far as

the respondents work on a different and variety num-

bers of the products that requires more information

and particular details.

The second part of the questionnaire consists of

several questions about the way they organize the cus-

tomer collaboration and about the agile RE activities

. There are also single-choice questions with the im-

plementation of Likert-Type Scale answer choice.

And, ﬁnally, the Third part consists of general

free-from questions to ﬁnd out about the challenges

encountered during the work and the way customers

handle the problems.

3.6 Research Validity

As in any survey, there are threats in our survey to the

external validity. The main question lies on the de-

gree of our representatives responsiveness. To address

this thread and increase the external validity of our

ﬁndings, we followed the best practices suggested in

the literature (Szolnoki and Hoffmann, 2013; Khazaal

et al., 2014; Maalej et al., 2014).

To provide an overall validation framework for

the research, we used the 4 design tests by (Yin,

2009). Results of the application of the design tests

are shown in the Table 2.

4 RESULTS

In the scope of the research study, we contacted 40

Product Owners and Product Managers from 30 com-

panies adopting Agile methodology practises. Out of

overall 40 contacted representatives only 30 of them

responded from 20 different ﬁrms.

The distribution of the company representatives

roles involved in the research study can be described

as following: 17 of the representatives are Product

Owners (PO), 10 - Product Managers (PM), 2 - CTOs

and 1 - CEO (see in Fig. 1). 2 CTOs and 1 CEO repre-

sent 3 Startups in the starting phase and/or transition-

ing to another business model. The limitation accord-

ing to these companies is that the roles of PO/PM are

not speciﬁcally established for the employee because

of the limited number of employees in the team.

Figure 1: Distribution of the roles.

There were generated a particular situation during

the investigation of the case. As far as most of the

teams are small-sized that fully seizes agile concept of

the team. 24 representatives of the survey participants

mentioned their team size from 1-10 people, whereas

3 of them stated their team size 10-20 and only 3 of

them has team with size of 20 and more (See Figure

2) One of the most inﬂuencing data for the result was

the information derived from the company represen-

tatives who were in the Chef positions, had more than

20 team members and several teams at the same time.

We considered all the subordinates of their branch as

a single uniﬁed team.

Figure 2: Distribution of the size of the teams.

Project teams are transformed into product teams

due to adoption of agile practices (see Figure 3).

As it was deﬁned from the research, Scrum is the

methodology adopted by the majority of our respon-

dents. Besides, there are may studies related to the

effective Scrum teams such as (Matharu et al., 2015).

Despite the fact that the number of our representatives

from the companies consisted 30, while their number

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

144

Table 2: Case study tactics for 4 design tests.

Tests Case study tactic Phase of research in which

tactic occurs

Application to the current

research

Construct Use multiple sources of evidence Data collection Applied

validity Establish chain of evidence Data collection Applied

Have key informants review draft case study re-

port

Composition Applied

Internal Do pattern-matching Data analysis Applied

validity Do explanation building Data analysis Applied

Do time-series analysis Data analysis To be done in future re-

searches

External

validity

Use replication logic in multiple case studies Research design Not Applied

Reliability Use case study protocol Data collection Applied

Develop case study database Data collection Applied

Figure 3: Distribution of the team types.

of methodologies adopted exceeded their number. So

we can claim that every company can adopt and im-

plement more than one methodology into their system

(see Figure 4). According to their results we can sum-

marize their methodologies used in the Table 3

Figure 4: Distribution of the Agile methodologies used in

the respondents team.

According to the practises of the interviewees the

Products Owners and Products Managers are the ones

who most of time (96,7%) directly communicate with

the customer rather than the other team members in

the company (see Figure 5).

Figure 5: PO/PMs direct communication with the customer.

Although the major part of the communication

with the customer is conducted by the Product Own-

ers, Project Managers, it is inevitable that the devel-

opment team also needs direct involvement of cus-

tomers to understand the customer needs fully. Direct

involvement of the customer during the Requirements

Engineering phase provides the transparency and im-

prove the understanding of the requirements. How-

ever, the direct involvement of the customer in the

process is not popular practise among the participants

of our survey as it can be seen from the Figure 6.

Although the face-to-face and live communication

with the customer during the RE process is the most

efﬁcient way, nevertheless there are also possibilities

to interact with the customer such as internet and on-

line meeting. Almost all of the participants of our sur-

vey mentioned the face-to-face communication one of

the ways when there is the least distortion of informa-

Empirical Research on Customer Communication Challenges in the Companies Adopting Agile Practices

145

Table 3: Number of used methodologies per representative.

Scrum 10

Modiﬁed Scrum 13

Kanban 4

No particular methodology but the combination of agile practices 4

Scaled Agile 3

Disciplined Agile (DAD) 2

Do not apply any methodology 2

Figure 6: Customer collaboration with the development

team during the requirements engineering phase.

tion. The Figure 7 shows the number of participants

who uses the communication methods for teams col-

laboration with the customers during the RE process.

Figure 7: Communication Channels Distribution.

The interview revealed also the controversial

points where the communication of the team with the

customer can be discouraged in some particular cases

such as:

1. Situation 1

• It is better to isolate business customers

from internal development processes, espe-

cially when customers do not have technical

background. Product Owner is the only one

person in a team who communicates to the cus-

tomer in this case.

• In this case, the customers needs to communi-

cate closely to the team and participate in all

the activities.

2. Situation 2

• POs, PMs should have technical background in

order to communicate effectively with the team

and be able to form requirements efﬁciently.

• If POs, PMs do not have technical background,

in this case, they need to get an expertise from

the developers to form adequate requirements.

4.1 Challenges

In the result of the research survey, there were derived

many challenges coming out of the customer collabo-

ration speciﬁcally during the Requirements Engineer-

ing process in the project. The challenges mentioned

by the participants of the interview sessions include

much more details. Nonetheless, they were incorpo-

rated into the general groups according to their cate-

gories of the problem (see Table 4 )

4.2 Solutions Suggested

Experience of the challenges in the communication

with the customer lead to deﬁning some solutions

to these challenges from the participants. This sub-

section includes the suggested solutions for the chal-

lenges encountered by the participants of the survey.

Most of the suggested solutions the representatives

were trying to implement into the project. The sug-

gested solutions for the PM/PO and managers include

the followings:

1. PO/PM can write down the best practices for the

developers, so that they will be ready for the cus-

tomer collaboration with the help of special cus-

tomer collaboration training so both of them could

form proper requirements.

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

146

Table 4: Challenges encountered during RE process in collaboration with the customer.

# Description of the challenges

1 Excessive expertise of the developers, PO/PM. They need to simplify the language they speak to make cus-

tomers understand what they explain.

2 Developers are separated from requirements engineering. That is why they are far from understanding of the

user needs.

3 Customers do not agree on product vision. Different interpretation of the same things, different design view

(UX and scenarios). Customers insists on their literally non-correct view. As an example, customers think that

developers are just code writers and do not have product vision. But, in fact, developers are experts in product.

4 Development team do not want to be aware of business part. Customers do not want to collaborate with a team.

5 Big number of users to be analyzed in order to form hypotheses for customers.

6 Customers are pressed by PO/PM’s and developers’ suggestions and refused from what they wanted. As a

result, end-product differs from their expectations.

7 Customers are not ﬂexible and require deadlines. They are often not available, team creates features as it thinks

that is correct. Customers do not want to go to demos, meetings, get in touch with a team randomly, when it’s

convenient for them. Customers do minimum what team asks from them. (E.g., they were asked to perform

user testing, they tested only 1 person).

8 Project (product) requirements approval takes a long time, company jurists approve everything very slowly.

When customers are big organizations with a lot of departments, solutions are taken on several steps and often

time-prolonged.

9 Lack of common information model for requirements related activities. Need in establishing one universal

communication/process standard.

10 After customers ex-representative is ﬁred, it takes quite a long for new representative to understand previously

elicited requirements.

11 Customer reproaches PO/PM for ex-PO/PM mistakes.

12 Too big number of customers that leads to too diverse and controversial requirements. Customers think every-

thing is easy to implement so they form not adequate requirements. Customers are not relevant even with the

non-technical scope of the software under development.

13 Developed requirements differ from product to test. Testability of the requirements is not provided in advance.

2. PO/PM can involve the developers in Require-

ments Engineering process to get common under-

standing of what the customer wants (applicable

for the case when only PO/PM is responsible for

working with the requirements).

3. To try to ﬁnd consensus with customer in case of

different product/feature vision. Suggest alterna-

tives. Use the facts to encourage the customer to

come to a compromise.

4. To make more universal feedback form with

checkbooks, automated visualization, in case of

more than one customer is involved.

5. To isolate customers from technical speciﬁcation,

terms and notation and ask more business related

questions to form the requirements.

6. To explain everything in the language of cus-

tomers involving analysts into the activity.

7. To generate the proper planning for the customer

meetings. In case of the long project approval ses-

sions, together with developers to ﬁnd the extreme

cases, possible mistakes and failures. And then

with the ready solutions set collaborate with the

customer.

8. To have more communication with the end users

and get more information about the expectations

from the system.

9. To rearrange the Requirements Engineering pro-

cess, in case current one did not work.

10. To introduce step-by-step Requirements Engi-

neering activities suggested by Agile methodolo-

gies. Besides, to work with the customers con-

tinuously to introduce and experience Agile prac-

tises to the customer.

11. To develop personal patience, building emotional

stability during the communication with the cus-

tomer.

5 CONCLUSIONS

Requirements engineering in agile takes its most efﬁ-

cient form comparing to traditional development. Ac-

cording to communication channels efﬁciency model

suggested by Alistair Cockburn, 2 most efﬁcient and

rich channels are considered such as face-to-face

communication with and without whiteboard (Cock-

burn, 2002). That is why all important moments in

Empirical Research on Customer Communication Challenges in the Companies Adopting Agile Practices

147

the Requirements engineering process should be dis-

cussed directly with the customer as it is implied in

Agile. The paper reviewed the existing literature and

work done in this area, proposed a methodology to

organize and conduct an interview session, and dis-

cussed the results of the interviews.

According to our survey which was done in the

context of identifying the Requirements Engineering

process challenges with the customer communication

in Agile practises adopting companies any problems

were deﬁned. The survey involved participants from

the different complexity and different size companies

which are located in three cities of Russian Federation

- Innopolis, Kazan and Moscow. The participants are

PO, PM, CTO, CEOs of the companies under con-

sideration. 30 representatives of the 20 companies

work in several teams with different sized teams and

methodologies applied in the company. The survey

derived many challenges which can be encountered

during the Requirements Engineering process and so-

lutions for the PM/PO’s to ease and minimize the is-

sues with the customer collaboration during RE pro-

cess.

The main constraint in the survey was that the

company representatives rarely share their internal

problem publicly. They share their best practices as

well as bad experiences which they managed to turn

into success or consider as a good lesson. Very few

of the companies can share the current situation and

problems. This, as a rule, has a form of insider in-

formation. The conducted research allowed us to an-

alyze particular qualities of the communication ﬁeld

in the context of rapidly changing Software Develop-

ment environment. There is a need in further work

on formation of the communication patterns from de-

scribed challenges and solutions in the ﬁeld of RE.

Moreover, it would be also extremely important and

interesting to consider the case of Open Source devel-

opment processes (Succi et al., 2001b; Kov

acs et al.,

2004; Paulson et al., 2004; Rossi et al., 2010; Petrinja

et al., 2010; Fitzgerald et al., 2011; Rossi et al., 2012;

Di Bella et al., 2013), which are strictly related to ag-

ile methods. Also the mobile market would be very

interesting to analyse, given its constant and very fast

evolution (Moser et al., 2008a; Corral et al., 2011;

Corral et al., 2013; Corral et al., 2014; Corral et al.,

2015). Finally, this research has been developed in

the context of Russian Software Development com-

panies, and in further research the practitioners form

other countries will be also considered.

ACKNOWLEDGEMENTS

This research project is carried out under the support

of the Russian Science Foundation Grant No 19-19-

00623.

REFERENCES

Abdullah, N. N. B., Honiden, S., Sharp, H., Nuseibeh, B.,

and Notkin, D. (2011). Communication patterns of

agile requirements engineering. pages 1:1–1:4.

Baruah, N. (2015). Requirement management in agile soft-

ware environment. Procedia Computer Science, 62:81

– 83. Proceedings of the 2015 International Confer-

ence on Soft Computing and Software Engineering

(SCSE’15).

Basili, V. R. (1992). Software modeling and measurement:

the goal/question/metric paradigm.

Basili, V. R., Caldiera, G., and Rombach, H. D. (1994). The

goal question metric approach. In Encyclopedia of

Software Engineering. Wiley.

Bellucci, A., Jacucci, G., Kotkavuori, V., Serim, B., Ahmed,

I., and Ylirisku, S. (2015). Extreme co-design: Proto-

typing with and by the user for appropriation of web-

connected tags. In D

ıaz, P., Pipek, V., Ardito, C.,

Jensen, C., Aedo, I., and Boden, A., editors, End-User

Development, pages 109–124, Cham. Springer Inter-

national Publishing.

Bjarnason, E., Wnuk, K., and Regnell, B. (2011). A case

study on beneﬁts and side-effects of agile practices in

large-scale requirements engineering. In Proceedings

of the 1st Workshop on Agile Requirements Engineer-

ing, AREW ’11, pages 3:1–3:5, New York, NY, USA.

ACM.

Bond, T. G. and Fox, C. M. (2013). Applying the Rasch

model: Fundamental measurement in the human sci-

ences. Psychology Press.

Cao, L. and Ramesh, B. (2008). Agile requirements engi-

neering practices: An empirical study. IEEE Software,

25(1):60–67.

Clark, J., Clarke, C., De Panﬁlis, S., Granatella, G., Predon-

zani, P., Sillitti, A., Succi, G., and Vernazza, T. (2004).

Selecting components in large cots repositories. Jour-

nal of Systems and Software, 73(2):323–331.

Cockburn, A. (2002). Agile Software Development.

Addison-Wesley Longman Publishing Co., Inc.,

Boston, MA, USA.

Coman, I. D., Robillard, P. N., Sillitti, A., and Succi,

G. (2014). Cooperation, collaboration and pair-

programming: Field studies on backup behavior.

Journal of Systems and Software, 91:124–134.

Corral, L., Georgiev, A. B., Sillitti, A., and Succi, G. (2013).

A method for characterizing energy consumption in

Android smartphones. In Green and Sustainable Soft-

ware (GREENS 2013), 2nd International Workshop

on, pages 38–45. IEEE.

Corral, L., Georgiev, A. B., Sillitti, A., and Succi, G. (2014).

Can execution time describe accurately the energy

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

148

consumption of mobile apps? An experiment in An-

droid. In Proceedings of the 3rd International Work-

shop on Green and Sustainable Software, pages 31–

37. ACM.

Corral, L., Sillitti, A., and Succi, G. (2015). Software As-

surance Practices for Mobile Applications. Comput-

ing, 97(10):1001–1022.

Corral, L., Sillitti, A., Succi, G., Garibbo, A., and Ramella,

P. (2011). Evolution of Mobile Software Development

from Platform-Speciﬁc to Web-Based Multiplatform

Paradigm. In Proceedings of the 10th SIGPLAN Sym-

posium on New Ideas, New Paradigms, and Reﬂec-

tions on Programming and Software, Onward! 2011,

pages 181–183, New York, NY, USA. ACM.

Di Bella, E., Sillitti, A., and Succi, G. (2013). A multivari-

ate classiﬁcation of open source developers. Informa-

tion Sciences, 221:72–83.

Dragicevic, S., Celar, S., and Novak, L. (2014). Use

of method for elicitation, documentation, and valida-

tion of software user requirements (medov) in agile

software development projects. In 2014 Sixth Inter-

national Conference on Computational Intelligence,

Communication Systems and Networks, pages 65–70.

Fitzgerald, B., Kesan, J. P., Russo, B., Shaikh, M., and

Succi, G. (2011). Adopting open source software: A

practical guide. The MIT Press, Cambridge, MA.

Furnham, A. (1986). Response bias, social desirability and

dissimulation. Personality and individual differences,

7(3):385–400.

Inayat, I., Salim, S. S., Marczak, S., Daneva, M., and

Shamshirband, S. (2015). A systematic literature re-

view on agile requirements engineering practices and

challenges. Comput. Hum. Behav., 51(PB):915–929.

Janes, A. and Succi, G. (2014). Lean Software Development

in Action. Springer, Heidelberg, Germany.

K Yin, R. (2003). A Review of Case Study Research: Design

and Methods, volume 5, page 219.

Khazaal, Y., van Singer, M., Chatton, A., Achab, S.,

Zullino, D., Rothen, S., Khan, R., Billieux, J., and

Thorens, G. (2014). Does self-selection affect sam-

ples’representativeness in online surveys? an investi-

gation in online video game research. Journal of Med-

ical Internet Research, 16(7):e164.

Kivi, J., Haydon, D., Hayes, J., Schneider, R., and Succi,

G. (2000). Extreme programming: a university team

design experience. In 2000 Canadian Conference

on Electrical and Computer Engineering. Confer-

ence Proceedings. Navigating to a New Era (Cat.

No.00TH8492), volume 2, pages 816–820 vol.2.

Kov

acs, G. L., Drozdik, S., Zuliani, P., and Succi, G.

(2004). Open Source Software for the Public Ad-

ministration. In Proceedings of the 6th Interna-

tional Workshop on Computer Science and Informa-

tion Technologies.

Krosnick, J. A. and Presser, S. (2010). Question and

questionnaire design. Handbook of survey research,

2:263–314.

Lethbridge, T. C., Sim, S. E., and Singer, J. (2005). Study-

ing software engineers: Data collection techniques for

software ﬁeld studies. Empirical Software Engineer-

ing, 10:311–341.

Lietz, P. (2008). Questionnaire design in attitude and opin-

ion research: Current state of an art. Citeseer.

Liskin, O., Schneider, K., Fagerholm, F., and M

unch, J.

(2014). Understanding the role of requirements ar-

tifacts in kanban. In Proceedings of the 7th Interna-

tional Workshop on Cooperative and Human Aspects

of Software Engineering, CHASE 2014, pages 56–63,

New York, NY, USA. ACM.

Maalej, W., Tiarks, R., Roehm, T., and Koschke, R. (2014).

On the comprehension of program comprehension.

ACM Trans. Softw. Eng. Methodol., 23(4):31:1–31:37.

Marino, G. and Succi, G. (1989). Data Structures for Par-

allel Execution of Functional Languages. In Pro-

ceedings of the Parallel Architectures and Languages

Europe, Volume II: Parallel Languages, PARLE ’89,

pages 346–356. Springer-Verlag.

Matharu, G. S., Mishra, A., Singh, H., and Upadhyay, P.

(2015). Empirical study of agile software develop-

ment methodologies: A comparative analysis. SIG-

SOFT Softw. Eng. Notes, 40(1):1–6.

Maurer, F., Succi, G., Holz, H., K

otting, B., Goldmann, S.,

and Dellen, B. (1999). Software Process Support over

the Internet. In Proceedings of the 21st International

Conference on Software Engineering, ICSE ’99, pages

642–645. ACM.

Moser, R., Pedrycz, W., and Succi, G. (2008a). A Compara-

tive Analysis of the Efﬁciency of Change Metrics and

Static Code Attributes for Defect Prediction. In Pro-

ceedings of the 30th International Conference on Soft-

ware Engineering, ICSE 2008, pages 181–190. ACM.

Moser, R., Pedrycz, W., and Succi, G. (2008b). Analysis of

the reliability of a subset of change metrics for defect

prediction. In Proceedings of the Second ACM-IEEE

International Symposium on Empirical Software En-

gineering and Measurement, ESEM ’08, pages 309–

311. ACM.

Mus

ılek, P., Pedrycz, W., Sun, N., and Succi, G. (2002).

On the Sensitivity of COCOMO II Software Cost Es-

timation Model. In Proceedings of the 8th Interna-

tional Symposium on Software Metrics, METRICS

’02, pages 13–20. IEEE Computer Society.

Myers, M. D. and Newman, M. (2007). The qualitative in-

terview in is research: Examining the craft. Informa-

tion and Organization, 17(1):2 – 26.

Olsson, H. H. and Bosch, J. (2015). Towards continuous

customer validation: A conceptual model for com-

bining qualitative customer feedback with quantitative

customer observation. In ICSOB.

Paetsch, F., Eberlein, A., and Maurer, F. (2003). Require-

ments engineering and agile software development.

pages 308–313.

Paulson, J. W., Succi, G., and Eberlein, A. (2004). An em-

pirical study of open-source and closed-source soft-

ware products. IEEE Transactions on Software Engi-

neering, 30(4):246–256.

Pedrycz, W., Russo, B., and Succi, G. (2011). A model

of job satisfaction for collaborative development pro-

Empirical Research on Customer Communication Challenges in the Companies Adopting Agile Practices

149

cesses. Journal of Systems and Software, 84(5):739–

752.

Pedrycz, W., Russo, B., and Succi, G. (2012). Knowledge

transfer in system modeling and its realization through

an optimal allocation of information granularity. Appl.

Soft Comput., 12(8):1985–1995.

Pedrycz, W. and Succi, G. (2005). Genetic granular classi-

ﬁers in modeling software quality. Journal of Systems

and Software, 76(3):277–285.

Petrinja, E., Sillitti, A., and Succi, G. (2010). Compar-

ing OpenBRR, QSOS, and OMM assessment models.

In Open Source Software: New Horizons - Proceed-

ings of the 6th International IFIP WG 2.13 Confer-

ence on Open Source Systems, OSS 2010, pages 224–

238, Notre Dame, IN, USA. Springer, Heidelberg.

Pikkarainen, M., Haikara, J., Salo, O., Abrahamsson, P.,

and Still, J. (2008). The impact of agile practices on

communication in software development. Empirical

Software Engineering, 13(3):303–337.

Podsakoff, P., MacKenzie, S., Lee, J., and Podsakoff, N.

(2003). Common method biases in behavioral re-

search: A critical review of the literature and recom-

mended remedies.

Robson, C. (2002). Real world research : A resource for so-

cial scientists and practitioner-researchers / c. robson.

Ronchetti, M., Succi, G., Pedrycz, W., and Russo, B.

(2006). Early estimation of software size in object-

oriented environments a case study in a cmm level 3

software ﬁrm. Information Sciences, 176(5):475–489.

Rossi, B., Russo, B., and Succi, G. (2010). Modelling Fail-

ures Occurrences of Open Source Software with Reli-

ability Growth. In Open Source Software: New Hori-

zons - Proceedings of the 6th International IFIP WG

2.13 Conference on Open Source Systems, OSS 2010,

pages 268–280, Notre Dame, IN, USA. Springer, Hei-

delberg.

Rossi, B., Russo, B., and Succi, G. (2012). Adoption of

free/libre open source software in public organiza-

tions: factors of impact. Information Technology &

People, 25(2):156–187.

Runeson, P. and H

ost, M. (2009). Guidelines for conduct-

ing and reporting case study research in software engi-

neering. Empirical software engineering, 14(2):131–

164.

Schn, E.-M., Thomaschewski, J., and Escalona, M. J.

(2017). Agile requirements engineering: A systematic

literature review. Computer Standards & Interfaces,

49:79 – 91.

Scotto, M., Sillitti, A., Succi, G., and Vernazza, T. (2004). A

Relational Approach to Software Metrics. In Proceed-

ings of the 2004 ACM Symposium on Applied Comput-

ing, SAC ’04, pages 1536–1540. ACM.

Scotto, M., Sillitti, A., Succi, G., and Vernazza, T. (2006). A

non-invasive approach to product metrics collection.

Journal of Systems Architecture, 52(11):668–675.

Sillitti, A., Ceschi, M., Russo, B., and Succi, G. (2005).

Managing uncertainty in requirements: a survey

in documentation-driven and agile companies. In

11th IEEE International Software Metrics Symposium

(METRICS’05), pages 10 pp.–17.

Sillitti, A., Janes, A., Succi, G., and Vernazza, T. (2004).

Measures for mobile users: an architecture. Journal

of Systems Architecture, 50(7):393–405.

Sillitti, A., Succi, G., and Vlasenko, J. (2012). Understand-

ing the Impact of Pair Programming on Developers

Attention: A Case Study on a Large Industrial Exper-

imentation. In Proceedings of the 34th International

Conference on Software Engineering, ICSE ’12, pages

1094–1101, Piscataway, NJ, USA. IEEE Press.

Sillitti, A., Vernazza, T., and Succi, G. (2002). Service

Oriented Programming: A New Paradigm of Software

Reuse. In Proceedings of the 7th International Con-

ference on Software Reuse, pages 269–280. Springer

Berlin Heidelberg.

Succi, G., Benedicenti, L., and Vernazza, T. (2001a). Anal-

ysis of the effects of software reuse on customer sat-

isfaction in an RPG environment. IEEE Transactions

on Software Engineering, 27(5):473–479.

Succi, G., Paulson, J., and Eberlein, A. (2001b). Prelim-

inary results from an empirical study on the growth

of open source and commercial software products. In

EDSER-3 Workshop, pages 14–15.

Succi, G., Pedrycz, W., Marchesi, M., and Williams, L.

(2002). Preliminary analysis of the effects of pair pro-

gramming on job satisfaction. In Proceedings of the

3rd International Conference on Extreme Program-

ming (XP), pages 212–215.

Szolnoki, G. and Hoffmann, D. (2013). Online, face-to-face

and telephone surveys – comparing different sampling

methods in wine consumer research. Wine Economics

and Policy, 2(2):57 – 66.

Thayer-Hart, N., Dykema, J., Elver, K., Schaeffer, N., and

Stevenson, J. (2010). Survey fundamentals: A guide

to designing and implementing surveys. Ofﬁce of

Quality Improvement.

Valerio, A., Succi, G., and Fenaroli, M. (1997). Domain

analysis and framework-based software development.

SIGAPP Appl. Comput. Rev., 5(2):4–15.

Vannette, D. L. and Krosnick, J. A. (2014). Answering

Questions: A Comparison of Survey Satisﬁcing and

Mindlessness, pages 312–327. John Wiley & Sons,

Ltd.

Vernazza, T., Granatella, G., Succi, G., Benedicenti, L.,

and Mintchev, M. (2000). Deﬁning Metrics for Soft-

ware Components. In Proceedings of the World Mul-

ticonference on Systemics, Cybernetics and Informat-

ics, volume XI, pages 16–23.

Yin, R. (2009). Case Study Research: Design & Methods,

volume 5.

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

150