St. Petersburg University
Graduate School of Management
Master in Management Program
AGILE METHODOLOGY IN MANAGING DIGITAL PROJECTS: EVIDENCE FROM
RUSSIA
Master’s Thesis by the 2nd year student
Marashlyan Anna, MIM
Research advisor
Kiran V. Zhukova, Ph.D.
Saint Petersburg
2016
АННОТАЦИЯ
Анна Григорьевна Марашлян
Автор
Название
магистерской Гибкие методы управления диджитал-проектами в России
диссертации
Факультет
Высшая Школа Менеджмента
Направление подготовки
Менеджмент
Год
2016
Научный руководитель
Киран Витальевна Жукова
Описание цели, задач и Целью данного исследования является изучение гибких
основных результатов
методов управления проектами, а также факторов, которые
влияют на решение менеджеров проектов перейти на гибкие
методы, с тем, чтобы выявить принятые практики и разработать
ряд рекомендаций для руководителей проектов по критериям
выбора в пользу гибких принципов.
Исследование
содержит
информацию
о
самых
распространенных гибких практиках среди цифровых и ИТкомпаний в России, а также о том, какие факторы и
характеристики проекта и его среды имеют тенденцию влиять
на
решение
исследование
нахождения
о
применении
использует
связи
между
гибких
методов.
количественные
уровнем
Наконец,
методы
внедрения
для
гибких
методологий и факторами принятия решений.
Ключевые слова
управление проектами, гибкие методологии, гибкие методы
разработки
3
ABSTRACT
Master Student’s Name
Anna Marashlyan
Master Thesis Title
Agile Methodology In Managing Digital Projects: Evidence
From Russia
Faculty
Graduate School of Management
Main Field of Study
Management
Year
2016
Academic Advisor’s Name
Kiran V. Zhukova
Description of the goal, The goal of this study is to investigate the adoption stage of agile
tasks and main results
methods and factors that encourage project managers to make the
choice of agile transition. A set of recommendations for project
managers on choosing agile principles will be derived based on
the analysis of the identified best practices.
The paper provides information on most adopted agile project
management practices among the Russian digital community and
IT companies, and environment-related factors that influence the
decision to adopt agile methods. Finally, quantitative analysis will
be conducted in order to provide evidence of the relationship
between agile methods adoption level and the factors, which
influence the decision-making process.
Keywords
agile, agile methodology, agile adoption factors, project
management, digital industry, software development
4
TABLE OF CONTENTS
ABSTRACT.................................................................................................................................... 4
INTRODUCTION .......................................................................................................................... 6
CHAPTER 1. EXISTING RESEARCH ON AGILE PROJECT MANAGEMENT ..................... 7
1.1.
Modern approaches to managing digital projects ........................................................... 7
1.2.
Paradigms and methods of agile project management .................................................. 10
1.3.
Classification of recent research directions on agile methodologies ............................ 19
1.4.
Identifying the research gap in agile adoption and tailoring factors ............................. 23
1.5.
Summary of Chapter 1 .................................................................................................. 25
CHAPTER 2. THEORETICAL FRAMEWORK FOR INVESTIGATING FACTORS
INFLUENCING THE ADOPTION OF AGILE METHODS ...................................................... 27
2.1.
Identifying research goal and research questions ......................................................... 27
2.2.
Choice and justification of the research design ............................................................ 28
2.3.
Deriving theoretical research model ............................................................................. 31
2.4.
Data collection and analysis technique ......................................................................... 41
2.5.
Summary of Chapter 2 .................................................................................................. 44
CHAPTER 3. RESULTS OF THE SURVEY AND FACTORS INFLUENCING DECISION ON
AGILE METHODOLOGY ADOPTION IN RUSSIAN DIGITAL INDUSTRY ....................... 45
3.1.
Descriptive statistics on respondents and organizations ............................................... 45
3.2.
Data assessment process and results of the data collection .......................................... 49
3.3.
Results interpretation and discussion ............................................................................ 54
3.4.
Summary of Chapter 3 .................................................................................................. 58
CONCLUSION ............................................................................................................................. 59
REFERENCES ............................................................................................................................. 60
APPENDICES .............................................................................................................................. 67
5
INTRODUCTION
Companies nowadays are heading towards digitalization with an increasing speed, which
inevitably affects customer journeys’ pathway. As consumers become more and more digitally
aware, the way companies organize business processes and work with clients dramatically
changes. We are now stepping into the era of “digital Darwinism”, when organizations can barely
keep up with the socio- and technological advances.
Effective software, web- and application development, as well as digital production in
general becomes crucial for reaching competitive advantage and success, especially given
increasing level of competition and tightening economic conditions. Companies employ digital
solutions for the purpose of marketing, branding, business strategy and product development. For
decades, professionals have been searching for ways to organize digital-related projects to reach
faster, cheaper, and better results; many solutions were suggested along the way, such as KPIs
standardization, various techniques, tools, and practices.
Successful projects require project methodology, which is a particular set of techniques,
methods, and artefacts that set the game rules for the development team. Ever since the agile
movement appeared in the beginning of 2000s as a new way of handling project work, it managed
to hugely impact software development worldwide, and has been recognized as one of the most
effective, if not the only one, practice to reach project goals in a more effective fashion in order to
build a competitive business.
Regardless of the adopted methodology, project managers should oftentimes tailor the
management techniques in order to adapt them better to the internal and external environment of
the project. Despite recognition of importance of the external factors and project context, there is
a gap between professional project management community and academic management research
done on the matter of agile adoption factors identification. This study aims to fill the gap to the
possible degree, by exploring the way agile methods are being implemented in Russian digital
companies, what challenges and drawbacks exist concerning this, and are there any ways to
identify the relation between the factors that influence the agile adoption decision and the actual
level of agile approach implementation.
This paper’s main purpose is to investigate the same problem with respect to Russian agile
community, specifically – digital production studios, IT, software, and web-development teams
and companies in order to help then with identifying to what factors they should look more closely
while considering transition from waterfall to agile approach.
6
CHAPTER 1. EXISTING RESEARCH ON AGILE PROJECT MANAGEMENT
1.1.
Modern approaches to managing digital projects
Nowadays, software and web-development is more technically complex; more strategic;
and brings to the fore the divergent viewpoints of a wider variety of stakeholders (Nerur, Cannon,
Balijepally, & Bond, 2010). Software and web-development is a complex activity characterized
by tasks and requirements that exhibit a high degree of variability (Boehm & Turner, 2005). At
the same time digitization is rewriting the rules of competition, with incumbent companies most at risk
of being left behind. This leads to the inescapable conclusion that software and web-development,
both today and in the future, is and will continue to be undertaken in a much more uncertain context
(Nerur et al., 2010).
Meanwhile the problem remains with keeping the quality of the digital projects and end
product quality definition in highly unstable environment; as well as with managing the software
and web-development outcomes and restrictions while reducing the cost and time of the project
(Petersen, 2010). The models of managing the projects that lay in the digital area typically are
divided into traditional, iterative models - Waterfall, RUP, and more flexible, agile methods SCRUM, XP, LEAN, etc. (Whitaker, 2014).
However, the problem remains with identifying the guidelines on to whether or not use the
agile methods, and how to tailor the project management practices to a particular project and
organizational environment. According to the popular Cynevin framework (Stacey, 2011), there
are three basic types of systems: ordered, complex and chaotic. Ordered systems are, in turn,
divided into simple and complicated. Hence, there are five domains in total: simple, complicated,
complex, chaotic, and disorder area. This is a decision-making framework that recognizes the
causal differences that exist between different types of systems, proposing new approaches to
decision making in complex social environments.
In practice it means that depending on the complexity of the environment and characteristic
of the project it is possible to choose which type of managerial and project management approach.
This Cynevin paradigm (see Figure 1.1.), while providing a philosophical and fundamental
conceptual model is, however, quite vague when it comes to actual implementation of the project
management and tailoring methods technique. The problem of developing a practical approach,
therefore, remains open and to the judgment of managers.
7
Figure 1.1. Theory of systems and agile paradigm. (Source: Stacey, 2011)
Waterfall software development model appeared in the mid 1950s in the work of Herbert
Benington (1956) and officially became one of the first software development model (Royce,
1970) used by the U.S. Army. The model represents iterative, sequential workflow, in which the
project progress goes gradually from identifying system requirements to design, coding and testing
phase until the end (see Figure 1.2). This system’s main advantage is relative simplification of
managing process and, given stable system requirements, the development process usually brings
satisfactory results (Pedersen, 2014). At the same time, this model is rigid in terms of allowing
project change during the implementation phase, which increases costs of possible changes
significantly.
Figure 1.2. Waterfall software development model. (Sources: Pedersen, 2013).
8
Rational Unified Process (RUP) is an approach that is getting more and more attention
recently, represents a modern iterative process for object-oriented system development, and has
been created to complement Unified Modeling Language (UML) (Abrahamsson et al., 2002). Its
main advantage lays in less rigidity in comparison to Waterfall and PMBOK approach, and it is to
strongly uses UML components such as use cases. The life cycle on RUP is composed by 4 phases:
inception, elaboration, construction and transition. Regarding adoption, it can be used in a whole
or in part, depending on the organization’s goals.
Agile methods for software development (see Figure 1.3.) have been increasingly used by
the digital, IT, and software development industry based on a set of advantages such as an
accelerated time to market, quality and productivity growth, improvement of Information
Technology (IT)/business alignment. Agile is about welcoming changes and managing priorities
reorganization compared to traditional software development methods (Nishijima & Santos, 2013;
Qumer & Henderson-Sellers, 2006).
Figure 1.3. Agile web-development cycle. (Source: Scanmarket)
The importance and benefits of agile adoption, such as as ability to manage changing
priorities, increased team productivity, improved project visibility, increased morale and faster
time to market are well researched both by market consultancies (VersionOne, 2016) and by
academic researchers (Jyothi & Rao, 2011; Glaiel, Moulton, & Madnick, 2013). Nevertheless, the
issue remains with the adoption process, especially such aspects as resistant culture, inability of
management to allow change, employees’ inactivity, and so on (Echalar, 2013; Gandomani et al.,
2013).
9
Employees’ resistant to change is especially important topic, since not every change should
generally be greeted and not necessarily is good for the team and project productivity and morale.
Development team must adjust to the new flexible approach, and to be ready to quickly respond
to changing business and clients’ requirements (Jyothi & Rao, 2011), since the testing oftentimes
goes in parallel with coding and clients’ communication and updates.
The transition from waterfall approach can be quite difficult and confusing for the project
teams and web-studios and companies in general. Important aspect lies in communication of new
order within the organizations in order to make it possible minimize the documentation flow and
bureaucracy (Moniruzzaman & Hossain, 2013). Communication is the key in agile methods
adoption – contrary to traditional detached role of the development team and not full clients’
involvement, agile paradigm requires to put people ahead of papers – and thus, to maximize the
interaction inside the team as well as with the external environment; this is critical difference
between waterfall and agile, and the main reason while waterfall is becoming less and less popular
(Santos et al., 2011).
Lastly, we are coming ahead of this paper’s timeline, and preliminary state the fact that
regardless of the adopted methodology, project managers should oftentimes (if not always) tailor
the management techniques in order to adapt them better to the internal and external environment
of the project (DeMarco, 1982). In order to do that, they can use the help of their counterparts, and
the best practices in the industry.
Substantial amount of research on agile methods is devoted to identifying factors that
influence the adoption process and their relationship (Ayed, Vanderose, & Habra, 2014; El-Said,
Hana, & Eldin, 2009; Santos et al., 2011; Glaiel, Moulton, & Madnick, 2013; etc.). This paper’s
main purpose is to investigate the same problem with respect to Russian agile community,
specifically – digital production studios, IT, software, and web-development teams and companies.
This study is also concerned with the problem of identifying the parameters when it is more
effective to apply the agile approach, given the Russian business conditions.
1.2.
Paradigms and methods of agile project management
Agile, initially being used as an effective tool during software development in small teams,
is now becoming a new vision and culture of managing large corporations (Bonner et al. 2010).
For decades there was a dominant, classical approach to managing software projects, so-called
“waterfall development” (Nerur et al., 2005), which implied iterative nature of project work. Once
approved project plan had to be implemented within initial constructs and limitations, which made
project performance extremely vulnerable to changing environment.
10
In 2001 a new conceptual approach was created (Beck et al., 2001); it changed the way
people start think about managing project, since the concept of agility implies innovative rethinking of a product/service creation, when project alteration can happen at any time due to
uncertain external conditions. Since the uncertainty is a constant factor of new business reality,
the concept of managing projects with flexibility has quickly become popular and is still highly
relevant up to this day.
While the agile concept is a relatively agreed upon definition and there is a common line
among most existing definitions, it seems important to highlight different angles and
terminological aspects. The most often definition of agility is connected with continual ability to
balance and navigate in times of change, to better respond to uncertainty, to better learn and adapt
to changing environments and instability (see Table 1.1.)
Table 1.1. Relevant definitions of agility in managerial research.
Author (-s)
Larman and Basili
View on agility
Rapid, fast and flexible response to change.
(2003)
Highsmith (2004)
Ability to both create and respond to change in order to profit in a
turbulent business environment; it is the ability to balance flexibility and
stability.
Conboy (2009)
Continual readiness of an information system development method to
rapidly or inherently create change, proactively or reactively embrace
change, and learn from change while contributing to perceived customer
value (economy, quality, and simplicity), through its collective
components and relationships with its environment.
Kettunen (2009)
Mechanism to increase the quality and service factors by meeting the
current customer requirements by being flexible to customer demands
and market changes.
Conboy and
Continual readiness of an entity to rapidly or inherently, proactively or
Fitzgerald (2004)
reactively,
embrace
change,
through
high-quality,
simplistic,
economical components and relationships with its environment
11
Lyytinen and Rose
Ability to sense and respond swiftly to technical changes and new
(2006)
business opportunities; it is enacted by exploration-based learning and
exploitation-based learning.
Additionally, few studies also have been describing agility through several characteristics,
or attributes, that further deepen the concept and are relevant for the purpose of this research in
providing an insight of what agile management is all about – effective team building, flexibility,
involvement, and concentration on the end result, and high speed of project work (see Figure 1.4.).
Important to notice, that definition and main characteristics of agility and being agile are
subjects that has already been well researched in the academic literature, and there is nothing
conceptually new been discovered in the area of agile epistemology. Hence this study does not
state its purpose and is not going to introduce new dimensions of “agile”, and, instead, works with
existing definitions.
Attributes of
agility
Speed
Ability to
respond and
get to the final
goa in a fast
and quick
fashion
Flexibility
Ability or
behaviour of
an entity that
enables
adapting to
change
whenever it is
required
Leanness
Responsiveness
Ability to be
compact and
tight and to
produce the
desired
quality output
in an
economical,
shortest way
Life, reaction,
and sensitivity;
ability to
respond when
it is required
Learning
Refers to
knowledge and
improvement,
indispensable
ability to show
continuous
improvement over
time
Figure 1.4. Characteristics of agility. (Source: adapted from Qumer and HendersonSellers, 2008).
In a recent survey, 84% of organizations stated they were using agile methods, with half
having begun in the last two years (VersionOne, 2016). Agile software development practices are
believed to significantly improve responsiveness to customer requirements and changes, which
results in better quality software products and improved productivity and morale of the
development team.
12
1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software
2. Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
Figure 1.5. Twelve principles of agile software development. (Source: Beck et al., 2001).
The three most important features of agile are (1) achievement of customer satisfaction
through early and continuous delivery of software (2) co-operative working of client and
development staff, and (3) the use of face-to-face conversations for communications in the team
(Bass, 2013).
The concept of agile methods was first introduced in 2001 by several project management
“gurus” and software engineers, and stated the principles of prevalence of communication over
processes and tools, effective applications over paperwork, collaboration with customers over
contracts negotiations; proactive response to changes over strict plan following (Figure 1.5.).
This approach was significantly different from classic, “waterfall” method of project
development, by allowing another level of flexibility and ad-hoc change (Nerur et al., 2010). It
13
has been argued that the paradigm of agility was one of the main shifts in digital development over
the last ten years, that, however could not avoid being the subject of various misinterpretations
and subjective individual judgments (Dingsøyr et al., 2010).
With these agile principles, the highest priority in managing projects is being placed on the
quality of the end product and customer satisfaction as the main measurement of project success.
This view has quickly become popular among other project manager practitioners (West & Grant,
2010), and currently there is a range of recognized agile professionals’ certifications available for
project managers who work in the agile project management domain and who chose to increase
their value as employees.
Speaking of effect of agile methods, it is argued to deliver extreme-quality applications
and software, to increase productivity and efficiency, to achieve higher customer satisfaction, to
keep clients, to reduce extra-cost and eliminate ineffective budgeting and “waste”, to perfect team
communication and morale, to improve risk management, etc. (Highsmith, 2007; Kettunen, 2009;
Schwaber, 2007).
Nevertheless, there is still some studies that suggest insufficient amount of empirical
evidence, not enough to strongly claim the impact of agile methods on abovementioned parameters
and overall productivity (Kettunen, 2009). Moreover, some papers show connection between agile
application and drawbacks in form of increased ambiguity and time-to-market pressure
(Baskerville et al., 2006). The problem of connecting productivity and agility will be covered in
the latter part of the chapter.
Table 1.2. Main differences between agile and waterfall methodologies. (Sources: adapted
from Nerur and Balijepally, 2007; Salo and Abrahamsson, 2008).
Fundamental concept
Waterfall
Agile
Environment and systems can
Software is being developed
be predicted, and are subject
in small teams, with
to thorough planning; once
application of continuous
planned project is planned
design principle and constant
feedback
Paradigm
Positivism
Learning theory, Dewey’s
pragmatic principle
Style of management
Monitoring and Control
Leadership, communication,
and collaboration
Communication style
Formal focus
Informal focus
14
Development model
Full life-cycle
Evolutionary-delivery
Management structure
Large-scale, bureaucratic,
Small-to-medium sized,
formalized
organic and flexible
Customers’ role
High
Critical
Aim
Budget and optimization
Responsiveness, adaptation,
and learning
Knowledge Management
Main features
Explicit, open-ended,
Tacit, non-codified/ hard-to-
codified data, stored in
codify data, personal
physical form
experiences and knowledge
Manager controls
Manger facilitates
Single-loop learning
Double-loop learning
Conflict aversion
Dialectic approach
Prevalence of control
Embrace of creativity
Implementation after
Project phases cannot be
planning and design phase
separated, and evolve
altogether
The main differences that were brought by agile practices (see Table 1.2.) resulted in
remarkable transformations in software development approach, and were more suitable for larger,
more complicated digital projects (Kettunen, 2009). Traditionally, main frameworks for leading a
digital project included so-called life-cycle models: spiral, waterfall, etc. (Nerur et al., 2005).
According to these models, the roles are distributed, and outcomes are stated at each phase
of the project. Waterfall approach implies iterative nature of the project management, and also
tends to produce loads of documentation and paperwork in order to properly codify information
for communication purposes.
As for team management, traditional approach states importance of communication
between team members and other project stakeholders; however, external project participants
(clients in particular) do not play constant part in project activities and do not have a strong voice
except for occasional milestone validation and approval (PMBOK 5th edition, 2013).
Traditional, waterfall approach also stresses the importance of processes, tools, and
operations, and comes from the assumption that external uncertainty can be eliminated in the
process of risk management activities, and activities related to measurement and monitoring, and
control (Nerur et al., 2005). This rational, optimization-based view has been dominating in digital
development industry for decades and until to the 2000s with agile methods appearance and
adoption.
15
Adoption of agile principles is claimed by some studies to alter organizational
characteristics such as business processes and tools, managerial practices, ways and channels of
communication, team roles, group dynamics, and even culture (Moe, 2011). The prevalent view
in literature stated that it is better to deal with high uncertainty by relying on individuals, teams,
and their creativity, and not on processes and tools, which in practice shortens digital development
cycles (Cockburn & Highsmith, 2001).
Consequently, adoption of agile methods increases the role of clients in the decisionmaking process via communication during all development cycle, from the start of the project. It
allows the possibility of getting faster feedbacks and gives opportunity to change project plan and
specifications ad-hoc, during the product development. Usually it implies that the development
process is divided between smaller teams, and each team is working in frames of project life-cycle
(planning phase, implementation phase, integration and testing, and closing) and is responsible for
local changes when necessary and for the part of working code to be delivered.
Agility affect the way managers conduct team leading and building – leadership style tends
to evolve from control to facilitation and collaboration without overload of documentation and
data codification processes. (Nerur & Balijepally, 2007). Lack of extra documentation, therefore,
gives more space for tacit knowledge and data, which is transferred between teams via
communication and other knowledge management techniques.
At the same time, agile methods allow to concentrate on processes adaptation inside teams,
which comes in the form “of on-the-go” improvements being made by professional developers
and professionals (Salo & Abrahamsson, 2007) and thus increases flexibility of project
management to the point that is unattainable by traditional waterfall approach.
One of the research objectives of the study is to identify the most popular agile methods
are that being used in managing digital projects, hence, for the purpose of stated objective it is
important to list main agile methods that are currently being used in software development (see
Table 1.3.).
16
Table 1.3. Main agile methods that are used in digital development. (Source: analysis of
literature).
Agile method
Description
Influential articles /
sources
SCRUM
Approach that was developed specifically for Schwaber (2007);
managing projects in times of uncertainty and Schwaber and Beedle
volatility, which is based on adaptability, (2002),
flexibility, and productivity. It allows free Schwaber and
choice of necessary development tools and Sutherland (2011)
techniques by developers. Feedback loops are
one of the main elements of project
management process;
XP (Extreme
Extreme programming is a compilation of Beck (1999); Beck et
Programming)
best and good practices in the industry that are al. (2001), Deemer et
gathered and lined up with each other, with an al. (2010)
aim at achieving successful end product.
Short iterations, and fast releases are the main
elements of XP;
Lean
Being developed as the Toyota production Poppendieck, M. and
system, lean is an adaptation of corporation Cusumano, M. (2012)
practices onto project management method
and is considered an agile technique by
majority of studies; Consists of seven
principles, namely waste reduction, team,
integrity building and empowerment, fast
deliverance etc.
Feature-driven
Is
a
combination
of
agile
software Coad et al. (2006);
development (FDD)
development and model-driven development Palmer and Felsing
giving a process-focused method as a result; (2002)
Most important focus upon which FDD is
places is phases of design and building.
17
Dynamic software
Provides a framework for Rapid application Stapleton (1997)
development
development. Includes three phases: pre-
method (DSDM)
project, life-cycle, and post-project. Contains
nine principles, among which are high end
user involvement, possibility of reversing
changes, detailed scope, etc.
Crystal
Branch of agile methods, which can be
methodologies
selected individually for each particular
(Crystal family)
project; at the core of methods is so-called
Cockburn (2004)
“appropriate-color method” – each project is
assigned a colour in dependence of size and
weight;
Currently, the most employed agile methodologies are: Scrum (Deemer et al., 2010;
Schwaber & Sutherland, 2011), Lean, Kanban, Extreme Programing (XP), Adaptive Software
Development (ASD), Feature-Driven Development (FDD), Dynamic Systems Development
Method (DSDM), and Crystal family practices with Scrum being the
most adopted one
(Versionone, 2016).
Agile methods should be distinguished from agile practices, which will be covered and
explained in the second and third chapters of the study. Each agile method is focused with distinct
set of values, techniques and terminology, and there is no “silver bullet” approach, and neither
there is a one sure way to tell which method would be preferable given the particular circumstances
– this decision lies on project leaders and managers.
Moreover, each of agile methods has its own evolution and interrelations between each
other, that are important to note for the better understanding of practices (see Figure 1.6.). Earlier
papers influences significantly the latter once, hence, intellectual roots of current agile methods
go back in 1980s. Problems remain with tailoring agile methods to specific markets, products, and
project specifications, so as the time gap between new agile developments and modifications and
lack of academic analysis
18
Figure 1.6. Evolution map of agile methods in digital project management. (Source:
adapted from Dingsøyr et al., 2010).
1.3.
Classification of recent research directions on agile methodologies
Since the emergence of the agile methodology in 2001 there are over 1550 publications
that have been published on agile project management; among them, the leading countries of
research are USA, Canada, and Western Europe (see Figure 1.7.). Speaking of developing
economies, there is still a substantial shortage of research concerning application and adoption of
agile project management practices and it influence on productivity, organizational culture, and
other factors.
It does seem necessary, though, to put countries like Russia on the “research map”, so that
the local companies could better be aware of ways of improving project management practices,
and academics would have more data concerning local geography.
19
338
110
96
94
94
56
52
51
48
43
41
33
29
25
23
Figure 1.7. Number of academic publications on agile methods by country (Source: ISI
Web of Science, Thomson Reuters; eLibrary).
Some papers are investigating particular agile methods application (test-driven
development, XP, pair programming, etc.) and their specifics. Moreover, the current “hot” theme
is reconciliation and possible harmonization strategies between project management practices,
finding ways to combine agile and non-agile in order to eliminate risks and have a synergy effect,
so as the role of patterns., which is being developed by several cited articles (Sharp & Robinson,
2010; Sharp et al., 2009).
Due to the vast variety of issues related to project management and agile methods in
particular, there are several categories, in which academic papers on the subject are generally tend
to fall (Figure 1.8). Firstly, it is about issues related to an introduction and adoption of agile
methods, that is still interesting for researchers, and so far there is no single accepted way due to
different services and organizational specifics (Layman et al., 2008; Lee & Xia, 2010).
Another stream of research is concerned with building organizational system, organizing
business activities in a way that it will help to implementation of agile practices and vice versa.
Many papers investigate influence of social behavior, team dynamics, and organizational culture
with respect to agile application. Within this area of research there is a large amount of work
devoted to knowledge management aspect of agile practices (Salazar-Torres et al., 2008; Chan &
Thong, 2009), to the influence if individual behavior and belies (Acuna et al., 2009; Hannay et al.,
2010), to organizational learning (Holz & Mauler, 2002), and social facilitation (Balijepally et al.,
2009).
There is a distinctive area of research, which is trying to investigate how implementation
of agile practices, as oppose to traditional methods, can influence the performance of the project
team/ the company and ultimately help to gain competitive advantage (Nerur et al., 2005). This
20
branch is trying to compare different methods between each other, with possibility of drawing
better practice for a particular business case.
The comprehensive map of research direction and research methods employed (see Figure
1.8.) shows that first qualitative findings on many topics already exist, but confirmatory studies in
almost all research areas are still lacking.
Speaking of research methods utilized (see Table 1.4), systematic literature review
(Hummel, 2014) results show that the case study is by far the most popular approach with almost
40% frequency. This speaks to the fact that agile methods, while being on the edge of popularity
for several years, still just on the way of transformation to the more advanced, quantitative
methods’ utilization.
Table 1.4. Research methods utilized in studies on agile methodology. (Source: Hummel,
2014)
Research method utilized
# of papers
% of total
Case Study
185
38,5%
Experiment
62
13.0%
Survey
39
8.0%
Ethnography
16
3.5%
Simulation
18
4.0%
Literature Review
25
5.0%
Grounded Theory
22
5.0%
Action Research
12
2.5%
Focus Group
6
1.0%
Considering all mentioned above, this study is more related to the adoption branch of the
agile methods studies, since there is yet a little evidence from Russian companies and gathered
data is used for relatively new research goal. Therefore, the study investigates which agile methods
are used in companies, how are they being implemented in practice, what are the parameters that
indicate that usage of agile methods would be more preferable.
21
Figure 1.8. Taxonomy of agile software-related project management academic focus and
research method employed. (Source: Hummel, 2014).
22
1.4.
Identifying the research gap in agile adoption and tailoring factors
As can be seen from the Figure 1.8., the adoption problems are still a relevant research
area, and is appealing for the analysis and further investigation for the local Russian software and
digital market. Analysis of e-Library showed that there are currently no scientific research papers
conducting primary data analysis on agile methods adoption factors in Russia.
As was stated before, the transition to agile approach can be quite challenging for the
development teams, and might face obstacles such as cultural differences, individual and group
resistance, upper management refusal or lack of understanding (Echalar, 2013, Gandomani Et Al.,
2013). We believe that this analysis can help identifying certain managerial patterns and implicit
practices, and, hence, to help teams that are considering agile transition in identifying factors that
are require special attention.
Therefore, the adaptation issue is a critical one, and in order to do that, we need
understanding of how project context, cultural and external environment influence the agile
adoption. The problem of agile adoption reasons identification has already been posed in the global
research community, however, yet without consistent results.
There are work on literature on agile practices selection (Ahmed & Sidky, 2009; Abbas,
Gravell & Wills, 2010, Esfahani, Yu, & Annosi, 2011; Madi, Dahalin, & Baharom, 2011;
Kurapati, Manyam, & Petersen, 2012) but still no final answer to this problem. Agile practices
adoption could help organizations bring new ways of performing tasks but also keep existing
practices of the organization in place. This combination could make the organization more
successful (Kurapati, Manyam, & Petersen, 2012). The research work on agile methods tailoring
according to papers above can be divided on the following types: most used practices, quality,
business goals, maturity model, agile values and project types.
A review of the research literature on use of agile in global software engineering presented
a list of agile practices used or referenced by the analyzed papers (Jalali & Wohlin, 2010). A survey
on agile practice adoption proposed to under- stand which practices have been used by the software
development industry (Kurapati, Manyam, & Petersen, 2012). The survey analyzed practices
adoption at the project and organization levels and also defined the association between practices.
Factor analysis was applied to group 58 agile practices and found 15 factors and checked the
correlation between them finding application of quality assurance and iterative and incremental
practices had a high success rate (Abbas, Gravell, & Wills, 2010). An empirical study identified
common adopted practices, listed practices that normally are used together and correlated the
customer satisfaction after adopting the practices (Manyam & Kurapati, 2012). This work also
tried to identify adaptation by organizations on the adopted practices. A work focused on the
23
quality aspects of the agile practices showed the main agile practices associated with high quality
of the software product (Santos et al., 2011).
SAAP (Strategic Analysis for Agile Practices) framework (Esfahani, Yu, & Annosi, 2011)
was proposed with the intent to associate business goals of the organization to the selection process
for agile practice adoption. SAAP extended Situation Method Engineering and used concepts from
Balanced Score Card (BSC). This work linked the selection of agile practices to the organization’s
business goals.
Sidky Agile Measurement Index (SAMI) (Ahmed, & Sidky, 2009) showed the adoption of
agile practices based on an agile maturity model. SAMI is a 5-step road map to guide teams
adopting based in 5 values considered essential to agility: enhancing communication and
collaboration (level 1), delivering software early and continuously (level 2), developing high
quality, working software in an efficient and integrated manner (level 3), respond to change
through multiple levels of feedback (level 4) and establishing an environment to sustain agility
(level 5). SAMI is not based on any specific agile method such as XP, Scrum or Crystal, but
instead, uses agile values and principles to define the path to agility.
The analysis of papers and books from Agile Manifesto signatories using content analysis
(Madi, Dahalin, & Baharom, 2011) identified the key agile values and how frequent they were
mentioned in the literature. The agile key values obtained by this work were: Flexibility,
Customer-centric, Working Software, Collaboration, Simplicity, Communication, Natural,
Learning, Pragmatism and Adaptability.
A methodology to select the best agile practices for projects based on the association
between project’s characteristics and the abilities of the agile practices has been defined (Saleh,
2013) and the key project’s areas analyzed in the work were team size, iteration duration and
distributed teams.
Case study was the most utilized empirical research technique and demonstrated that those
researchers were trying to prove that the proposed approaches could be used on real case and with
the feedback obtained by the case studies the approaches could be improved. Experiments are rare
among the analyzed papers and the cause could be the lack of wide real adoption of the agile
method tailoring technique, since experiments should have to involve multiple cases in a
controlled setup (Tonella et al., 2007).
More than half of the analyzed papers are non-specific to any agile method. This data
indicates that the majority of the research on agile methods tailoring could be applied to
organizations independently of the agile method chosen. The rest of the papers use agile methods
tailoring approaches mainly focused on Scrum or XP. Real world organizations have been
adopting mainly Scrum and XP (Versionone, 2016) as their agile methods and this shows research
24
connection with practical agile adoption.
The analyzed agile method tailoring procedures or techniques that were non-specific
worked based on a set of agile practices no matter the agile method chosen by the organization
and on a model to select the practices to be adopted. There were also approaches combining agile
methods to try to get the best of different agile methods (El-Said, Hana, & Eldin, 2009; Ayed,
Vanderose, & Habra, 2012).
Finally, a comprehensive analysis of the agile adoption research literature showed that, in
general, digital tailoring criteria can be divided into several categories (Kalus & Kuhrmann, 2013),
namely team, internal environment, external environment, and project objectives (see Table 2.3).
Those criteria are directly or indirectly influence the decision to adopt a particular project
management methodology. This study has borrowed this approach for the purposes of the research
model synthesis, which is going to be covered in the second chapter. The details of
abovementioned papers’ results are discussed in the third chapter with regards to compare the
results of this work’s statistical analysis.
1.5.
Summary of Chapter 1
The conceptual issues of agile methodology and overview of agile methods with respect to
web- and software development were presented in this chapter. Several research areas, where the
majority of research papers fall were identified. This study is concerned with problems of adoption
choice agile practices. The current state of the agile methods tailoring literature was summarized
in this chapter.
The results of the analysis and classification showed that this is currently still a relevant
research topic, as the number of published studies have been growing over time and the studies
are originated from multiple countries around the globe. Moreover, there are no similar research
studies done in Russia, hence it can be useful not just for the companies, but also in cross-cultural
studies if they will take place.
In general, agile methods factors and tailoring research should be considered mature since
more than half of the papers use empirical research methods. There are, however, still papers that
do not use primary data or which do not provide enough empirical evidence. The literature analysis
of the area identifies several influential works, with extensive list of possible agile adoption factors
and categories.
For the purpose of this research, the next chapter will contain the synthesis of the factors
based on the considered articles. This research’s is therefore aims to provide a set of detected
factors and to investigate the impact that those factors have on agile practices and methods
adoption among Russian IT and digital companies, since there is a lack of research on this matter
25
in the country.
From the practical point of view, the proposed recommendations which is derived from the
analysis could help project managers to select agile methodology for adoption based on the level
of importance of each of the criteria has on the organization’s context.
To sum up, there are currently no studies that study the factors that influence factors of
agile adoption for digital Russian teams, and this thesis aims to fill this research gap. This analysis
will help identifying certain managerial patterns and implicit practices, and, hence, to help teams
that are considering agile transition in identifying factors that are require special attention. The
goals, research questions, and the details of the research design and adopted theoretical model are
covered in the next chapter of this study.
26
CHAPTER 2. THEORETICAL FRAMEWORK FOR INVESTIGATING FACTORS
INFLUENCING THE ADOPTION OF AGILE METHODS
2.1.
Identifying research goal and research questions
In previous chapter a review on existing agile methods and problem of their adoption and
application with respect to digital projects and web- and software development have been
provided. The information was provided also on the general state of project management
approaches to modern software development, the main differences between waterfall and agile
approaches were overviewed, main agile techniques were reviewed, the problem of method choice
to a particular IT projects and project effectiveness was stated, and modern research gaps were
found.
As has been shown above, while being extremely recognized methodology in the
professional project management community, details of agile application and adoption are still not
fully investigated in academic research and there is a need for a “bridge” between professional
community and academic research.
At the same time, there is still not enough evidence from developing countries
developments on the matter, whereas many of those countries have been experiencing significant
growth in software and digital markets, and, hence, present an interest for the investigation. This
gap is currently being filled with increasing number of research papers from Brazil, India, Republic
of South Africa, etc.
Several current “hot topics” for the research were identified in the previous chapter,
however, they cannot all be investigated due to the limit nature of master’s thesis itself and the
time given; instead, this study will be mainly concerned with problems of adoption and practical
implementation of agile methods in managing digital projects, namely with identifying what
factors are the most important for management decision of agile practices adoption, and the way
the implementation process of agile methods adoption should be held.
Having stated that, this work is also being limited by looking only at Russian companies,
operating in high-tech, digital, and IT fields, since there is lack of literature that investigate this
geographical area, and instead rather concentrate either on global level, or on developed countries
with more acceptation of agile practices.
There are several research frameworks that had been developed in the recent years, which
help to identify the characteristics of the project which incline the sense to use agile methodology.
This chapter’s aim is to make a reasonable choice of a research model, and to create a research
framework which will make it possible to analyse Russian digital market.
27
The rest of the study is devoted to gain practical evidence of the adoption and
implementation of agile project methodology in Russian digital companies, with purpose of
deriving managerial recommendation and drawing some possibilities for further research
development. Particular additional interest of research with this matter, is to provide an insight on
what managerial implications concerning agile adoption and tailoring might be derived from the
results of the study.
The goal of this study is therefore to investigate the state of agile methods adoption and
factors that encouraged project managers to make this choice in order to reveal good practices
and to develop a set of recommendations for project managers on choosing agile principles
In order to reach stated goal, this study is aiming to answer the following research
questions:
Q1 what factors in the research literature are said to influence the decision to adopt the
agile practices?
Q2 which agile methods and practices are being used in Russian digital projects?
Q3 what is the relation between adopted agile methods and the implicit factors for Russian
digital development teams?
Hence, this study is going to provide, first of all, an evidence from current situation of
Russian agile adoption for the global research community, and secondly, to be of a value to digital
companies and project managers working in Russia, and to agile teams in general, so that they are
able to employ agile project management initiatives and increase their competitive advantage.
As well it might be of use for Russian software and digital teams that are trying to improve
their productivity by adopting some practices or methods but do not have practical framework or
insights for the importance of factors that influence the decision to adopt certain practices.
2.2.
Choice and justification of the research design
Previous literature review on the subject indicated a “boom” on publications concerning
various aspects of agile software development. At the same time, the problem remains with
identifying what factors, according to development teams and project managers help to decide to
whether or not adopt the agile methods to a particular project or organizational context.
At the same time there is a gap between the professional project management and academic
research community, i.e. a disparity when it comes to academic investigation of agile methods
adoption, since the majority of agile publications refer to professional conferences and
management journals, and not the academic once. Moreover, this problem particularly concerns
Russian development and project management community, that historically have less relied on
methodology guidelines and oftentimes do not possess any KPIs and adoption guidelines.
28
The objectives of the study are as follows:
(1) To identify to which agile methods and techniques are being implemented in Russian
digital companies;
(2) To identify factors and project characteristics that imply that the agile methods are
more preferable to the traditional approach according to the Russian digital project
managers and development teams;
(3) To produce insights on how to improve the adoption of agile methods in an average
representative Russian IT company / digital agency;
According to the appropriate research identification framework (see Table 2.1.), the choice
of research design should be based on the state of previous investigation of the researched area
(Edmondson, McManus, 2007). The study was divided into several parts in order to fulfil the stated
research goals.
Previous literature review on the subject indicated quite a gap between the professional
project management and research community in Russia, i.e. a disparity when it comes to academic
investigation of productivity increase due to agile methods application in companies. With respect
to this inconsistency the nature of this research is exploratory. At the same time, the method was
chosen as quantitative due to the maturing of the research area and more frequent usage of
quantitative techniques (via survey design, in particular).
Table 2.1. Categories of methodological fit in field research. (Source: adapted from
Edmondson, McManus, 2007.
State of theory
Research questions
Nascent
Intermediate
Mature
Open-ended
Hypothesis about the
Focused questions/
investigation of the
relationship between
hypotheses
phenomenon
new and established
concerning existing
phenomena
constructs
Type of gathered
Qualitative, open-ended
Both qualitative and
Quantitative data,
data
data which has to be
quantitative data
focused on specific
interpreted
area
Theoretical
Suggestive theory,
Provisional theory,
Supported theory,
contribution
invitation for further
which oftentimes
which might add new
research, set of new
integrates previous
processes, views,
problems opened by the
parts of different
mechanisms to
study
studies done before
already existing
theories
29
Review of agile concepts and methodologies
Narrowing the focus by selecting the problem of identifying main agile adoption factors
Literature review of papers investigating agile adoption and taloring methods and factors
Search for the appropriate quantitative model and research framework
Research model adopted for the purpose of the study, research design is chosen
Data collection (survey)
Statistial analysis (PLS-SEM)
Interpreration and recommendations
Figure 2.1. Research process: from literature review to the statistical analysis. (Source:
author).
With respect to all this, the study was divided into three parts (see Figure 2.1.):
(a) synthesis of research framework in order to fulfil the goal of the study (section 2.3. of
the second chapter);
(b) identification of agile methods used in Russian digital project management, gaining
more understanding about why project managers choose to adopt agile practices, and,
consequently, an identification of IT project characteristics that would most probably require an
agile approach (section 3.1. of the third chapter);
(c) interpretation of research results and deriving of managerial recommendations on agile
methodologies adoption that will suit an average Russian digital studio / IT company. In that way,
the study is going to have both theoretical and managerial contribution to the area of agile project
management methods (sections 3.2. and 3.3. of the third chapter);
It is important to characterize the nature of this research fully. Therefore, firstly, we state
that the research is exploratory, according to the goal and objectives, because we are trying to
identify and explore the relationship between the set of explicit variables and implicit factors and
constructs. Hence, this research’s objective provides with expectation of providing the patterns
and relationships between abovementioned parameters (Hair et al., 2016).
30
This research is also applied, since we are planning to add new knowledge for the concrete
industry and with the purpose of deriving practical recommendations for the digital project
mangers, scrum-masters, or other people involved in the digital project development and
management.
Finally, the research is quantitative, since we believe that the exploratory purpose can be
better reached with combination of factor analysis and path dependence analysis. The data analysis
framework will be explained later in this chapter. Our goal is objective measurement and reliable
results which can be interpreted in more comprehensive way; which ca be better guaranteed with
qualitative measures.
Speaking of the procedures, this research uses bibliography secondary data analysis and a
survey that focused specifically on Russian project management teams. Bibliographical research
intended to review previous academic achievements and models proposed on the topic to research
gaps, and was covered in the first chapter. We analyzed published articles on the agile methods
and agile tailoring topic. With the application of bibliographical research, we analyzed several
existing approaches to agile factors identification and agile implementation issues, which in turn
let us derive the research framework, which will be explained in section 2.3.
The survey has been sent to targeted groups, and has been posted on LinkedIn, Facebook,
and Vkontakte groups, devoted to agile project management, or digital project practices. In total
83 answers have been received. Data has been gathered using an on-line survey form available
during the whole research process. We investigated how commonly used individual agile practices
are, combinations of practices (which are not the same thing) and their frequency of usage, as well
as the degree of compliance to agile methodologies (Scrum and XP), and as how successful
practitioners perceive the adoption.
2.3.
Deriving theoretical research model
The first research question [Q1] was formulated as: what factors in the research literature
are said to influence the decision to adopt the agile practices? In the end section 1.4 of the first
chapter, we have stated that this study is mainly going to adopt the comprehensive adoption factor
list (or ‘tailoring criteria’) from the systematic literature review of Kalus and Kuhrmann (2013),
since the literature review of this study identified that this is one of the most recent and
comprehensive research papers on the matter (127 papers researched in total out of 1600
population, see Table 2.2).
31
Table 2.2. Number or researched papers on agile methods adoption (Source: Kalus and
Kuhrmann, 2013).
Source
Number
Number (cleaned)
Selected
ACM
210
210
44
Springer
60
60
13
IEEE
210
210
22
Wiley
1120
329
44
Misc
Sum
4
1600
809
127
This study identified four categories of agile tailoring factors, or “tailoring criteria”,
including Team, Internal Environment, External Environment, and Objectives (see column
Constructs in Table 2.3.). Those criteria are said to influence the managerial decision to adopt
agile practices in a particular project context, but are quite difficult to observe directly, which
makes them latent constructs in terms of factor analysis terminology.
For the sake of clarity, we are providing the definition of constructs. They are defined as
“ideas which are generated in mind” (Hair et al., 2016). It is therefore more generalized categories
of similar factors, that exist implicitly, and are quite difficult to measure directly. The construct is
therefore must be represented by the set of variables in order to be measured quantitatively. Those
constructs are based on the results of the literature review we provided earlier and will describe in
more detail below (see also Chapter 1).
In order to evaluate constructs contribution to adoption of agile methods, we need to look
at their presence indirectly, partially by looking at behavior of specific factors inside those
categories (see column Factors in Table 2.3.) and their connection to agile practices adoption level
in Russian digital studios. The aim of this chapter is to explain the adapted research model in full
detail.
Table 2.3. Full set of factors for software-related projects (Source: adapted on Kalus and
Kuhrmann, 2013)
Constructs
External Environment
Factors
Client availability
Client process
Legal aspects
32
Number of Stakeholders
Requirements stability
Stakeholder availability
Stakeholder background
Type of contract
User availability
User background
Internal Environment
Clear project proposal
COTS products
Database system
Financial controlling
Management availability
Management support
Maturity model
Measurement system
Operating system
Programming language
Project budget
Project duration
Project role
Project type
Prototyping
Sub contractors
Technical support
Tool infrastructure
33
Project objectives
Complexity
Conceptual solution
Degree of innovation
Documentation
Domain
Hardware development
Legacy system
Neighboring systems
Safety & security
Technical solution,
User Interface and system integration testing
Team
Distribution
Domain knowledge
Good cooperation
Previous cooperation
Previous Knowledge
Process knowledge
Size
Technology knowledge
Tool knowledge
Turnover
In order to simplify the research and make it possible to gather primary data, the number
of factors has been found too large, and it was decided to shorten the number of factors to the
reasonable quantity. The factor set was chosen based on similar works that investigated agile
factors influence (Mukhtar et al., 2013), which was in turn slightly modified by adding two
additional factors, ‘maturity level’ and ‘previous knowledge’, and is presented in the Table 2.4 in
the final form. In conclusion, we can state that these tailoring criteria allow clear classification and
the results of the literature review were used as a basis for the research model, and the follow up
survey construction.
After researching the literature, the following set of factors and latent constructs were
adopted. Figure 2.2. shows the constructs of the proposed model. On the right side of the model,
there are four constructs representing the criteria adopted for this research (see Table 2.4.). The
proposed model evaluates the impact of the exogenous factors on agile practices adopion. Those
34
“tailoring criteria” are independent and are grouped into following categories: internal and external
environment, objectives, and team as it is in the original Kalus and Kuhrmann’s work (2013).
Table 2.4. List of final set of Categories and Factors (Source: synthesis of Kalus and
Kuhrmann, 2013; Mukhtar et al., 2013; Ahmed & Sidky, 2009).
Category
Factors
Requirements Stability
External Environment
Internal Environment
Objectives
Team
User Availability
Type of Contract
Communication
Project Type
Management Support
Project Budget
Organization Size
Culture
Maturity Level
Business Goals
Innovation
Complexity
Technology
Domain Knowledge
Team Size
Team Distribution
Previous Knowledge
The “team” construct represents aspects related to the communication and characteristics
of the team involved in digital project development and management, and also with accumulated
knowledge, experience, learning curve, geographical distribution, and roles distribution and
management style.
The “objectives” category is describing the business and project goals and requirements,
as well as certain characteristics of the project such as the degree of complexity and newness of
technology involved, which represent the complexity, safety and security of the work.
The “internal environment” is the largest category that contains the context of the
organization, its size, culture, and the way the communication and processes are managed. It
includes also the main project characteristics, such as budget and type.
The “external environment” includes factors outside of the organization and project team,
such as client’s and end users’ goals and requirements, contract and sub-contracts’ types and legal
35
issues. The definition of chosen set of factors is shown in the Table 2.5. and is directly taken from
the mentioned sources.
Table 2.5. Description of agile adoption factors taken for the purpose of this research
(Kalus and Kuhrmann, 2013; Mukhtar et al., 2013; Ahmed & Sidky, 2009)
Requirements Stability
The stability of requirements directly influences the entire
approach in a project, e.g., the strategy for requirements
elicitation, architecting the solution, implementation and
test.
User Availability
The end user availability is important during the
requirements engineering, and the integration and testing
phases
Type of Contract
The type of the contract directly influences the software
process, e.g., a fixed-price model vs. time & material leads
to different strategies in handling change requests
Communication
If the team works in a good and collaborative way the need
for formalized communication/documentation may
decrease
Project Type
Depending on the project- or service type, different facets
of a software process need to be emphasized, e.g., kind of
requirements elicitation, addressed life cycle phases,
system migration. This criteria influences the software
process’s structures in general.
Management Support
The top management should actively support a project.
This is important to have the management’s support in
critical situations
Project Budget
Project budget influences the degree of formalism in a
project. A little project budget usually implies a nonformalized process (less documentation), but also requires
a strict controlling w.r.t. costs.
Organization Size
The higher the number of involved stakeholders the more
time is required to negotiate all needs and requirements.
Plus, the coordination effort increases
36
Culture
Culture is the key success factor in the software
development business and decisions to adopt agile practices.
Business Goals
A clear mission and goals are an essential artifact. They
also contain basic requirement and is essential for the
project’s success. Blurry goals are a risk.
Innovation
The degree of innovation may cause a more explorative
approach to mitigate project risks
Complexity
The complexity of a project directly influences the process,
e.g., by creating prototypes or following a divide and
conquer strategy (creating sub projects). A higher
complexity usually causes a more comprehensive software
process, more (formalized) communication, a more
formalized configuration and change management and so
on.
Technology
Little or missing knowledge w.r.t. the technology is a risk
Domain Knowledge
Little or missing knowledge w.r.t. the actual domain is a
risk
Team Size
The team size is an indicator for the effort of team
coordination. While smaller teams located in a single room
can directly communicate the need for formalization
increases if the team grows (also if distributed/virtual
teams become relevant). Team size is one of the key
criteria when selecting a software process
Team Distribution
Team distribution influences the interaction pattern in a
project. Teams located in a single room can directly
communicate while distributed teams need a more
formalized communication.
The new factor, “maturity level” was adopted from the work of Ahmed and Sidky (2009),
and represents the maturity and learning level of the software development company. It reflects
the organizational motivation to reach the certain development capacity level, and is quite known
among the professional community (Sutherland, 2009; Macriver, 2015). Another added item
“previous knowledge” reflects on the previous projects done, and represents the accumulated
37
experience of the development team (Mukhtar et al., 2013), and is definitely missing from the
original “team” construct.
The research model is represented in Figure 2.2. On the left side of the model, there is one
construct representing the agile practices adoption. The selected 40 agile practices are based on
previous studies (Esfahani, Yu, & Annosi, 2010) and also on the Version One State of Agile 2016
Research (Versionone, 2016). Table 2.6. shows the list of agile practices used as indicators on this
research. To sum up, the research model is serving the purpose of the research to explore the
relationship between implicit factors and explicit agile adoption level.
Table 2.6 List of agile practices used in this research as indicators of agile adoption level.
(Source: VersionOne2016, Esfahani, Yu and Annosi, 2010)
Indicator ID
Practice
PR_01
40-hours per Week
PR_02
Acceptance Testing
PR_03
Analog Task Board / Analog Story Board
PR_04
Behavior-Driven Development
PR_05
Brainstorming
PR_06
Coding Standard
PR_07
Collaborative Teams
PR_08
Collective Ownership
PR_09
Continuous Integration
PR_10
Customer Focused Group Review
PR_11
Daily Meeting / Daily Scrum / Daily Stand Up
PR_12
Dedicated Product Owner
PR_13
Developing by Feature / Developing by Component
PR_14
Digital Task Board / Digital Story Board
PR_15
Domain Object Modeling
PR_16
Empowered Team
PR_17
Features Team
PR_18
Inspection
PR_19
Interview - Structured
PR_20
Interview - Unstructured
PR_21
Iteration Planning / Planning Game / Sprint Planning
PR_22
Iteration Review / Sprint Review
38
PR_23
Kanban Board
PR_24
Metaphor
PR_25
On-Site Customer
PR_26
Open Office Space
PR_27
Pair Programming
PR_28
Product Backlog / Features List / Sprint Backlog / Release Backlog
PR_29
Prototyping
PR_30
Refactoring
PR_31
Reporting / Visibility of Results
PR_32
Retrospective
PR_33
Reversible Changes
PR_34
Short Release
PR_35
Simple Design
PR_36
Test-Driven Development
PR_37
Time-Boxed Planning
PR_38
Unit Testing
PR_39
Velocity
PR_40
Waste Elimination
As it was stated previously, this research is exploratory since it aims to search for patterns
and understand the relevance of the indicators and the relationships between the variables (Hair et
al., 2016) based on the data collected applied to the proposed model for agile practices adoption.
Based on the results of literature review, we cannot propose the model to further quantitative
research the agile methodology implementation before we do not have the study of the importance
of different factors, which makes the exploratory design quite relevant. The full research model is
shown on Figure 2.2 with all constructs and indicators/variables.
39
IE_1
IE_2
PR_01
PR_21
IE_3
PR_02
PR_22
IE_4
PR_03
PR_23
PR_04
PR_24
PR_05
PR_25
PR_06
PR_26
PR_07
PR_27
PR_08
PR_28
PR_09
PR_29
PR_10
PR_30
PR_11
PR_31
PR_12
PR_32
PR_13
PR_33
PR_14
PR_34
TE_1
PR_15
PR_35
TE_2
PR_16
PR_36
TE_3
PR_17
PR_37
PR_18
PR_38
PR_19
PR_39
PR_20
PR_40
IE_5
IE_6
Internal
Environment
IE_7
EE_1
EE_2
EE_3
External
Environment
OB_1
Agile
Adoption
OB_2
OB_3
TE_4
TE_5
Objectives
Team
Figure 2.2. Full research model showing latent constructs and all indicators: Hierarchical
Component Model, Formative-Reflective (Source: Afthanorhan, 2014).
40
2.4.
Data collection and analysis technique
The purpose of survey research is to get the details on particular topic in order to collect
enough data for the subsequent qualitative or quantitative analysis and to perform data mapping
(Denscombe, 2010). Critical success factor in survey research is its construction because the
wording of the questions oftentimes influences and biases the respondents (Bell, 2010); it is
therefore necessary to be very careful with stylistic and clarity of the questions posed.
Practitioners can use the knowledge of the commonality of individual practices and
combinations of practices as support in focusing future research efforts, and as decision support in
selecting agile practices. The survey for this work gathered data regarding adoption factors used
by practitioners for agile practices implementation.
A survey has been conducted during a two months, from March 2016 to May 2016. The
sample on this research includes practitioners working with agile methods and/or practices, who
also work in the area of digital project management and IT. There was a previous selection of the
positions occupied by the agile practitioners to answer the survey and there was a field on the form
the gather the position of the respondent. Data has been gathered using an on-line survey (via
Google forms) available during the whole research time.
The survey was divided into 3 main parts. Part one of the survey consisted of demographic
questions and profile of the organization. The importance of the tailoring criteria on the decision
to adopt the agile practices was assessed on part two. Part three identified the level of adoption of
the listed agile practices on the organization according to the agile practitioner’s point of view.
Parts two and three used a 5-point ordinal Likert scale to represent the answers in an equidistant
manner (Hair et al., 2016). The survey questions are presented in details on Appendix 1. We have
received a total of 83 answers coming from on-line form.
In this case use multivariate data analysis methods in order to analyze multiple variables
simultaneously, to develop and prove research findings: “multivariate analysis techniques can be
used to confirm theories testing predefined hypotheses or to explore relationships between
variables and data patterns when there is no consistent knowledge about it to formulate a theory
and hypotheses” (Hair et al., 2016).
Our research goal is to understand the impacts of selected factors (project criteria) on agile
practices adoption. Since both the tailoring criteria and agile practices are represented by multiple
indicators, the simultaneous multiple variables analysis feature multivariate data analysis fits well
into our objective. We are going to establish of the relationships between the constructs and
indicators generated by multivariate data analysis.
Currently, researchers use second generation multivariate analysis techniques such as
41
structural equation modeling (SEM) (Wong, 2013). This model allows latent constructs to be
included in a model and measured indirectly by indicator variables, since they cannot be directly
measured or they are hard to measure. All constructs in proposed model are unobservable since
we cannot measure them directly. There are two types of SEM that are suitable for our analysis:
Covariance-based SEM (CB-SEM), and Partial Least Squares (PLS-SEM) (Wong, 2013). The
goal has narrowed to, therefore, just choose the best fit technique.
First option, CB-SEM is applied for theory testing and confirmation on large samples sizes
through hypothesis testing (Wong, 2013) using a technique to verify if the proposed model can
estimate the covariance matrix for a sample data set. It is a combination of path modeling and
factor analysis (Iacobucci, 2010). It requires some assumptions such as normally distributed data,
minimum number of indicator per construct, minimum sample size and the theory to model
mapping to be correctly implemented (Wong, 2013). If the assumptions are violated, then gathered
results could be biased.
Second option, PLS-SEM can be applied to prediction and to theory development working
with complex models and smaller sample sizes (Hair et al., 2016). It is a combination of path
modeling and principal components (Iacobucci, 2010). The idea behind the model is to maximize
explained variance and at the same time check data quality of the measurement models. PLSSEM can work with no data distribution assumptions; it works with small sample size; it is not
concerned with model specification correctness; and it fits exploratory research approaches
(Wong, 2013). Research areas such as information systems, business and marketing adopt PLSSEM (see Table 2.7.). Since the PLS-SEM is far more flexible and can be applied more frequently
than CB-SEM, we have decided to proceed with this option.
Table 2.7. PLS-SEM review studies from business disciplines. (Source: Hair et al., 2016).
The prediction features of PLS-SEM pair well with our objective and also allow future
42
theory development. Other characteristics of PLS-SEM that are need by our research are:
constructs with few indicators; it handles well both formative and reflective constructs; it works
with complex models composed of multiple constructs and indicators; and it has a great statistical
power to identify significant relationships in the population. The iteration process of this statistical
method is represented in Figure 2.3.
1. Defining individual constructs: The first step is to define the constructs
theoretically.
Conduct a pretest to evaluate the item.
A confirmatory test of the
measurement model is conducted using CFA.
2. Developing the overall measurement model: The measurement model is also known as
path analysis. Path analysis is a set of relationships between exogenous and endogens
variables. This is shown by the use of an arrow. The measurement model follows the
assumption of “unidimensionality”. Measurement theory is based on the idea that latent
constructs cause the measured variable and that the error term is uncorrelated within
measured variables. In a measurement model, an arrow is drawn from the measured
variable to the constructs.
3. Design the study to produce the empirical results: In this step, the researcher must
specify the model. The researcher should design the study to minimize the likelihood of
an identification problem. Order condition and rank condition methods are used to
minimize the identification problem.
4. Assessing the measurement model validity: Assessing the measurement model is also
called CFA. In CFA, a researcher compares the theoretical measurement against the reality
model. The result of the CFA must be associated with the constructs' validity.
5. Specifying the structural model: In this step, structural paths are drawn between
constructs. In the structural model, no arrow can enter an exogenous construct. A singleheaded arrow is used to represent a hypothesized structural relationship between one
construct and another. This shows the cause and effect relationship. Each hypothesized
relationship uses one degree of freedom. The model can be recursive or non-recursive.
6. Examine the structural model validity: In the last step, a researcher examines the
structural model validity. A model is considered a good fit if the value of the chi-square
test is insignificant, and at least one incremental fit index (like CFI, GFI, TLI, AGFI, etc.)
and one badness of fit index (like RMR, RMSEA, SRMR, etc.) meet the predetermined
criteria.
Figure 2.3. Steps while performing PLS-SEM. (Source: Wong, 2013)
43
2.5.
Summary of Chapter 2
In the chapter we have covered the research process, identified research goal, questions
and objectives. The goal of this study is therefore to investigate the state of agile methods adoption
and factors that encouraged project managers to make this choice in order to reveal good practices
and to develop a set of recommendations for project managers on choosing agile principles
We have stated that this research has applied, quantitative, and explorative nature and uses
bibliographical analysis of secondary data and a survey for primary data analysis. Findings of the
literature review was an extended classification for software and web-development factors based
mainly on the work of Kalus & Kuhrmann (2013) and other similar articles.
Finally, all the steps above allowed us to form a research model based on multivariate
analysis technique, aiming to explore the relationship between factors of agile adoption and it’s
actual degree. PLS-SEM was chosen investigate the relationships between the factors and
constructs on the one hand, and the agile practices adoption construct on the other hand. Survey
was designed in order to gather necessary primary data for the statistical analysis. Survey’s details
and design can be seen in details on Appendix 1. The results of data analysis and interpretation are
going to be covered in Chapter 3.
44
CHAPTER 3. RESULTS OF THE SURVEY AND FACTORS INFLUENCING
DECISION ON AGILE METHODOLOGY ADOPTION IN RUSSIAN DIGITAL
INDUSTRY
3.1.
Descriptive statistics on respondents and organizations
83 respondents in total have participated in the survey (the structure of the survey can be
found in the Appendix 1). Most of them are employed as project managers and/or SCRUM masters
[менеджер проекта/скрам-мастер] (45.78%). The second largest position were being a part of
the development team [разработчик] (18.07%). The “Other” category comes on third place with
total of 14 professionals (16.87%), and decoded as follows: 5 product managers, 3 product owners,
4 marketing specialists and 2 technical training specialists. 10.84% of all respondents were testers
[тестировщики], and finally, 8.43% identified themselves as IT Consultants.
Therefore, the sample size was quite diverse and, hence, allowed to take into account not
only project managers and developers point of view, but reflected views of other stakeholders as
well (see Figure 3.1.).
8,43%
16,87%
45,78%
10,84%
18,07%
Project Manager / SCRUM master
Developer
Tester
Other
IT Consultant
Figure 3.1. Respondents: roles in the team. (Source: analysis of survey results).
Figures 3.2. and 3.3. provide the statistics on the sample population’s both general level of
experience with agile methods and years of experience with agile approach. Approximately half
of the respondents (49.4%) have been working with agile methods for 1 to 2 years. Consequently,
48.19% of respondents claim they have moderate experience with agile approach [умеренное
владение практиками]. 34.94% evaluate themselves as possessing beginner-to-medium
knowledge of agile methodology [начальное понимание практик].
45
A substantial portion of the respondents (32.53%) have from 3 to 4 years of experience
with agile methods and practices, and together with those who have more than 5 years’ expertise
(6.02%) they comprise 38.55% of the total number of answers. 13.25% of professionals evaluate
themselves as “experts” [экспертное знание] in the area of agile management. This makes us
believe that the sample is of a high quality and the expert opinions gathered are of a great value in
investigation the state of agile management practices implementation in Russian digital
companies.
6,02%
12,05%
49,40%
32,53%
From 1 to 2 years
From 3 to 4 years
Less than year
5 or more years
Figure 3.2. Respondents: years of experience. (Source: analysis of survey results).
Finally, there are 12.05% of respondents have less than a year experience with agile
approach, and only 3.61% say that they possess almost no knowledge and understanding of agile
methods. Nevertheless, answers that were gathered from this category were useful while analyzing
initial challenges with agile adoption as well as make it more cleat as to which factors let the
managers make that decision.
Generally, we can say that the data on years of experience and level of self-perceived
knowledge level complement and correspond with each other. Further statistical analysis were not
performed due to the fact that this is not directly a research question of this study.
46
3,61%
13,25%
48,19%
34,94%
Moderately experienced
Beginner-to-medium knowledge
Expert
Almost no experience
Figure 3.3. Respondents: level of expertize with agile methods. (Source: analysis of survey
results).
Speaking of the organization’s size, the relative of them (33.73%) are comprises of 20 to
50 employees, and the second item is those companies with less than 20 people working (28.92%)
This reflects with the fact that average digital agency’s size is balancing around 30 people
according to leading digital consulting agency, Tagline (see Figure 3.4). At the same time, more
approximately 29% of respondents work in companies with more than 100 employees, which
speaks to the fact that agile methods are being actively used in larger companies as well. Important
to note that, according to international statistics, around 60% of software organizations using agile
methods have more than 100 employees (VersionOne, 2016).
Second research question [Q2] was formulated as follows: which agile methods and
practices are being used in Russian digital projects? Scrum is the expectedly by far the most used
agile method among Russian digital (75.90% of all companies), followed by Kanban techniques
(55.42%). With a large gap come methods such as Lean, FDD, Hybrid methods (18.07%, 13.25%,
and 13.25% accordingly) (see Figure 3.5.). Crystal, XP, and DSDM are not largely employed
among respondents (less than 10% companies in total have adopted them). NB: agile method and
agile practice are not on the same generalization level and agile method can be composed of several
agile practices / techniques.
Different agile practices are ranked on Table 3.1. by relative agile practices adoption level,
and, as can be seen, SCRUM practices, such as Features list / Product backlog / Sprint backlog /
Release backlog are on the top of the list. At the same time, there is a tendency to use multiple
47
agile practices at a time, which we can already derive as an accepted project management practice
among digital managers. Hybrid methods are not popular, however, companies tend to mix
techniques from distinct agile methods, which is the global tendency (VersionOne, 2016).
20,48%
28,92%
8,43%
8,43%
33,73%
less than 20
20-50
51-100
101-200
more than 200
Figure 3.4. Companies / agencies’ size. (Source: analysis of survey results).
Scrum
63
Kanban
46
Lean
15
FDD
11
Hybrid
11
Other
8
ASD
7
Crystal
4
XP
3
DSDM
3
Figure 3.5. Adopted agile methods ranking. (Source: analysis of survey results. NB: sum
does not come up to 83 since the majority of companies employ several agile methods at a
time).
48
Table 3.1. Top-20 agile practices adopted in Russian agile digital teams. (Source: analysis
of survey results).
#
Distinct agile practice
Statistical
Indicator
1
Features list / Product backlog / Sprint backlog / Release backlog
PR_28
2
Reporting / Visibility of results
PR_31
3
Digital story board / digital task board
PR_14
4
Brainstorming
PR_05
5
Prototyping
PR_29
6
Retrospective
PR_32
7
Development by feature / by component
PR_13
8
Refactoring
PR_30
9
Short release
PR_34
10 Iteration planning / Planning game / Sprint planning
PR_21
11 Daily meeting/ Daily Scrum / Daily stand up
PR_11
12 Open Office Space
PR_26
13 Empowered team
PR_16
14 Kanban board
PR_23
15 Iteration review / Sprint review
PR_22
16 Continuous integration
PR_09
17 Features team
PR_17
18 Analog story board / analog task board
PR_03
19 Acceptance testing
PR_02
20 Collective ownership
PR_08
3.2.
Data assessment process and results of the data collection
The rest of this chapter covers the model assessments, discussion of results and possible
validity threats. As was mentioned in the previous section of the study, in order to get to the results,
we applied the guidelines proposed by several papers (Hair et al., 2016; Wong, 2013) and the tool
used for modeling and evaluation was SmartPLS 3.0 (Ringle, Wende, & Becker, 2015). The
evaluation step included the execution of the PLS, bootstrapping and blindfolding algorithms.
After the bootstrapping and blindfolding algorithms were executed and necessary
adaptations of the model was performed, we then started to assess and evaluate the measurement
models of the adjusted structural model. The purpose of the different assessments and evaluations
of the model was to provide the most relevant set of indicators to increase the prediction aspects
of the model.
The PLS-SEM model should be validated by three assessments (Wong, 2013. The
reflective model assessment [1] analyzes the relationship between the reflective constructs and its
49
indicators. The idea is to validate that all indicators are caused by the construct. On the formative
model assessment [2], the idea is to check if the indicators cause the construct. The structural
model assessment [3] defines if there is empirical support the proposed model/concept.
3.2.1. Reflective Model
The constructs and its indicators in our model represent the reflective measurement model.
The reflective measurement model was assessed for reliability and validity. Composite reliability
indicates the constructs internal consistency and in exploratory research, and values between 0.60
and 0.70 are considered to be satisfactory (Hair et al., 2016).
Convergent validity and discriminant validity compose the validity assessment. The
convergent validity evaluation used average variance extracted (AVE). In this approach, each
construct’s AVE value should be higher than 0.50 to indicate a sufficient degree of variance (Hair
et al., 2016). Discriminant validity defines how a construct is distinct from the other constructs
using empirical standards and for that purpose we took Fornell-Larcker criterion (Henseler. Ringle
and Sarstedt, 2015), which can be calculated by using the square root of the AVE and must be
greater than the correlation values for all other constructs (Wong, 2013).
Table 3.2. Composite reliability and average variance extracted (AVE) for the four
constructs.
Construct
AA
EE
IE
OB
TE
Composite Reliability
Formative
0.817
0.789
0.799
0.725
AVE
Formative
0.573
0.631
0.678
0.581
Table 3.3. Fornell-Larcker test results
Construct
AA
EE
AA
Formative
IE
EE
0.643
0.718
IE
0.678
0.417
0.748
OB
TE
0.118
0.326
0.076
0.302
0.175
0.553
OB
0.821
0.276
TE
0.745
The results for composite reliability and AVE are summarized in Table 3.2. and present
satisfactory results for the evaluation criteria (composite reliability higher than 0.70 and AVE
higher than 0.50). The results for Fornell-Larcker criterion confirmed that all the reflective
50
constructs fulfill the criterion (see Table 3.3.).
The indicator’s loadings are also an important measurement for the reflective model
assessment. The general recommendations tell that the absolute loading value should be higher
than 0.70 (Hair, Ringle, & Sarstedt, 2011). The indicators with loadings between 0.40 to 0.70
should be analyzed and only removed if that would result in an increase of the composite reliability
value for the construct (Hair et al., 2016). Indicators with absolute loadings below 0.40 should be
removed from the model.
During the reflective model assessment, we removed a total of 7 out of 18 indicators from
the model. The final loading values for the indicators on the adjusted model are shown in Table
3.4. The removed indicators have no loading value on the table. In other words, after the
assessment, only relevant indicators are part of the model. These are the indicators representing
tailoring criteria that can cause impact on agile practices adoption.
Table 3.4. Reflective indicator loadings after model adjustments.
ID
Indicator
EE_1
EE_2
EE_3
IE_1
IE_2
IE_3
IE_4
IE_5
IE_6
IE_7
OB_1
OB_2
OB_3
TE_1
TE_2
TE_3
TE_4
TE_5
Requirements Stability
User Availability
Type of Contract
Communication
Project Type
Management Support
Project Budget
Organization Size
Culture
Maturity Level
Business Goals
Innovation
Complexity
Technology Knowledge
Domain Knowledge
Team Size
Team Distribution
Previous Knowledge
Loading Value
0.807
Removed
0.721
0.713
0.786
0.875
Removed
Removed
Removed
0.688
0.715
Removed
-0.551
-0.609
Removed
Removed
0.615
0.639
3.2.3. Formative Model
The formative indicators only cause latent variables and might not correlate among
themselves, making “internal consistency reliability and convergent validity not relevant to its
assessment” (Wong, 2013). The "Agile Adoption"(AA) construct and agile practices indicators
51
represent the formative measurement model in the proposed model. The significance of the
formative indicators should be validated using bootstrapping and after that, by applying
multicollinearity analysis.
The bootstrapping analysis relies on the indicator’s weight (relative importance of the
indicator) and the indicator’s loading (absolute importance of the indicator) analysis to assess the
indicator’s significance (Hair et al., 2016). The bootstrapping results, based on significance level
of five percent for the indicators weights or loadings, should be at least 1.96 to justify the retention
of the formative indicator on the model. If both weight and loading values are not significant, the
indicator should be removed.
Table 3.5. shows the weight and loading values for the indicators retained in the model
after bootstrapping analysis. During the assessment, we removed some indicators if both
measurements were not significant then, the indicator was not relevant for the construct. Even
though low weight values have been found in some indicators these have been retained on the
adjusted model based on significant loading values. Three indicators of agile practices (Pr_04,
PR_24, and PR_40) have been removed from the model, leaving 37 practices in total.
The multicollinearity analysis can show if the indicator is not significant based on
redundancy. Redundancy can impact on the weight estimation and on the statistical significance
of the indicator (Hair et al., 2013). The variance inflation factor (VIF) is a collinearity measure
and for each indicator it should be less than 5.0.
After this assessment, only relevant indicators continue to be part of the model. These
formative indicators represent relevant agile practices for the model based on the data gathered
from the sample via the survey.
3.3.3. Structural Model
The structural model assessment intends to check if empirical data supports the structural
model based on coefficients of determination (R2) evaluation and on path coefficient analysis.
Another approach also includes collinearity, effect sizes and predictive relevance assessments to
validate the structural model. We used both approaches in our assessment. Strictly speaking, this
assessment validates the level of influence between the constructs on the model and the predictive
aspects of the model.
The collinearity assessment is the same as the one applied to the formative model but, in
this case, it is applied to the predictor constructs (Hair et al., 2016). The VIF values should be
under 5.0 to avoid collinearity problems and in the adjusted model.
Path coefficients assessment provides the statistical significance of the relationships
between the constructs and also the relevance of their relationships. The statistical significance of
52
the relationships can be determined using the bootstrapping algorithm resulting t values and the
significance level used as a parameter for the algorithm.
We have considered a significance level of five percent resulting in a t value threshold of
1.96. Meaning that the t values of the indicators should be higher than the threshold of 1.96 to be
significant. The relevance of the relationships between constructs should be evaluated using the
path coefficients from the PLS algorithm execution (Hair et al., 2016). The values can vary
between “+1” and “-1” where “+1” represents a strong positive relationship, where “-1” represents
a strong negative relationship while values close to “0” represent a weak relationship.
Table 3.5. VIF values for exogenous constructs
Construct
External Environment
VIF
1.890
Internal Environment
Objectives
Team
1.753
1.137
1.714
Table 3.6. Statistical significance and relationship relevance results for the adjusted model
using a significance level of 5 percent.
Relationship
External Environment ->Agile Adoption
Internal Environment ->Agile Adoption
Objectives ->Agile Adoption
Team ->Agile Adoption
t Value
3.731
2.671
0.187
2.481
Statistically
Significant1
Yes
Yes
No
Yes
Path
Coefficient
Size
0.447
0.351
0.017
0.341
Table 3.6. summarizes the t values for statistical significance and path coefficient relevance
analysis and Table 3.8. represents the validated final adjusted model according to all the
assessments and tests. The results of this figure show that the relationships between the "External
Environment" and "Agile Adoption" constructs, the "Internal Environment" and "Agile Adoption"
constructs, and "Team" and "Agile Adoption" constructs are statistically significant at an error
level of five percent.
The structural paths between the "Objectives" and "Agile Adoption" constructs, and the
were not considered statistically significant since they did not reach the t value threshold (0.187)
of 1.96 for the two-tailed test (Hair et al., 2016).
The path coefficients on Table 3.6. indicate that “External Environment” criteria have
the strongest predictor positive effect on agile practices adoption (0.447), and is followed by the
53
“Internal Environment” factor with a positive effect (0.351) and the “Team” factor with a positive
effect (0.341). The “Objectives” do not produce any relevant effect on agile practices adoption.
The coefficient of determination (R2 value) defines the model’s predictive power and is
the most common measure for structural model evaluation. It represents the combined effect of all
exogenous latent variables on the endogenous latent variable and can be obtained using the PLS
algorithm. The model showed the R2 value of of 0.596. This means that all the factors have a
moderate impact on agile practices adoption.
Effect size (f2) was measured to analyze the impact of the exogenous construct on the
endogenous construct by using the R2 value of the adjusted model and R2 values calculated when
the analyzed construct is omitted (see Table 3.7). "External Environment" and "Previous
Knowledge" constructs have a medium effect size on the "Agile Adoption" construct. The rest of
the constructs have a small effect size on the "Agile Adoption" construct.
The prediction aspect of the model is one of the major objectives when executing PLSSEM procedures. The adjusted model’s predictive relevance for the endogenous construct "Agile
Adoption" has been evaluated using the blindfolding algorithm. The result of cross-validated
redundancy for the "Agile Adoption" construct was above zero and supported the claim of
predictive relevance of the model. It means that the adjusted model shows predictive behavior for
the provided dataset.
All the assessments on the structural model showed that the adjusted model has moderate
explanation of 59.6% of the relevance on the "Agile Adoption" construct and predictive relevance
of the model has been confirmed. The results showed that the model can predict agile practices
adoption based on the set of project-related criteria.
Table 3.7. Effect size f2 values for the exogenous constructs.
Construct
3.3.
f2 Value
Effect size
External Environment
0.234
Medium
Internal Environment
0.078
Medium
Team
0.031
Small
Objectives
0.000
Small
Results interpretation and discussion
The results are being discussed following: researched criteria impact and agile practices
adoption among Russian digital teams. The researched criteria impact section shows the effect of
54
each of the factors on the agile practices adoption process. The agile practices adoption section
can be found in shows the most adopted practices for the sample of this research and provides
insights on the results patterns compared to the literature.
3.3.1. Analysis of relation between researched factors and adopted agile methods
Third research question [Q3] was formulated as follows: what is the relation between
adopted agile methods and the implicit factors for Russian digital development teams?
Table 3.8. shows the final list of identified critical factors. The “External Environment”
category has a moderate positive impact on agile practices adoption, but still highest impact among
the rest categories. The items of the “External Environment” that has lest after all the adjustments
are “Requirements Stability” (EE_1), and “Type of Contract” (EE_3) with the fist having higher
influence (0.807) than the latter (0.677). On the other hand, “User Availability” (EE_2) item,
which is also part of the external environment tailoring criteria, did not impact the agile practices
adoption.
Among four important factors of “Internal Environment” category, there are “Project
Type” (0.786), “Communication” (0.713), and “Maturity Level” (0.688). The highest positive
effect has the “Management Support” factor (0.875), which corresponds with the results gathered
from open survey questions (see the next section).
Meanwhile, the “Team” category, while having statistically significant impact on the agile
adoption construct, it has the lightest one among the rest factors. This might be explained by
different cultural approach and differences with leading Russian business. “Technology
knowledge” is the one factor that have a negative influence on the adoption (-0.609).
Table 3.8. Final list of all relevant factors that influence agile adoption (from the most
positive to the most negative).
ID
IE_3
EE_1
EE_3
IE_1
IE_7
IE_2
TE_5
TE_4
TE_1
Indicator
Management Support
Requirements Stability
Type of Contract
Communication
Maturity Level
Project Type
Previous Knowledge
Team Distribution
Technology Knowledge
Loading Value
0.875
0.807
0.721
0.713
0.688
0.677
0.639
0.615
-0.609
55
Reviewing the literature, we have found papers using the external environment criteria as
part of their approaches. For instance, Khan and Beg (2013) proposed
a contingency factors
approach based on project profile, external environment, internal environment and objectives.
Kruchten (2013) used criteria to define a method to adopt and adapt agile practices to the
organization’s context. Sidky et al. (Sidky, Arthur and Bohner, 2007) developed a very
sophisticated procedure for agile adoption prediction based on method engineering that used
multiple criteria (team, internal environment, external environment and maturity level) to evaluate
the projects and the organization and define agile practices to be adopted.
Results of our adjusted model showed that the "External Environment" construct is
statistically relevant and has a moderate positive effect on the "Agile Adoption" construct (see
Table 3.7) and highest among all the other factors researched for Russian companies. This means
that the external environment indicators of the adjusted model such as “requirements stability”
(EE_1) and “contract type” (EE_3) positively affect the adoption of agile practices among Russian
digital teams. It also indicates that “user availability” (EE_2) was found irrelevant to indicate
impact on agile practices adoption.
Mukhtar et al. (2013) used case based reasoning on previous experiences as the unique
factor for agile practices selection method implemented with artificial intelligence techniques.
McHugh et al. (2014) reviewed the literature to understand the barriers for agile adoption in the
medical domain. Main barriers were related to items in the team and internal environment tailoring
criteria groups such as team size, management support and project type. Sultana et al. (2014)
proposed a hybrid model mixing agile practices to resolve issues in the Pakistani software industry
and evaluated it with a case study and expert review. The tailoring criteria of the paper were also
based on internal environment indicators. This corresponds with our findings since the “Team”
category was found statistically significant for the agile adoption prediction.
In the literature we were able to find references that team size (TE3) is an important factor
for agile methods adoption (Deemer et al., 2010) but our results have not supported that fact for
the Russian population since the “team size” (TE_3) was removed from the model. Another
important discussion on the literature is about “distributed teams” (TE_4) (Bass, 2013, Shrivastava
and Date, 2010), and our finding here are similar on that issue.
Interesting issue to point out and speculate about is the fact that “Management Support”,
“Requirements Stability” and “Type of Contract” are among top-3 influencing factors, and such
“soft” factors as “Communication” and “Team Distribution” have less positive impact on the agile
adoption. This might be preliminary explained by the local business culture and can be supported
with some of the statements that we have received during the survey collection:
56
“Lack of understanding / acceptance by the customers, misinterpretation of the role of Project
Owner and agile methodologies in general”
“Desire of the customer to save resources”,
“Over-regulated requirements to an end product and wordy project specifications”
“Lack of support and top-managers’ fear of chaos”
“The imposition of the top management of agile methods without a clear understanding of when
they should be applied”
“Rigid, government contracts”
and other similar description. The reasons behind this can be further investigated, but at this point
we can claim that client and management relations are the critical factor that must be take into
account while considering the agile adoption.
Generally, around 79% of respondents claimed to be satisfied with agile practices
transition, another 15% said that their teams are transitioning at the moment and there is no
substantial data yet that would either prove or disprove the efficiency of the agile adoption.
Approximately 25% added that there is a difficulty in identifying the effective KPI for the agile
methods effectiveness, and this is a topic worth investigating further and should be a subject of
further research.
3.3.3. Possible validity threats
We have identified four main sources of possible data validity threats. First of all, it is a
researcher bias in identifying and selecting factors that are, in the researcher’s opinion are the most
important and relevant for the analysis. The only mitigation strategy here has been the careful
research on similar studies and taking the examples of most cited papers on the agile adoption.
The second threat to validity is concerned with the survey questionnaire formulation and
here is, again, the same technique of synthesizing the best practices of constricting questionnaires
was employed. Importantly, the questionnaire was bi-lingual, since the main agile methods and
practiced do not have a single translation to the Russian language and are more easily understood
by the practitioners.
Thirdly, the problem with validity might lay in the quality of sample itself and with the
possibility that sample does not represent the population of digital community practitioners to the
full extent. All we can state here is that the diverse respondent’s profile might speak to the fact
that the sample is enough to represent variety of opinions and experiences, and enough to conduct
the statistical model. With respect to that, the findings might be proving to be useful as a part of
the general picture of the agile project methods adoption in Russian digital industry and as well
57
can be of relevance in other comparative cross-culture studies.
Finally, the issue with survey design is always the possibility of inaccurate and sloppy
while filling the questionnaire. There is no way to check the accuracy of the data, but we believe
that the sample size was enough to mitigate that threat as well.
3.4.
Summary of Chapter 3
In this chapter we have answered the remaining research questions, by firstly having
identified the most adopted agile methods used in Russian digital community, and by gaining more
understanding about why project managers choose to adopt agile practices. We have synthesized
the research model based on found factors in the literature on agile adoption (team, internal and
external environment, and objectives).
Then we have described the statistical analysis technique and provided with the results on
main factors of agile adoption. The external environment tailoring criteria has a positive effect on
agile practices adoption, followed by the internal environment and team. The objectives criteria
did not prove to be statistically significant.
Finally, we have interpreted the study results and added insight on the reasons behind
factors related to clients and management support having the strongest impact on development
teams. The details of these findings can be investigated further, especially interesting topic is
cultural study on business culture influence, as well quantitative research on how to measure agile
adoption effectiveness.
58
CONCLUSION
All successful projects require project methodology, and artefacts, and rules that set the
game for the development team and for the all stakeholders as well. Digital business success is
critically related to the client satisfaction which in turn is connected with high-speed of highquality code.
Given the rapidly changing technology and high degree of uncertainly that is pre-set for
this industry, more flexible approaches are required to manage more effectively. After agile
development paradigm first appeared in the last decade it has been seen as a new way of project
management, a “silver bullet” for technology-intense projects and products, and has been
recognized by mane professionals as one of the most effective methods that exist today.
However, popularity comes at a price, and behind the agile movement boom there is strong
tendency among adopting teams to overuse the technique, combined with misunderstanding of
when it is appropriate to employ it, and when it’s not. The existing research on this matter has
been carried out, but without clear and comprehensive results. Partially due to the too abstract
scope of factors, but also due to the fact that studies in different countries give different results,
most probably because of contextual issues.
This study aimed to fill the gap by exploring the way agile methods are being implemented
in Russian digital companies, and by exploring the relation between the factors that influence the
agile adoption decision and the actual level of agile approach implementation.
This study investigated agile practice adoption by asking practitioners directly about which
practices they are using on project and organizational level and what factors influenced the
decision to adopt the agile practices in their organizations. We gathered the results that in our
opinion prove that cultural differences are indeed important even when we talk about highly
globalized and technologically advanced industries.
It is too premature to give more clear frameworks and guidance, but we have pointed out
the critical factors that should be taken into account first of all while considering the agile adoption,
and these are the practices among managers that is implicitly present, but have not been studied
before in the context of Russian digital market.
We believe that the study is going to have both theoretical and managerial contribution to
the area of agile project management methods, and that the results of it will be of use to both
researchers investigating agile methods adoption and tailoring, and to practitioners in the field,
who fight for their projects success everyday.
59
REFERENCES
Abbas, N., Gravell, A. M., & Wills, G. B. (2010). Using factor analysis to generate clusters of
agile practices (A guide for agile process improvement). Agile Conference, Orlando, USA.
Abrahamsson, P. et al. (2002). Agile software development methods: Review and analysis. VTT
Finland.
Acuna, S., Gomez, M., & Juristo, N. (2009). How do personality, team processes and task
characteristics relate to job satisfaction and software quality? Information and Software
Technology 51: 627–639.
Afthanorhan, W. (2014). Hierarchical Component Using Reflective-Formative Measurement
Model in Partial Least Square Structural Equation Modeling (PLS-SEM). International Journal
of Mathematics and Statistics Invention 2 (2): 55-71.
Ahmed, E., & Sidky, A. (2009). 25 percent ahead of schedule and just at. 2009 Agile Conference,
Chicago, IL, USA.
Ayed, H. Vanderose, B. & Habra, N. (2012). A metamodel-based approach for customizing and
assessing agile methods. 8th International Conference on the Quality of Information and
Communications Technology, QUATIC 2012, Lisbon, Portugal.
Ayed, H., Vanderose, B., & Habra, N. (2014). Supported approach for agile methods adaptation:
An adoption study. Proceedings of the 1st International Workshop on Rapid Continuous Software
Engineering. New York, NY, USA: 36–41.
Balijepally,V., Mahapatra, R., Nerur, S., & Price, K.H. (2009). Are two heads better than one for
software development? The productivity paradox of pair programming. MIS Quarterly 33: 91–
118.
Baskerville, R., Balasubramaniam, R., Levine, & L., Pries-Heje, J. (2006). High-speed software
development practices: What works, what doesn’t. IT Professional 8 (4): 29–36.
Bass, J. (2013). Agile method tailoring in distributed enterprises: Product owner teams. Global
Software Engineering (ICGSE), IEEE 8th International Conference: 154–163.
Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley
Professional, 1st ed.
Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J.,
Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R., Mellor, S., Schwaber, K.,
Sutherland, J., & Thomas, D. (2001). Manifesto for agile software development.
60
Bell, J. (2010). Doing your research project. McGraw-Hill International.
Benington, H. D. (1983). Production of Large Computer Programs. IEEE Annals of the History of
Computing 5 (4): 350–361.
Boehm, B., & Turner, R. (2005) Management challenges to implementing agile processes in
traditional development organizations. IEEE Software 22 (5): 30 – 39.
Bonner, N. A., Teng, T. C., & Nerur, S. (2010). The perceived advantage of agile development
methodologies by software professionals: Testing an innovation-theoretic model. AMCIS: 93-111
Proceedings. Paper 93. http://aisel.aisnet.org/amcis2010/93.
Chan, F., & Thong, J. (2009). Acceptance of agile methodologies: a critical review and conceptual
framework. Decision Support Systems 46: 803–814.
Coad, A., & Rao, R. (2006). Innovation and market value: A quantile regression analysis.
Economics Bulletin 15 (13).
Cockburn, A. (2004). Crystal Clear: A Human-Powered Methodology for Small Teams. AddisonWesley Professional.
Cockburn, A., & Highsmith, J. (2001). Agile software development: The people factor. Computer
34: 131–133.
Conboy, K. (2009). Agility from first principles: Reconstructing the concept of agility in
information systems development. Information Systems Research 20 (3): 329–354.
Conboy, K., & Fitzgerald, B. (2004). Toward a conceptual framework of agile methods: a study
of agility in different disciplines. WISER 04: 37–44.
Conboy, K., Coyle S., Wang X., & Pikkarainen M. (2011). People over process: Key challenges
in agile development. IEEE Software 28 (4): 48–57.
Deemer,
P.
et
al.
(2010).
The
scrum
primer.
<http://assets.scrumtraininginstitute.
com/downloads/1/scrumprimer121.pdf>
DeMarco, T., (1982). Controlling Software Projects. Prentice-Hall, Englewood Cliffs, N.J.
Denscombe, M. (2010). The Good Research Guide: For Small-Scale Social Research Projects:
for small-scale social research projects. McGraw-Hill International.
Dingsøyr, T., Dybå, T., & Moe, B. (2010). Agile Software Development: Current Research and
Future Directions. Springer Publishing Company, 1st edition.
61
Dingsøyr, T., Nerur, S., Balijepally, V., & Moe, B. (2012). A decade of agile methodologies:
Towards explaining agile software development. Journal of Systems and Software 85 (6): 1213–
1221.
Echalar, M. S. V. (2013). The innocent scrum team member <http://www.techzone.org/memorias/2013/MVillalta_Scrum_2013_paper.pdf>.
Edmondson, A.C., & McManus, S.E. (2007). Methodological fit in management field research,
Academy of Management Review 32 (4): 1155–1179.
El-Said, S., Hana, M., & Eldin, A. (2009). Agile tailoring tool (ATT): A project specific agile
method. Advance Computing Conference. IACC 2009. IEEE International: 1659–1663.
Esfahani, H. C., Yu, E. S. K., & Annosi, M. C. (2010). Capitalizing on empirical evidence during
agile adoption. Agile Conference, AGILE, Orlando, Florida, USA: 21–24.
Esfahani, H. C., Yu, E. S. K., & Annosi, M. C. (2010). Towards the strategic analysis of agile
practices. Proceedings of the CAiSE Forum 2011, London, UK: 155–162.
Gandomani, T. J. et al. (2013). How pre-start up assessment helps software companies in agile
transition. Science International. Special Issue Agile Symposium Malaysia, 2013.
Glaiel, F., Moulton, A., & Madnick, S. E. (2013). Agile Project Dynamics: A System Dynamics
Investigation of Agile Software Development Models. Proceedings of the 31st International
Conference of the Systems Dynamics Society, Cambridge, MA.
Hair, J. F., Hult, G. T. M., Ringle, C. M., & Sarstedt, M. (2016). A Primer on Partial Least Squares
Structural Equation Modeling (PLS-SEM), 2nd edition. Thousand Oaks: Sage.
Hannay, J.E., Arisholm, E., Engvik, D., & Sjoberg, D. (2010). Effects of personality on pair
programming. IEEE Transactions on Software Engineering 36: 61–80.
Highsmith, J. (2004). Agile Project Management - Creating Innovative Products. Pearson
Education, Boston.
Highsmith, J. (2007). Agile transitions, part 1.
http://www.cutter.com/project/fulltext/advisor/2007/apm071108.html
Holz, H. & Mauler, F. (2002). Knowledge management support for distributed agile software
processes. Advances in Learning Software Organizations: 60–80.
Iacobucci, D. (2010). Structural equations modeling: Fit indices, sample size, and advanced topics.
Journal of Consumer Psychology 20 (1): 90 – 98.
Ikonen, M. et al. (2010). Exploring the sources of waste in kanban software development projects.
62
Software Engineering and Advanced Applications (SEAA), 36th EUROMICRO: 376–381.
Jyothi, V. E., & Rao, K. N. (2011). Effective implementation of agile practices ingenious and
organized theoretical framework. IJACSA - International Journal of Advanced Computer Science
and Applications 2 (3): 41–48.
Kalus, G., & Kuhrmann, M. (2013). Criteria for software process tailoring: a systematic review.
International Conference on Software and System Process, ICSSP ’13, San Francisco, CA, USA:
171–180.
Kettunen, P. (2009). Agile software development in large-scale new product development
organization: team-level perspective. Helsinki University of Technology.
Kurapati, N., Manyam, V. S. C., & Petersen, K. (2012). Agile software development practice
adoption survey. Agile Processes in Software Engineering and Extreme Programming - 13th
International Conference, XP 2012, Malmö, Sweden. Proceedings:16–30.
Larman, C., & Basili, V. R. (2003). Iterative and incremental development: A brief history. IEEE
Computer Society 36: 47–56.
Layman, L., Williams, K., Slaten, S., Berenson, M., & Vouk, M. (2008). Addressing diverse needs
through a balance of agile and plan-driven software development methodologies in the core
software engineering course. International Journal of Engineering Education 24: 659–670.
Lee, G., & Xia, W. (2010). Toward agile: an integrated analysis of quantitative and qualitative
field data on software development agility. MIS Quarterly 34: 87–114.
Lyytinen, K., & Rose, G. (2006). Information system development agility as organizational
learning. EJIS 15 (2): 183–199.
Macriver,
R.
(2010).
Agile
Maturity
Self-Assessment.
<http://www.robbiemaciver.
com/documents/presentations/A2010-AgileMaturitySelf-Assessment.pdf>.
Madi, T., Dahalin, Z., & Baharom, F. (2011). Content analysis on agile values: A perception from
software practitioners. IEEE. Software Engineering (MySEC), 5th Malaysian Conference: 423–
428.
Manyam, V. S. C. & Kurapati, N. (2012). Empirical investigation on adoption and adaptation of
agile practices. Dissertation. Blekinge Institute of Technology.
Moe, B. (2011). From Improving Processes to Improving Practice. Software Process Improvement
in Transition from Plan-driven to Change-driven Development. Norwegian University of Science
and Technology.
63
Moniruzzaman, B. M., & Hossain D. S. (2013). Comparative Study on Agile software
development methodologies. Global Journal of Computer Science and Technology 13 (7).
Mukhtar, M. et al. (2013). A hybrid model for agile practices using case based reasoning. In:
Software Engineering and Service Science (ICSESS), 4th IEEE International Conference: 820–
823.
Nerur, S., & Balijepally, V. (2007). Theoretical reflections on agile development methodologies.
Communications of the ACM 50: 79–83.
Nerur, S., Cannon, A., Balijepally, V., & Bond, P. (2010). Towards an understanding of the
conceptual underpinnings of agile development methodologies. Agile Software Development: 15–
29.
Nerur, S., Mahapatra, R., & Mangalaraj, G. (2005). Challenges of migrating to agile
methodologies. Communications of the ACM 48 (5): 72–78.
Nishijima, R. T. & Santos, J. G. D. (2013). The challenge of implementing scrum agile
methodology in a traditional development environment. International Journal of Computers &
Technology 5 (2): 98–108.
Palmer, S., & Felsing, J. (2002). Practical Guide to Feature-Driven Development. Prentice Hall.
Pedersen, M. (2013). A quantitative examination of critical success factors comparing agile and
waterfall project management methodologies. Dissertation. Capella University September.
Petersen, K. (2010). Is lean agile and agile lean? Modern Software Engineering Concepts and
Practices: Advanced Approaches. IGI Global 19.
PMI. (2013). A guide to the project management body of knowledge (PMBOK® Guide)—Fifth
Edition. Newtown Square, PA: Project Management Institute.
Poppendieck, M., & Cusumano, M. (2012). Lean software development: A tutorial. Software,
IEEE 29 (5): 26-32.
Poppendieck, M., & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit.
Boston, MA, USA: Addison-Wesley Longman Publishing.
Qumer, A., & Henderson-Sellers, B. (2008). An evaluation of the degree of agility in six agile
methods and its applicability for method engineering. Information and Software Technology 50
(4): 280–295.
Royce, W. (1970). Managing the Development of Large Software Systems. Proceedings of IEEE
WESCON 26 (August): 1–9.
64
Salazar-Torres, G., Colombo, E., Da Silva, F., Noriega, C., & Bandini, S. (2008). Design issues
for knowledge artifacts. Knowledge-Based Systems, 21(8), 856-867.
Salo, O. & Abrahamsson, P. (2008). Agile methods in European embedded software development
organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum. IET
Software, 2(1), 58.
Santos, M. A. et al. (2011). Agile practices: An assessment of perception of value of professionals
on the quality criteria in performance of projects. Journal of Software Engineering & Applications
4 (12).
Schwaber, C. (2007). The truth about agile processes. Forrester Research, Inc.
Schwaber, K. & Sutherland, J. (2011). The scrum guide. http://scrum.org/.
Schwaber, K., & Beedle, M. (2001). Agile Software Development with Scrum. Prentice Hall PTR,
NJ. 1st edition.
Sharp, H., & Robinson, H. (2010). Three Cs of agile practice: collaboration, coordination and
communication. Agile Software Development: 61–85.
Sharp, H., Badoo, N., Beecham, S., Hall, T., & Robinson, H. (2009). Models of motivation in
software engineering. Information & Software Technology 51 (1): 219–233.
Shaw, M. (2003). Writing good software engineering research papers: minitutorial. IEEE
Computer Society. Proceedings of the 25th international conference on software engineering 1:
726–736.
Sjøberg, D. et al. (2008). Building theories in software engineering. In: Shull, F.; Singer, J.;
Sjøberg, D. Guide to Advanced Empirical Software Engineering. Springer London: 312–336.
Solinski, A., & Petersen, K. (2014). Prioritizing agile benefits and limitations in relation to
practice usage Springer Software Quality Journal 24 (2): 447-482.
Sommerville, I. & Ransom, J. B. (2005). An Industrial Experiment in Requirements Engineering
Process Assessment and Improvement. ACM Transactions on Software Engineering and
Methodology (TOSEM) 14 (1): 1-33.
Stacey, R. D. (2011). Strategic Management and Organizational Dynamics: the challenge of
complexity to ways of thinking about organizations. Pearson Education (6th edition), London.
Stapleton, J. (1997). DSDM, Dynamic Systems Development Method: The Method in Practice.
Addison-Wesley.
65
Stevens, R., Millage, J., & Clark, S. (2010). Waves of Knowledge Management: The Flow
between Explicit and Tacit Knowledge. American Journal of Economics and Business
Administration 2: 129-135.
Tonella, P. et al. (2007). Empirical studies in reverse engineering: state of the art and future trends.
Empirical Software Engineering, Springer 12 (5): 551–571.
West, D., & Grant, T. (2010). Agile development: Mainstream adoption has changed agility trends in real-world adoption of agile methods. Forrester Research 1: 15-23.
Whitaker, S. (2014). The Benefits of Tailoring: Making a Project Management Methodology Fit.
Project Management Institute, Inc.
66
APPENDICES
APPENDIX 1. SURVEY QUESTIONNAIRE
The questionnaire was divided into 3 parts: (1) information on respondents’ demographics,
experience with agile, and organization size (2) information on agile practices implementation in
the companies (40 practices in total), (2) criteria for agile method tailoring that influences the
decision to adopt agile practices
PART 1. RESPONDENT'S AND COMPANY'S PROFILE
(1) What is your current position in the organization? <single choice>
Development
Project manager / Scrum master
Consultant
Tester
Another
(2) How long have you been working with agile methods / practices? <single
choice>
less than a year
between 1 and 2 years
between 3 and 4 years
more than 5 years
(3) How would you evaluate your own experience with agile methods /
practices? <single choice>
Almost no experience
Beginner-to-medium knowledge
Moderately experienced
Expert
(4) What is the size of your company / agency? <single choice>
< 20
20-50
51-100
101-200
>200
(5) Which agile methods are used in your organization? <multiple choice>
Adaptive Software Development (ASD)
Crystal
Dynamic Systems Development Method (DSDM)
Feature-Driven Development (FDD)
Hybrid (agile & waterfall)
Kanban
Lean
SCRUM
XP
Respondent's answer
67
PART 2. AGILE PRACTICES ADOPTION
(1) Please provide the adoption stage of the following agile practices in your company /
agency
Not
Planning
adopted adoption
Adoption in
progress
Partially
adopted
Completely
adopted
40-hours per Week
Acceptance Testing
Analog Task Board / Analog Story Board
Behavior-Driven Development
Brainstorming
Coding Standard
Collaborative Teams
Collective Ownership
Continuous Integration
Customer Focused Group Review
Daily Meeting / Daily Scrum / Daily
Stand Up
Dedicated Product Owner
Developing by Feature / Developing by
Component
Digital Task Board / Digital Story Board
Domain Object Modeling
Empowered Team
Features Team
Inspection
Interview - Structured
Interview - Unstructured
Iteration Planning / Planning Game /
Sprint Planning
Iteration Review / Sprint Review
Kanban Board
Metaphor
On-Site Customer
Open Office Space
Pair Programming
Product Backlog / Features List / Sprint
Backlog / Release Backlog
Prototyping
Refactoring
Reporting / Visibility of Results
Retrospective
Reversible Changes
Short Release
68
Simple Design
Test-Driven Development
Time-Boxed Planning
Unit Testing
Velocity
Waste Elimination
(2) Are you, in general, satisfied with adoption of agile methodology in your
organization? <open question>
PART 3. ADOPTION CRITERIA
(1) How important were the following criteria on the decision to adopt agile practices in
the organization?
Unimportant
Of little
importance
Moderately
important
Important Critical
Business goals
Communication
Complexity
Culture
Degree of Innovation
Domain Knowledge
Management support
Maturity Level
Organizational Size
Previous Projects
Project Budget
Project type
Requirements Stability
Team distribution
Team size
Technology knowledge
Type of Contract
User Availability
(2) What, in your opinion, are the factors that make adoption of agile methodology
unnecessary / impossible? <open question>
(3) When, in your opinion, it is more effective and more desirable to use agile
methodology? <open question>
69
APPENDIX 2. LIST OF ABBREVIATIONS
ASD
Adaptive Software Development
AVE
Average Variance Extracted
CB-SEM
Covariance-Based Structural Equation Model
CS
Computer Science
DEV
Development
DSDM
Dynamic Systems Development Method
FDD
Feature-Driven Development
IT
Information Technology
ITC
Information Technology and Communication
KPI
Key Performance Indicators
RAD
Rapid Application Development
RUP
Rational Unified Process
SAAP
Strategic Analysis for Agile Practices
SAMI
Sidky Agile Measurement Index
SEM
Structural Equation Modeling
PLS
Partial Least Squares
UML
Unified Modeling Language
XP
Extreme Programming
VIF
Variance Inflation Factor
70
Отзывы:
Авторизуйтесь, чтобы оставить отзыв