Empirical Research on Customer Communication Challenges in the
Companies Adopting Agile Practices
Paolo Ciancarini
2 a
, Shokhista Ergasheva
1 b
, Ilyuza Gizzatullina
1
, Vladimir Ivanov
1 c
,
Sergey Masyagin
1 d
and Giancarlo Succi
1 e
1
Innopolis University, Innopolis, Russia
2
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 defining 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 field in the context of rapidly changing
Software Development environment helped to define 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-
a
https://orcid.org/0000-0002-7958-9924
b
https://orcid.org/0000-0003-0241-5640
c
https://orcid.org/0000-0003-3289-8188
d
https://orcid.org/0000-0002-6010-8764
e
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
specifications 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 deficient 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
Copyright
c
2021 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
139
process. It includes the definition 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) identifies 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 definition, implementation
and testing phases, (3) Integrated Requirements Engi-
neering, where both requirements definition and doc-
umentation is done simultaneously with design and
development phase, (4) Gradual and Iterative Detail-
ing of requirements refinement 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 significant 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 difficulties 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 influences directly
on overall customer collaboration process during
further requirements engineering activities result-
ing in not so well-defined 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, modified Scrum and an exploitation of ag-
ile practices with no definite methodology, high-
light the existing procedure, find 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 figure out usual
algorithm of events.
3.2 Research Questions
To proceed with the research study we defined 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 field. 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 first 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 flex-
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 find out more relevant information
generating natural environment during the interview
session (Myers and Newman, 2007).
The scientific 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
first interview session outcomes the final 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 modified 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 offline 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 first 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 final
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 office corporate bonuses customizable
and motivate employees
Management System
R25 B2B platform for the fish 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, artificial intelligence AI & Machine Learning
R29 Chatbots AI
R30 Autonomous computer vision traffic 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 final 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 defined, orga-
nized and put in the context can influence the results
of the survey significantly. 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-
nificant attention in preventing biases in the responses
and confirmation, based on the approach described in
(Furnham, 1986; Podsakoff et al., 2003).
The first 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, finally, the Third part consists of general
free-from questions to find 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
findings, 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 firms.
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 specifically 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 influencing 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 unified 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 defined 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
efficient 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
Modified 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 efficiently.
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 specifically 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 defining 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 flexible 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 fired, 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 find 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 specification,
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 find 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 effi-
cient form comparing to traditional development. Ac-
cording to communication channels efficiency model
suggested by Alistair Cockburn, 2 most efficient 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 defined. 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 field
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 field 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 benefits 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 Panfilis, 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-Specific to Web-Based Multiplatform
Paradigm. In Proceedings of the 10th SIGPLAN Sym-
posium on New Ideas, New Paradigms, and Reflec-
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 classification 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 field 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 Efficiency 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-
fiers 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 firm. 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. Office 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 Satisficing and
Mindlessness, pages 312–327. John Wiley & Sons,
Ltd.
Vernazza, T., Granatella, G., Succi, G., Benedicenti, L.,
and Mintchev, M. (2000). Defining 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