A Perspective from Large vs Small Companies Adoption of Agile

Methodologies

Manuela Petrescu

and Simona Motogna

Department of Computer Science, Babes Bolyai University, Cluj-Napoca, Romania

Keywords:

Agile, Small Companies, Start-Ups, Survey, Adapt, Challenges, Large, Adoption, Adaptation.

Abstract:

To offer a perspective from large versus small companies’ adoption of Agile Methodologies we performed a

study in which we discussed and analyzed the answers of 31 interviewees from 14 companies. We carefully se-

lected the data set to be representative for all the actors in the market from the company’s size, business model,

role balance, and gender balance. We found out that most of the companies adopted the Agile methodologies

in a more or less extensive manner. By far, the most used ceremony was daily meetings, other ceremonies

were sometimes merged or removed from the methodology implementation. We also investigate how compa-

nies adopted the Agile mindset by analyzing how the Agile Manifesto was implemented in these companies,

even if it was not in the scope of our study. From a scientiﬁc point of view, this study contributes from a

methodological perspective to a better understanding of Agile adoption in different types of companies and of

the challenges related to Agile practices and processes. For practitioners, the results presented in this paper

offer evaluation means and solutions for Agile adoption.

1 INTRODUCTION

As the applications become more complex, new

methodologies emerged to fasten delivery. Agile ap-

peared as a response to different requirements that

could not be fulﬁlled through plan-driven methodolo-

gies. Agile methodology started to be widely used be-

cause it offers more ﬂexibility and responsiveness to

change; it offers support to continuous changes and

delivery, even if it has its own downsides (Brown,

2013). SCRUM, XP (Extreme Programming), and

FDD (Feature Driven Development) methodologies

imposed themselves and are analyzed and compared

in different papers (Akhtar et al., 2022; Saleh et al.,

2019).

In our opinion, small companies are the engines

for innovation, they are forced to bring new ideas,

and new approaches to survive and to get a market

share. They are more dynamic and ﬂexible, being

able to change processes on the run much faster com-

pared to large-scale companies. The key to future de-

velopment approaches is to analyze how software de-

velopment start-ups are implementing Agile method-

ologies. Knowing how small companies adopt Agile

https://orcid.org/0000-0002-9537-1466

https://orcid.org/0000-0002-8208-6949

Methodologies compared to medium and large com-

panies provide useful information for other compa-

nies doing business in the same sector. Thus, the mo-

tivation of this paper is strongly related to the busi-

ness environment and the paper could provide useful

information to other companies working in the same

business domain.

The transition of IT projects to agile practice is

not always easy (Burga et al., 2022); large com-

panies faced issues in adopting Agile in the devel-

opment process (Klunder et al., 2019) and startups

use a hybrid method - Agile and Waterfall (Mishra

et al., 2021). Some research was conducted related

to various topics for Agile adoption in start-ups: the

use of Agile practices (Souza et al., 2019), internal

communication (Gonz

alez-Cruz et al., 2020), process

metrics usage (Choras et al., 2020). This study ad-

dresses a new perspective: how the small companies

adapted the team structure, the roles, the processes in

the SCRUM teams, and the challenges they faced in

adopting and adapting Agile methodologies. Despite

the maturity of Agile practices and the considerable

number of research contributions, there are organiza-

tional aspects that need a deeper understanding: (i)

adaptation of Agile practices and (ii) challenges faced

by the organization during the implementation of the

Agile framework. This study aims at comparatively

Petrescu, M. and Motogna, S.

A Perspective from Large vs Small Companies Adoption of Agile Methodologies.

DOI: 10.5220/0011716800003464

In Proceedings of the 18th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2023), pages 265-272

ISBN: 978-989-758-647-7; ISSN: 2184-4895

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

265

responding to these open issues, by exploring differ-

ences between large and small companies. We use

empirical methods, starting with interviews of people

with management roles to ﬁnd out the company’s ap-

proach, then we used open coding to process the ob-

tained data and to produce a qualitative analysis. The

paper is structured as follows: Preliminaries and Re-

lated Work sections analyze the current studies, and

the Data collection and analysis section describes how

we obtained and analyzed the data. Results are de-

tailed in the Findings through empirical investigation

section, and we conclude in the Conclusions and fu-

ture work section.

2 PRELIMINARIES

Agile addresses some of the waterfall methodology

issues as it adapts to requirements changes, offer-

ing a ﬂexible development approach focused on cus-

tomer satisfaction and team involvement. The val-

ues and principles of the Agile methodologies were

deﬁned in Agile Manifesto (Kent Beck, 2001), in

which the authors stated four core values to assure an

open-to-change process. They stated the importance

of Individuals and interactions over processes and

tools, of working software over comprehensive docu-

mentation, Customer collaboration over contract ne-

gotiation, and Responding to change over following

a plan. Several development methodologies follow

these principles, the most used being: Scrum, Kan-

ban, XP, and FDD. We decided to use the deﬁnition

for small companies provided by the Commission of

the European Communities (the European Communi-

ties, ), which states that a small enterprise has between

10 to 49 persons employed and an annual turnover of

not more than C10 million.

3 RELATED WORK

A considerable number of papers were written over

the last 20 years addressing Agile methodologies,

adoption to different domains, and case studies. In

this study, we focused on contributions related to Ag-

ile adoption in IT companies. Agile was not adopted

only in IT companies but it spread in other domains

as well, modiﬁed according to their needs and scaled

(Gerster et al., 2020). In IT it started in compa-

nies that develop speciﬁc niche software products (au-

tomotive (Katumba and Knauss, 2014) or network-

ing (Smits and Rilliet, 2011)). The authors (Smits

and Rilliet, 2011) spent six months in a center for

Agile practice adoption at Cisco Voice Technology

and they concluded that the teams should get Ag-

ile skills before ”attempting to change the Software

Development Life Cycle”. In Nokia’s case (Laanti

et al., 2011) the authors concluded that ”Agile is

here to stay” after gathering and analyzing more than

1000 answers from people working there in an Ag-

ile methodology; people mentioned a higher satis-

faction, increased quality and transparency, as ear-

lier detection of defects; 60% stated that prefer work-

ing based on agile methods. The same conclusion is

drawn from (Klunder et al., 2019) – a literature re-

view study based on 85 papers on agile transforma-

tion in large companies. The authors also proposed

an agile transformation model based on the reviewed

literature and provided an example for the automo-

tive domain. The Agile adoption success in large

companies depends on a set of factors such as com-

pany culture, support from management, change lead-

ers, prior Agile experience (Kalenda et al., 2018),

and communication style and methods (Martini and

Bosch, 2013). Adopting a new methodology raises

some challenges, mostly related to people’s resistance

to change, quality assurance concerns, and integration

with existing processes (Kalenda et al., 2018). Other

authors were interested in Agile adoption in start-ups

and small companies, what Agile methodologies are

mostly used (Souza et al., 2019), and how agile in-

ternal communication works (Gonz

alez-Cruz et al.,

2020).

According to our knowledge, most of the research

focused on Agile adoption in large companies, so we

consider that a comparison between Agile methodol-

ogy adoption in large versus small companies is an

interesting topic and the results can be used by other

actors from the same business environment.

4 DESIGN OF THE STUDY

Large companies that have a portfolio of clients ﬁnd

it easier to survive and to assure a cash ﬂow. Small

companies need to innovate, to be more ﬂexible to

client’s needs, and to adapt faster to new method-

ologies. Companies can adapt to the challenges by

changing the structure of the teams, the processes, the

people’s roles, and their attributions. In this study, we

propose to see how small companies adapted Agile

Methodologies and to perform a comparison of how

Agile methodologies are used in small companies, re-

spectively large companies adoption. In conclusion,

we answer the following questions:

A. How is the team structure adapted in small

companies? / How does the team structure differs in

small vs large companies?

ENASE 2023 - 18th International Conference on Evaluation of Novel Approaches to Software Engineering

266

B. How are the processes and the people’s roles

adapted in small vs large companies?

C. How are the challenges perceived in small

companies vs large companies?

5 DATA COLLECTION AND

ANALYSIS

We opted for an empirical investigation and we used

qualitative methods. We performed the interview

studies according to the requirements and standard

process as described in (Ralph, Paul (ed.), 2021). In

our study we had conversations with one participant

at a time, we recorded the interviews, then we applied

quantitative data analysis to the participant’s answers.

Meeting these criteria classiﬁes our study as a qualita-

tive survey according to ACM Standards (Ralph, Paul

(ed.), 2021). The major concern was that the data set

had to be representative for the selected topic. Due

to this aspect, we tried to have a highly diverse par-

ticipant set in terms of position, company, and gen-

der. We interviewed 31 people from 14 companies,

14 women and 17 men. Their position was also di-

verse: team leaders 10, product owners 3, delivery

managers 6, SM 12, chief software architect 2, and

testers 5. It was interesting to see that many of the per-

sons that were in leading positions roles (team leads,

release managers, POs) or in other roles (business an-

alyst, developer roles, testing roles) combined their

role with the scrum master and/or PO role. We de-

signed the questions and grouped them in several cat-

egories, starting with personal info, project info, and

then Agile related topics as mentioned in Table 1. As

Table 1: Interview Questions.

1. Name of the participant & Current Role

2. Experience in current role & overall working experience

3. Company Name & Type [multinational, local, national]

4. Application domain, Project theme

5. Size of the project & Size of the team

6. Development period (in terms of months, years)

7. What roles are in the Agile team?

8. Do you use Agile methodology? Which parts of the

methodology are you using and how you adapted it?

9. Please describe which are the major challenges related to

Agile methodology implementation in your team.

we wanted to investigate the software development

process in large companies compared to small com-

panies, we had to assure that the participant set is rel-

evant, and the participants that work in small versus

large companies are equally represented. There were

more than 34 hours spent in interviews and more than

52 hours spent reviewing the data and creating tran-

scripts. The data gathering process was done accord-

ing to the requirements and the standard process as

described in (Ralph, Paul (ed.), 2021). Data were col-

lected mainly as open answers to get a more profound

understanding of the processes, roles, overall func-

tioning, and to allow respondents to fully describe rel-

evant details of interest. We coded each answer with

RSx where x was the number of interview and S came

from the interviewee company size: S (small) or L

(large). We decided to use thematic analysis (Braun

et al., 2019; Kiger and Varpio, 2020) to interpret the

text, previously used in software engineering in other

studies (Motogna. et al., 2021; Petrescu et al., 2022).

6 FINDINGS THROUGH

EMPIRICAL INVESTIGATION

RQ1: How is the team structure adapted? / How does

the team structure differs in small vs large compa-

nies?

Team structure as deﬁned in the SCRUM should

consist of a Product Owner (PO), a SCRUM Mas-

ter (SM), and the SCRUM team, such that the team

has all the resources and the knowledge to be able

to deliver each sprint. Once the decision to use the

SCRUM methodology is used, people need to be al-

located to ﬁll up the roles. We asked each interviewed

person about the PO role in their team and to de-

scribe how SCRUM was implemented. We found

out that ”We changed the role responsibility (PO

tasks were taken over by Scrum Master/Team lead”

(RL31). More interviewers mentioned that the back-

log changed during the sprint without the team’s ac-

ceptance. In many cases, the PO had a hard time ne-

gotiating with the client, and most of the time the team

had to complete tasks with higher priority in the same

sprint. The interviewees mentioned that there are is-

sues with ”backlog prioritization (tasks appear with

0 priority and they need to be solved and impact the

sprint, as no tasks are taken out). The prioritization

is done by PO and BAs.” (RL17).

In our study, we found out that the structure of

the SCRUM teams is very different, it depends on the

size of the project, the project type, the client’s re-

quirements, and the involvement. For example, we

encountered the following situations for the PO role:

no explicit PO allocated (2 cases), PO assigned by

the client (12 cases), PO assigned by the develop-

ment team (11 cases), and PO shared (5 cases). In

our interviews, only one small company had a per-

son designated to do a PO role, but we had a com-

plex project in which there were 7 persons working

A Perspective from Large vs Small Companies Adoption of Agile Methodologies

267

as PO: ”We had seven POs and no SCRUM master”

(RL25). Another observation, the shared PO role ap-

peared in large companies for small teams, and there

were only two cases in a large company where the

PO role was not explicitly allocated (due to project

speciﬁcity). For the PO role, there are no signiﬁcant

Figure 1: PO Distribution in small vs large companies.

differences between large and small companies; for

SM role, the situation is different. We found out that

the SM role was more adapted to each project’s speci-

ﬁcity (size, niche):

- a person was designated only for a project in a) large

companies or b) small companies but large projects

(15 cases)

- shared SM, the same person had this role in multiple

projects (11 cases)

- no designated person (5 cases)

In the last case, the role was performed by PO, team-

lead or by different members of the team depending

on the sprint ”it was not a permanent role, for techni-

cal sprints, it was a technical person, for a sprint with

polishing, design, the role was taken by PO” (RS12).

Figure 2: SCRUM Master Distribution.

Non-Coding Roles. All teams had developers for

programming roles, and most of the teams had QA,

but as for the other roles: business analyst, DevOps,

and subject matter experts, things were more ﬂexible

and they were adapted based on the required skills,

client, and project. We found out that some roles (De-

vOps) were ﬁlled based on demand from interval re-

sources or by contracts when there was no internal re-

source: ”There was a need for technical experts (for

cloud migration)- they were request based and con-

tracted” (RS12). Business analysts or subject mat-

ter roles were sometimes fulﬁlled by PO, but in some

cases, independent contractors were hired for domain

know-how ”It depends on the problem, for a business

problem sometimes they hired a consultant” (RL24).

We found out that small companies were more

likely to ﬁnd external resources for technical roles; for

business roles (PO, SM), sometimes the client was in-

volved. Other non-coding roles (i.e. technical writer)

were not mentioned; practically, there was almost no

effort related to writing project documentation. Large

companies hired specialized personnel for documen-

tation writing, and all companies (small and large)

used internal resources when a presentation or other

internal documents had to be written. Usually, large

companies had internal resources for technical roles

such as DevOps or site engineer, allocated project

based.

Our analysis revealed the following key points:

A. There is no signiﬁcant difference in non-coding

roles between small or large companies, they rely on

external resources (usually contract based) when they

don’t have the necessary know-how. Most companies

try to use as few resources as possible for tasks such

as documentation (technical writers’ roles are men-

tioned brieﬂy only in large companies).

B. In small companies, the team structure is more

ﬂexible, as PO and SM roles are performed by

different team members; in large companies, there

are more dedicated persons to perform these roles.

RQ2: How was implemented Agile Manifesto? How

are the processes and the people’s roles adapted in

small vs large companies? We structured the answer

to this question in two parts, the ﬁrst one related to

how the principles in Agile Manifesto were adapted,

and the second related to the adaptation of processes

and people’s roles.

RQ2.1:How were adapted Agile Manifesto princi-

ples?

Individuals and Interactions over Processes and

Tools. Agile enforces interactions and teamwork over

processes or speciﬁc usage of tools. In the intervie-

wee’s perception, implementing all the ceremonies

(or most of them) introduces high costs. ”Spending

a day each fortnight it’s a lot of wasted time. ”

(RS24) or ”processes (spring deﬁning, planning,

retrospective are time-consuming – 15% time can

be consumed only on these tasks)” (R26). Some

ENASE 2023 - 18th International Conference on Evaluation of Novel Approaches to Software Engineering

268

teams modiﬁed the ceremonies, shorted, merged,

or even removed them to save time ”retrospective

and planning were in the same meeting – all in

one” (RL26). However, daily meetings were the one

ceremony that was the most present and suffered less

adaptation. Some companies kept the main idea and

tasks, but the processes and the responsibilities were

adapted, ”there was a mini squad team to review the

document” (RL11).

Working Software over Comprehensive Docu-

mentation. To have comprehensive documentation,

each team should assign people to write it. In our

interviews, none of the interviewees mentioned

technical writers, nor did they mention writing doc-

umentation tasks, client’s manuals, or other types of

documentation. Everyone’s focus was on delivering

working software and sometimes on ﬁxing and

supporting testing versions (cases when the backlog

was modiﬁed due to high-priority bugs). As all the

companies valued working software more compared

to comprehensive documentation, and the processes

were not related to the degree of Agile methodology

adoption, we believe that the approach is due more to

the business perspective, as the clients don’t accept

the costs of such comprehensive documentation.

Some clients had a hard time accepting the cost

of different development tasks, ”clients do not

understand the impact in terms of the cost of their

CRs (change requests);” (RL2).

Customer Collaboration over Contract Negoti-

ation. Customer collaboration is strong, in our study,

35% of the projects had the Product Owner named

by the client (11 projects from 31 interviewed). In

1.16% (5 of 31) projects, the client preferred not to

interfere at all in the development phase, so those

projects can be considered more contract related. The

rest of the projects had ﬂexible length sprints and the

backlog was updated based on the client’s input. In

conclusion, we can state that customer collaboration

was extensive in most of the projects (83% of them).

Responding to Change over Following a Plan.

Developing a project requires a plan, and the archi-

tecture skeleton should be in place before starting to

implement the other features. The main topic is in

fact how easily the backlog artifact can be adapted

to new requirements, to changes of prioritization,

or based on client feedback. Only 4 interviewees

mentioned that it was plan-driven development,

one interviewee did not mention it. Other intervie-

wees mentioned that there were issues due to work

overload: topics and tasks were added to the sprint

backlog during the sprint. We concluded that in most

of the projects, 83% of the total number of projects,

the methodology was to respond to change, ”support

tickets were resolved with higher priority than the

sprint tasks” (RL22), ”Agile in fact is a waterfall

split in sprints. There are deadlines, a list of features,

but the work is structured in sprints.” (RS12).

RQ2.2:How are the processes and the people’s roles

adapted in small vs large companies?

The answer to this research question is obtained

by analyzing the results obtained through open cod-

ing of the responses to question 13 (see Table 1). The

procedure followed in the coding process considered

the already existing themes/categories related to Ag-

ile methodology and project management and key-

words generated from data analysis have been clas-

siﬁed according to these themes. Two members of

the study have previous industrial experience in Agile,

one with over 15 years working in IT company, while

one member had signiﬁcant experience in Grounded

Theory application to software engineering problems.

Table 2 contains the main categories (themes) ob-

tained through coding, keywords (labels) associated

with this category, and respectively suggestive exam-

ples for these keywords. The process was applied for

all answers, regardless of the company type. We then

explore which is the distribution of these categories,

depending on the size of the company, as depicted in

Figure 3.

Figure 3: Adapting Agile in large vs. small companies.

Our analysis revealed the following key points:

A. The majority of adapting changes target the

methodology itself both for small and large compa-

nies in terms of ﬂexible ceremonies and adapted ar-

tifacts; in some cases, companies decided to drop

SCRUM in favor of Kanban. The adaptations seem

to have similar distribution for small and large com-

panies.

B. In the case of small companies, adapting Agile was

targeting people on a bigger scale than in the case of

larger companies. Having ”mixed roles” and consid-

A Perspective from Large vs Small Companies Adoption of Agile Methodologies

269

Table 2: Categories for ”Adapting SCRUM/Agile”

Category Topics Examples

Client client dependency, changes,

client only partially involved

”frequent client requirements to modify scope”, ”client

could ask for change requests during the sprint”, ”client

not present to deﬁne all subtasks”

Project project, modify scope ”was adapted depending on project needs”, ”Kanban and

Scrum are combined due to development purpose”

People team availability, human re-

sources, mixed roles

”adapted to facilitate the team”, ”roles are mixed; SM

also has other roles”

Methodology estimations, ﬂexible cere-

monies, adapted artifact,

prioritization

”board is not always well deﬁned, just add items”,

”grooming eliminated from planning”, ”long meetings,

involving many people in which one does not bring any

input/value”

Others non formal, enforce new ideas ”nothing is formalized”, ”scaled Agile framework: one

sprint for stabilization and innovation”

ering ”team availability” takes higher importance in

small companies. We might say that adapting human

resources is easier in the case of larger companies.

C. In the case of large companies, adapting changes

were generated by client requirements or speciﬁcity,

which might indicate that a larger company might

be more sensitive to client changes, while the

smaller companies will try to preserve their resources

throughout the whole lifespan.

RQ3: How are challenges perceived in small compa-

nies vs large companies?

The answer to this research question comes from

results obtained through open coding of the responses

to question 14 from Table 1, following the same ap-

proach as in the case of the previous research ques-

tion. We applied the same methodology of coding on

all answers, regardless of the company size, which re-

sulted in four categories of challenges, as presented

in Table 3. The answers were very diverse, with some

respondents nominating several challenges, and some

of them even describing actions to resolve them. The

Agile methodology poses a large range of challenges

for both small and large companies. The majority is

due to the methodology itself (≈ 51%), where esti-

mations, priorities, and planning are among the most

encountered: ”people ﬁnd it hard to do all the cere-

monies mentioned in the methodology” (RS16), ”pri-

orities that had to be changed one week to another”

(RL20), ”the estimation part as is impacted by: ur-

gent issues, new issues that must be done, or issues

that were included in the sprint but can not be done

due to external factors” (RL27).

Human resources challenges were mentioned by

(≈ 31%) of interviewees: people are sometimes not

fully allocated to a project, are not available, or is

hard to ﬁnd people with required skills: ”People chal-

lenges: ﬁnd people with required skills” (RL3). There

are cases when there is no dedicated person for a spe-

ciﬁc role, i.e. the SM role was ”adapted to facilitate

the team”. The attributes were delegated to a spe-

ciﬁc different team member ”PO did the scrum mas-

ter part”, ”roles are mixed” (RL7). Small and large

companies encountered other restrictions or speciﬁc

conditions they had to overcome: ”Nothing is formal-

ized” (RL2), ”One limitation is timezone”; to adapt:

”scaled Agile framework: one sprint for stabilization

and innovation”. They are confronted with resistance

to change ”The resistance to change is big, people

ﬁnd it hard to do all the ceremonies mentioned in the

methodology” (RS16).

Clients or contracts also played a major role. Dur-

ing the phases of a project, they intervened and mod-

iﬁed requirements or imposed a priority change in

the tasks of a sprint: ”frequent client requirements

to modify scope” (RL3), ”support tickets interfered

with the sprint” (RS23). In other projects, the clients

did not offer support or did not perform their tasks

”Client not present to deﬁne all subtasks” (RL21).

Figure 4: Challenges in large vs. small companies.

The key points regarding the challenges can be

summarized:

ENASE 2023 - 18th International Conference on Evaluation of Novel Approaches to Software Engineering

270

Table 3: Categories for ”Challenges in SCRUM/Agile”.

Category Topics Examples

Client client requirements, client re-

strictions, client interaction

”clients don’t understand the impact in terms of cost of CRs”,

”convince them about agile principles”, ”clients not answering”

Agile estimation, agile methodol-

ogy, planning, agile imple-

mentation costs, priorities

”when a task implementation exceeds two or three times the esti-

mated time”, ”Too long meetings with too many people”, ”most

problematic is the estimation part”

Human

re-

sources

workload, HR shortage, com-

munication, context switch-

ing

”peoples with required skills”, ”Online communication: infor-

mation passing might be affected”, ”Context switching impacts

productivity”

Others project speciﬁcity, software

quality, business value

”Scrum may not be suited for a live project (in production)”, ”ac-

cumulated technical debt can be an issue”, ”lack of testing for

frequent deliveries”

A. Challenges related to the methodology itself pose

the biggest problems both for large and small compa-

nies. In the case of small companies, these challenges

seem overwhelming compared to the others.

B. Especially large companies struggle with human

resources needs. The solution was (according to the

answers) to train people from other domains to per-

form roles such as SM, PM, and business analyst.

7 THREATS TO VALIDITY

Being an empirical investigation, threats to validity

have to be addressed. We followed existing guide-

lines (Ralph, Paul (ed.), 2021), and considered the

following potential threats to validity: the sample size

is too small, the sample size is too similar, the lack

of representativeness, and the relevance of the survey

based on the assumptions that it captures general peo-

ple’s perception. We addressed the ﬁrst threat by hav-

ing 31 interviews, a number close to similar studies

(Burga et al., 2022; Gerster et al., 2020; Martini and

Bosch, 2013; Souza et al., 2019). The sample size

was diverse in terms of gender (the number of women

was almost equal with the number of men), years of

experience in the ﬁeld, and the positions held in the

company. Special attention was given to the company

size as small companies and medium/large compa-

nies needed to be represented. We mitigated the last

risk by asking questions strictly related to processes,

where the people’s perception is less important and it

does not inﬂuence the answer. To ensure internal va-

lidity, we also took into consideration and minimize

the impact of our interventions: we followed the same

interview structure and timing and the data set was

generic, so no extraneous factors can explain the re-

sults. We paid careful attention to the content of re-

sponses, trying to reduce bias by third author veriﬁca-

tion of the transcript and also explicit approval of the

respondents on the ﬁnal transcript. We respected the

methodology of open coding, by addressing aspects

related to the objectivity of the coding process and

the saturation of categories. We paid attention to con-

struct validity, we had several iterations of the ques-

tions included in the interviews. We had two inter-

views with two professionals with extensive experi-

ence to calibrate the questionnaire before starting the

study. Finally, there was no companies or people se-

lection bias selection. We make sure that there exists

a complete anonymization of persons and companies.

8 CONCLUSIONS AND FUTURE

WORK

We discussed and analyzed the answers of 31 inter-

viewees from 14 companies to ﬁnd out the challenges

encountered in adopting different methodologies and

how did they adapt these methodologies. To have a

valid overview of the business environment, we had

to select carefully the data set to be representative for

all the actors in the market. The selected data set

was diverse in terms of the company’s size (small and

medium/large companies), business model (product

companies and outsourcing companies), and also in

terms of the interviewed persons. Both genders were

represented, people were having multiple roles (team

lead, scrum master, release manager, and so on). We

found out that most of the companies adopted the Ag-

ile methodologies in a more or less extensive man-

ner. By far, the most used ceremony was Daily meet-

ings, other ceremonies were sometimes merged or re-

moved from the methodology implementation. There

were only 2 of 32 projects that used ”SCRUM by the

book” methodology. We also analyzed how the Ag-

ile Manifesto was implemented in these companies,

even if this was not the original scope of our study,

but it provides relevant information related to Agile

A Perspective from Large vs Small Companies Adoption of Agile Methodologies

271

mindset adoption.

From a scientiﬁc point of view, this study con-

tributes to the body of knowledge related to Agile

adoption in different types of companies and to bet-

ter understand from methodological perspectives the

challenges related to Agile practices. For practition-

ers, the results presented in this paper offer evaluation

means and solutions for Agile adoption. For compa-

nies that do not completely adopt Agile, some action

plans can be designed.

In the future, it would be interesting to ﬁnd out

how the Agile adaptation evolves in the mentioned

companies, and how much the adaptation is corre-

lated with project type (size, application domain, and

so on), company size, or management style.

FUNDING

The publication of this article was supported by the

2022 Development Fund of the Babes¸-Bolyai Univer-

sity.

REFERENCES

Akhtar, A., Bakhtawar, B., and Akhtar, S. (2022). Extreme

programming vs scrum: A comparison of agile mod-

els. International Journal of Technology, Innovation

and Management (IJTIM), 2(2).

Braun, V., Clarke, V., Hayﬁeld, N., and Terry, G. (2019).

Thematic Analysis, pages 843–860. Springer Singa-

pore.

Brown, D. D. (2013). Agile User Experience Design. Mor-

gan Kaufmann.

Burga, R., Spraakman, C., Balestreri, C., and Rezania, D.

(2022). Examining the transition to agile practices

with information technology projects: Agile teams

and their experience of accountability. International

Journal of Project Management, 40(1):76–87.

Choras, M., Springer, T., Kozik, R., Lopez, L., Martinez-

Fernandez, S., Ram, P., Rodriguez, P., and Franch, X.

(2020). Measuring and improving agile processes in

a small-size software development company. IEEE

access, 8:78452–78466.

Gerster, D., Dremel, C., Brenner, W., and Kelker, P.

(2020). How enterprises adopt agile forms of organi-

zational design: a multiple-case study. ACM SIGMIS

Database: the DATABASE for Advances in Informa-

tion Systems, 51(1):84–103.

Gonz

alez-Cruz, T. F., Botella-Carrubi, D., and Mart

ınez-

Fuentes, C. (2020). The effect of ﬁrm complexity and

founding team size on agile internal communication

in startups. International Entrepreneurship and Man-

agement Journal, 16(3):1101–1121.

Kalenda, M., Hyna, P., and Rossi, B. (2018). Scaling ag-

ile in large organizations: Practices, challenges, and

success factors. Journal of Software: Evolution and

Process, 30(10):e1954.

Katumba, B. and Knauss, E. (2014). Agile development

in automotive software development: Challenges and

opportunities.

Kent Beck, a. (2001). Agile manifesto. [accessed 31-July-

2022].

Kiger, M. E. and Varpio, L. (2020). Thematic analysis

of qualitative data: Amee guide no. 131. Medical

Teacher, 42(8):846–854.

Klunder, J. A.-C., Hohl, P., Prenner, N., and Schneider, K.

(2019). Transformation towards agile software prod-

uct line engineering in large companies: A literature

review. Journal of Software: Evolution and Process,

31(5):e2168.

Laanti, M., Salo, O., and Abrahamsson, P. (2011). Ag-

ile methods rapidly replacing traditional methods at

nokia: A survey of opinions on agile transformation.

Information and Software Technology, 53(3):276–

290.

Martini, A. and Bosch, J. (2013). Communication factors

for speed and reuse in large-scale agile software de-

velopment.

Mishra, A., Abdalhamid, S., Mishra, D., and Ostrovska,

S. (2021). Organizational issues in embracing ag-

ile methods: an empirical assessment. International

Journal of System Assurance Engineering and Man-

agement, 12(6):1420–1433.

Motogna., S., Suciu., D., and Molnar., A. (2021). Inves-

tigating student insight in software engineering team

projects. In Proceedings of the 16th International

Conference on Evaluation of Novel Approaches to

Software Engineering - ENASE,, pages 362–371.

Petrescu, M. A., Borza, D. L., and Suciu, D. M.

(2022). Findings from teaching entrepreneurship to

undergraduate multidisciplinary students: Case study.

EASEAI, page 25–32.

Ralph, Paul (ed.) (2021). ACM Sigsoft Empirical Standards

for Software Engineering Research, version 0.2.0.

Saleh, S., Huq, S., and Rahman, M. (2019). Comparative

study within scrum, kanban, xp focused on their prac-

tices.

Smits, H. and Rilliet, K. (2011). Agile experience report:

Transition and complexity at cisco voice technology

group. In 2011 Agile Conference, pages 274–278.

Souza, R., Rocha, L., Silva, F., and Machado, I. (2019).

Investigating agile practices in software startups. In

Proceedings of the XXXIII Brazilian Symposium on

Software Engineering, pages 317–321.

the European Communities, T. C. Commission recommen-

dation. [accessed 2022].

ENASE 2023 - 18th International Conference on Evaluation of Novel Approaches to Software Engineering

272