An Intentional Perspective on Partial Agile Adoption

Soreangsey Kiv

, Samedi Heng

, Manuel Kolp

and Yves Wautelet

LouRIM-CEMIS, Universit

e Catholique de Louvain, Belgium

Faculty of Economics and Business, KULeuven, Belgium

Keywords:

Agile Methods, Partial Adoption, Goal Modeling, Conceptual Model, Requirements Engineering.

Abstract:

Nowadays, the agile paradigm is one of the most important approaches used for software development besides

structured and traditional life cycles. To facilitate its adoption and minimize the risks, different meta-models

have been proposed trying to unify it. Yet, very few of them have focused on one fundamental question: How

to partially adopt agile methods? Intuitively, choosing which practices to adopt from agile methods should

be made based on their most prioritized goals in the software development process. To answer this issue,

this paper proposes a model for partial agile methods adoption based on intentional (i.e., goal) perspectives.

Hence, adoption can be considered as deﬁning the goals in the model, corresponding to the intentions of the

software development team. Next, by mapping with our goal-based model, suitable practices for adoption

could be easily found. Moreover, the relationship between roles and their dependencies to achieve a speciﬁc

goal can also be visualized. This will help the software development team to easily identify the vulnerabilities

associated with each goal and, in turn, help to minimize risks.

1 INTRODUCTION

In user-intensive software development, to effectively

deal with quality expectations, change or risk man-

agement, and to ensure that all the requirements

are satisﬁed, activities such as requirements gather-

ing, design, development and testing should be it-

erative and incremental. In the last decade, among

other approaches such as the introduction of eXtreme

Proramming (XP) (Beck, 2000), Feature-Driven De-

velopment (FDD) (Palmer and Felsing, 2001), Dy-

namic Systems Development Method (DSDM) (Sta-

pleton, 1997), Crystal family (Cockburn, 1998),

Scrum (Schwaber and Beedle, 2002), etc., this led

to the deﬁnition of the Agile Manifesto (Fowler and

Highsmith, 2001; Abrahamsson et al., 2003) to offer

alternatives to traditional approaches.

Among many research subjects in the agile com-

munity, partial agile adoption has gained a lot of in-

terests. It has always been actively studied and known

as agile tailoring, customization or practice selection,

etc. (Campanelli and Parreiras, 2015). Based on the

survey on partial agile adoption in the same publica-

tion indicated that 56 out of 783 papers published be-

tween 2002 and 2014 actually describe agile method

tailoring approaches. The common objective is to of-

fer the possibility to adopt agile methods gradually or

partly, rather than fully. According to the Campan-

elli and Parreiras, by adopting agile partially, orga-

nizations can avoid the need of spending efforts and

resources on irrelevant practices.

Intuitively, when software teams want to partially

adopt agile methods – either one or the combination

of multiple methodologies – they should have in mind

the reasons they want to do it and which are the goals

they want to achieve after the adoption. (Tripp and

Armstrong, 2014) conduct an exploratory study to

ﬁnd out that different motives exist for agile adoption,

all with different project management conﬁgurations

focusing on agile practices for software development.

(Campanelli and Parreiras, 2015) highlight that 42%

of the papers working on agile tailoring use goal as

one of their criterion for practice selection. For in-

stance, among others, the Strategic Analysis for Agile

Practices framework (Esfahani et al., 2011) proposes

to link the selection of agile practices to the organiza-

tion’s business goals.

Unfortunately, these business goals along with

other criteria are often described textually for partial

agile adoption. To ensure wide diffusion in academia,

we believe that explicit formalisms should have been

proposed by using meta-models (Henderson-Sellers

and Gonzalez-Perez, 2005; Mikul

enas et al., 2011;

Esfahani et al., 2010) to describe the methods. This

has motivated us to propose a partial agile adop-

tion from a goal perspective by means of a concep-

116

Kiv, S., Heng, S., Kolp, M. and Wautelet, Y.

An Intentional Perspective on Partial Agile Adoption.

DOI: 10.5220/0006429301160127

In Proceedings of the 12th International Conference on Software Technologies (ICSOFT 2017), pages 116-127

ISBN: 978-989-758-262-2

tual model to offer a more explicit representation and

guideline. Our motivation contrasts with previous

goal-based agile tailoring approaches in the sense that

we employ the original goal behind agile methods cre-

ation (i.e., the Agile Manifesto) rather than business

goal. This perspective coincides also with the work of

(Madi et al., 2011) which emphasizes that agile prac-

tices should follow the agile values which is funda-

mental to deﬁne the culture of the software company.

To summarize, we aim here at building a generic

goal-based conceptual model to facilitate partial agile

method adoption. Each agile concept will be seen as a

goal to achieve, to which dependencies between roles

and resources are associated. A complementary ob-

jective is to explain how a software team can use our

model at the two levels of adoption process: tactical

and operational.

• At the tactical level, the software team has to

choose the practices to integrate into its existing

development process.

• At the operational level, agile practices will be im-

plemented.

This paper is organized as follows. Section 2 dis-

cusses various agile methods and meta-models pro-

posed in literature. Their pros and cons are high-

lighted. Section 3 presents our framework for adopt-

ing agile methods partially. We ﬁrst expose our ag-

ile conceptual model adopting tactical and operational

levels. Then, we discuss on the use of the intentional

i* framework to instantiate our conceptual model.

Last, we provide a methodology for using our frame-

work in selecting agile practices. Section 4 provides a

validation for our approach. Finally, we conclude the

paper in Section 5 including a discussion on future

directions.

2 RELATED WORK

Over the last decade, many agile methods have been

proposed based on the Agile Manifesto to meet spe-

ciﬁc requirements and situations. For instance, Scrum

is proposed with an objective to put more focus on

project management organization while XP is de-

signed to be more responsive to customer requirement

changes (Mikul

enas et al., 2011). The research from

(Jacobson et al., 2006) shows that agile methods tend

to be compatible with small development teams and

focus more on people rather than processes or arti-

facts. Other well-known predecessors of agile frame-

works can be found in the literature, even inspired

from other disciplines than software and information

systems engineering: Agile Uniﬁed Process (AUP)

(Ambler, 2005), OpenUP (Kroll and MacIsaac, 2006)

and Agile Modeling (Ambler, 2002), Kanban (Ah-

mad et al., 2013; Liker, 2004), Lean Software Devel-

opment (Poppendieck and Poppendieck, 2003), Lean

Ofﬁce and Organization (Chiarini, 2013), etc.

These agile methods are generally described tex-

tually as a series of values, principles and practices

(Beck, 2000; Schwaber and Beedle, 2002; Fowler

and Highsmith, 2001). To formalize their description,

help their adoption, minimize the risks of deploying

them and generalize them, meta-models (Henderson-

Sellers and Gonzalez-Perez, 2005; Mikul

enas et al.,

2011; Esfahani et al., 2010) have been created. Meta-

models can then help the adoption of such meth-

ods better, faster and at the same time minimizing

the risks. They aim at making relations, attributes,

control ﬂows, rules of a particular process more ap-

pealing based on a particular perspective, e.g., prod-

ucts and capability assessment (Henderson-Sellers

and Gonzalez-Perez, 2005), partial agile adoption

(Mikul

enas et al., 2011), and goal-oriented (Esfahani

et al., 2010).

(Schwaber, 2004) has designed a meta-model to

support the construction of agile methods. By rely-

ing on the measurement concept from the Situational

Method Engineering framework (Henderson-Sellers

et al., 2014), it provides guidance to agile method-

ologists during the construction and throughout the

development process itself. Rather than working on a

single agile method, (Mikul

enas et al., 2011), on their

side, focus on a meta-model enabling a fusion of dif-

ferent agile methods – named as partial agile methods

adoption. The core idea is to decompose each agile

method into components which, in theory, could al-

ways be categorized into a common pre-deﬁned struc-

ture. This offers great ﬂexibility in adopting agile

methods since one can manually select and combine

different alternative components coming from differ-

ent methods at will.

Interestingly, (Lin et al., 2014) and (Esfahani

et al., 2010) have shed more light on goal-oriented

meta-models. (Lin et al., 2014) propose a novel goal-

oriented method on the top of the AUP (Ambler,

2005), called GOAUP that could be also applied to

OpenUP and other adaptation of the Uniﬁed Process

to agile. Goal-Net theory (Shen et al., 2004) is used

to model the hierarchical goals in the AUP using a

Goal-Net diagram. Each iteration can be considered

to have one main goal. (Esfahani et al., 2010) propose

a more sophisticated goal-oriented meta-model that

put focus on social interaction, in which human re-

lations are clearly deﬁned. For example, the relation-

ship/dependency between roles in required processes

and the skills are associated with each goal in turn

An Intentional Perspective on Partial Agile Adoption

117

described with certain vulnerabilities to minimize the

risks of the adoption process. Although many other

meta-models have been proposed (Lin et al., 2014;

Shen et al., 2004; Mikul

enas et al., 2011; Esfahani

et al., 2010; B

ezivin, 2004; Schuppenies and Stein-

hauer, 2002; Damiani et al., 2007; Henderson-Sellers

and Gonzalez-Perez, 2005), none of them focuses

speciﬁcally on partial agile adoption in an intentional

goal-oriented perspective. The closest research re-

lated to our work is (Esfahani et al., 2010), in which

goal-oriented has been used to model micro-processes

(i.e., practices). However, the authors focus rather on

how to visualize agile methods, mainly Scrum, in so-

cial modeling while our work aims at using a goal-

oriented framework speciﬁcally dedicated to partial

agile methods adoption.

3 PROPOSED FRAMEWORK

Our objective is to introduce a generic conceptual

model based on goal and social aspects to describe

agile software development. To do this, we formulate

our proposed framework in two main parts.

First, we create a generic conceptual model, appli-

cable to any agile method. We will need to deﬁne a

common structure that can, theoretically, represent all

the agile elements from a goal perspective. Each ag-

ile concept will be seen as a goal to achieve, to which

dependencies between roles and resources are associ-

ated.

Second, we propose making use of the inten-

tional i* framework (Yu et al., 2011) (that means dis-

tributed intentionality) as schema instances derived

from the conceptual model to visualize all the depen-

dencies/relationships. The choice is inspired by the

fact that i* framework has stimulated a considerable

interest in a socially-motivated approach to systems

modeling and design, and has led to a number of ex-

tensions and adaptations (Eric, 2009). We will ex-

plain how this goal-based conceptual model and its

i* representation can offer advantages at both tacti-

cal and operational levels for a partial agile methods

adoption process.

We describe, hereafter, more formally our concep-

tual model and the mapping of each component into

i* elements. We then apply it on two agile methods,

Scrum and XP to verify that all the agile concepts can

be mapped to our conceptual model and to show that

it is helpful for practitioner in selecting practices and

identifying vulnerability.

3.1 Agile Conceptual Model

Our conceptual model is created to help the software

team to select a set of practices for adoption based

on goals. The Agile Manifesto introduces four val-

ues, twelves principles and the abstraction of prac-

tice (Fowler and Highsmith, 2001) to agile methods

should respect. Agile values are the large-scale crite-

ria we use to judge what we see, what we think and

what we do (Madeyski, 2010). They are fundamental

where a set of practices can be followed on their basis

(Madi et al., 2011). According to agile practitioners,

knowing the most important agile values is the key to

follow the best set of practices. Practices are concrete

activities and practical techniques used to develop and

manage software projects in accordance with the ag-

ile principles (Sidky et al., 2007). There is a big gap

between values and practices, since values are too ab-

stract to directly guide the development. Therefore,

principles come into agile and act as a bridge to nar-

row this (Madeyski, 2010). We introduce the concept

of agile feature based on (Laanti et al., 2013) as the

composition of principles. As the concept of princi-

ple, it is introduced to further narrow the gap between

principle and practice. Finally, a practice is performed

by a certain role (actor) with/without using/producing

the artifact. Our conceptual model is built on top

of these abstractions: value, principle, agile feature,

practice, role and artifact. Figure 1 is the conceptual

model of agile methods in the goal perspective.

The deﬁnition of the main components in our con-

ceptual model are:

• Value is the large-scale criteria used to judge what

we see, what we think and what we do (Madeyski,

2010). It is seen as the top-level goal in agile

methods adoption.

• Principle helps to establish a mind-set for solid

software engineering practices (Pressman, 2005).

It comes into agile methods and acts as a bridge

to narrow the gap between values and practices

(Madeyski, 2010).

• Agile feature is the distinctive characteristic of

each principle, as deﬁned by (Laanti et al., 2013).

These features can help to narrow the gap between

principles and practices, and consequently the rel-

evant practices can be better identiﬁed by the de-

velopment team.

• Practice is the concrete activity and practical tech-

nique that is used to develop and manage software

projects in a manner consistent with the agile prin-

ciples (Sidky et al., 2007).

• Role in agile methods refers to the allocation of

speciﬁc roles through which the software produc-

ICSOFT 2017 - 12th International Conference on Software Technologies

118

Principle

Agile_Feature

Practice

Artifact

Value

Role

1..*

0..*

1..*

produces/requires

is responsible for

achieved by

emphasizes on

contributes to

Figure 1: Agile conceptual model.

tion in a development team is carried out (Sidky

et al., 2007).

• Artifact is the resource produced during software

development. It can be tangible like user stories

(Cohn, 2004; Wautelet et al., 2014) or intangible

like working software functionality.

All the relationships between different compo-

nents are of the type “many-to-many”.

3.2 Mapping the Agile Conceptual

Model to i*

Goal/Intention and social dependencies between each

component over a speciﬁc goal can be visualized us-

ing goal-oriented frameworks. In this research, we

use the i* framework (Yu et al., 2011). It has two

main models: the Strategic Dependency model (SD)

and Strategic Rationale model (SR). The SD model

describes external dependency relationships between

goals, actors using hard-goal, soft-goal, task and re-

source elements. These four kinds of dependency

are suitable to represent respectively the functional

goal, functional goal without a clear-cut of satisﬁa-

bility, functional goal with a speciﬁc activity or prac-

tice to achieve and resource or artifact needed dur-

ing the development. In addition to the SD, the SR

model provides a deeper representation to the in-

ternal, intentional dependency with the means-end,

task-decomposition and contribution links to describe

stakeholders’ interests and the (combination of) activ-

ities, sub-goals, artifacts that help to achieve the main

goal. A full description of i* can be found in (Yu

et al., 2011) but we summarize the important concepts

below for self-sufﬁciency:

• Hard-goal is an intentional desire of an actor, the

speciﬁc way of how the goal is to be satisﬁed is

not described.

• Soft-goal is similar to (hard) goals except that the

criteria for the goals satisfaction are not clear-cut,

it is judged to be sufﬁciently satisﬁed from the

point of view of the actor.

• Task is a particular way of attaining a goal.

• Resource is the ﬁnished product of some

deliberation-action process.

• Role is an abstract characterization of the behavior

of a social actor within some specialized context

or domain of endeavor. Its characteristics are eas-

ily transferable to other social actors.

• Contribution link (some+) is a positive contribu-

tion whose strength is unknown.

An Intentional Perspective on Partial Agile Adoption

119

Table 1: Mapping agile concepts to i*.

Agile concepts i* concepts

Principle Soft-goal

Agile Feature Soft-goal

Practice Task

Artifact Resource

Role Role

Contributes to Contribution link (some+)

Emphasizes on Contribution link (and or make)

Achieved by Contribution link

Is responsible for Task dependency

Produces/requires Resource dependency

• Contribution link (and) is kind of contribution

where the parent is satisﬁed if all of the offsprings

are satisﬁed.

• Contribution link (make) is a positive contribution

strong enough to satisfy a soft-goal.

• Task dependency is a relationship where the de-

pender depends on the dependee to carry out an

activity (task).

• Resource dependency is a relationship where the

depender depends on the dependee for the avail-

ability of an entity (physical or informational).

In order to visualize our model using the i* frame-

work, all the concepts and their relationships must be

mapped to i* elements. This mapping is performed

with an heuristic search using the idea of Cartesian

product. Indeed, for every concept in our model, we

compare its deﬁnition/objective to all the possible i*

elements that can be found. The best match should

have the most similar objective/deﬁnition. We ﬁrst

map the classes and we ﬁnish by mapping their rela-

tionships. We managed to map all the concepts and

their relationships to i* elements and detail hereafter

the motivation of our mapping for each concept:

• Value, principle and agile feature are represented

as soft-goals. These concepts are described in ag-

ile methods as the objectives to be achieved with-

out any deﬁned criterion. For instance, “Individu-

als and interactions over processes and tools” ex-

plains why software team members and their in-

teractions are important for the development but

there is no explicit explanation of how the team

should be, what kind of interactions they need in

order to attain the beneﬁt of this value. Similar ex-

planations apply for the concepts of principle and

agile feature.

• Practice is described as a set of activities that the

software team must follow in order to realize its

beneﬁt. It is represented as a task in i*.

• Artifact is the resource required or created when

performing a practice. For example “user stories”

are the resources needed for a “sprint planning”

and from this practice, a “sprint backlog” is cre-

ated. In i*, artifact is represented as resource.

• Role exists in many forms in different agile meth-

ods. Each role has different responsibility and can

be played by different or the same actor. It is rep-

resented as a role in the i* framework.

• Contributes to is the relationship between value

and principle which are soft-goals. It is repre-

sented as a contribution link with the “some+” tag,

as the strength of its contribution to satisfy is un-

known.

• Emphasizes on is the relationship between princi-

ple and agile feature. Each principle is decom-

posed into different parts used to emphasize it.

This kind of relationship is represented by a con-

tribution link with the tag “and” while principle

is the parent and can be fully satisﬁed only if all

of the children, agile features, are satisﬁed. Some

principles having only one feature, the “contribu-

tion link” with the tag “make” is used to represent

them. That one feature is the only thing to be sat-

isﬁed to fulﬁll the principle it emphasizes.

• Achieved by is the relationship between agile fea-

ture (soft-goal) and practice (task). This relation-

ship is a “contribution link” where the tag used

depends on the practice to carry out and the fea-

ture to achieve.

• Is responsible for is the relationship between an

agile role and the practice under its responsibility.

It is represented by task dependency.

• Produces/requires is the relationship between an

ICSOFT 2017 - 12th International Conference on Software Technologies

120

agile role and the artifact it requires or creates.

It is represented by an i* resource dependency,

which roles depend on each other for the resource

needed.

3.3 Agile Practices Selection Process

The partially adopt agile methods in our framework

consists of four steps and follows an iterative and in-

cremental process as represented by Figure 2.

• Deﬁning Goals: within this stage, agile practition-

ers need to deﬁne the goals/objectives they want

to achieve after the agile methods adoption, either

single or multiple methods.

• Selecting Practices: based on the goals deﬁned

previously, the software team follows our goal-

based conceptual model to ﬁnd out the supporting

practices. At this point, the team should be able to

select which practices to adopt.

• Checking Vulnerabilities: in order to help

the team to identify the possible risks dur-

ing practices implementation, various relation-

ships/dependencies between agile practices, roles,

and resources needed will be visualized to the

organization. This enables the software team to

see the possible vulnerabilities, e.g., roles or re-

sources required can not be provided.

• Solving Vulnerabilities or Implementing Prac-

tices: ﬁnally, based on the results of dependency

check, if there is any identiﬁed risks associated

with practice, the software team needs to make

the decision on how to avoid them: either by solv-

ing the cause of vulnerability or by redeﬁning the

goal (eventually, the process of selecting practices

is started again). If there is not any risk, the team

can start implementing the practices into their de-

velopment process.

4 VALIDATION

In order to fully validate the framework, there are two

necessary validations should be carried out, we would

call theoretical and practical validation. Theoretical

validation aims at verifying that all the agile concepts

can always be mapped to our conceptual model and

showing that it can help practitioner in selecting prac-

tices and identifying vulnerability. The practical val-

idation aims at validating whether or not the frame-

work is useful for the development team in the real

case of partial agile methods adoption. However, as

the preliminary study, we only focus on theoretical

validation in this paper. As we can not take practices

from all the agile methods to discuss in one paper, we

choose to work only with the two most popular agile

methods namely Scrum and XP.

The validation will be done in two steps. At the

ﬁrst step, the “tactical level”, the relationships be-

tween value, principle, agile feature and practice will

be visualized. Practitioners can follow our methodol-

ogy to ﬁnd out what are the practices that fulﬁll their

desired goals. Then, during selected practices im-

plementation, named “operational level”, the depen-

dencies between practices, roles and resources needed

will be visualized. This level is supposed to help prac-

titioners to identify the vulnerability.

We describe below these two levels applied to

Scrum and XP.

4.1 Application at Tactical Level

Our goal-based conceptual model can ﬁrst be used at

“the tactical level” for attempting to partially adopt

agile methods.

One of the most common questions in partial agile

adoption is: which practices should we adopt ﬁrst?

To answer this, the software team can visualize the

adoption process as having a set of goals to achieve

and follow the conceptual model until reaching the

lowest level in order to ﬁnd out the practices they need

to achieve the goals.

Over the years, many values, principles and prac-

tices have been proposed in different agile methods.

However, to avoid an overwhelming amount of in-

formation, this research will discuss only on the root

four values, twelve principles and some practices pro-

posed in the two most popular agile methods: Scrum

and XP. It is important to remind that the main idea of

this paper is not to map all the existing elements, but

rather to show the interests of having them mapped in

a goal perspective.

We can discover which principles contribute to

which value, which practices can help to achieve

which principle, etc. by either a literature review or

a qualitative research approach. In our case, the ﬁrst

method has been carried out while the second one will

be done later.

Although there is no explicit claim of relationship

between them, they can be understood from the tex-

tual meaning. For example, “Individuals and interac-

tions over processes and tools” can easily be under-

stood as the ability of the software team and the inter-

actions that contribute to this value. Logically, all the

principles that contribute to this value are those focus-

ing on the improvement of the software team and their

interactions. Similarly, we can group the twelve prin-

ciples into the four values deﬁned in the Agile Mani-

An Intentional Perspective on Partial Agile Adoption

121

Defining

goals

Selecting practices

Checking

vulnerabilities

Solving vulnerabilities

Implementing

practices

Have new goals to

be achieved?

Any risk?

Adopting

Agile Methods

yes

Figure 2: Agile practices selection process.

festo based on what they contribute to. Interestingly,

(Laanti et al., 2013) analyze each principle in their

research and introduces emphasis that we call “agile

features”.

Based on the knowledge extracted from (Martin,

2003; Laanti et al., 2013), we summarize the mapping

between value, principle and agile feature in Table 2.

As mentioned earlier, it is not possible in this re-

search to extract all the practices from all methods

adopted by the industry. The two most popular meth-

ods have then been studied. Besides, being the most

favored, Scrum and XP are known to be compati-

ble and have frequently been adopted together (Ver-

sionOne, 2016).

• Scrum, the most used among agile methods (Ver-

sionOne, 2016) is a framework within which peo-

ple can address ﬂexible adaptive problems, while

productively and creatively delivering products of

the highest possible value (Schwaber and Suther-

land, 2011). It is not a process or a technique

for building products; rather, it is a method within

which we can employ various processes and tech-

niques. It consists of Scrum Teams and their as-

sociated roles, events, artifacts, and rules. Each

component within the framework serves a spe-

ciﬁc purpose and is essential to the success and

usage of Scrum. The rules of Scrum bind together

the events, roles, and artifacts, governing the re-

lationships and interaction between them. Scrum

has never been described with clear-cut practices.

However, the list of practices can be found at (Ag-

ileAlliance, 2017).

• XP, as described in (Beck, 2000), is a process for

the business of software development that make

the whole software team focus on common, reach-

able goals. Using XP values and principles, soft-

ware teams apply appropriate practices in their

own context. XP practices are chosen for their

encouragement of human creativity and their ac-

ceptance of human frailty. One of the goals of XP

is to bring accountability and transparency to soft-

ware development, to run software development

like any other business activity. Another goal is to

achieve more effective and efﬁcient development

with far fewer defects than is currently expected.

Finally, XP aims to achieve these goals by cele-

brating and serving the human needs of everyone

touched by software developmentsponsors, man-

agers, testers, users, and programmers.

A list of XP and Scrum practices can be found on

(AgileAlliance, 2017). The mapping between agile

features and practices in this research has been cre-

ated based on the understanding of each practice and

its beneﬁt described in (Martin, 2003; Schwaber and

Beedle, 2002). The result is summarized in the online

Appendix goo.gl/xg6aK4.

Figure 3 depicts the relationship between the dif-

ferent agile concepts: value, principle, agile feature

and practice, represented in four different levels while

the upper levels are contributed by the lower ones.

Due to the limited space, only the practices that help

to achieve the two principles contributing to a value

are shown. In the Figure 3, the value “Individual and

interaction over processes and tools” is contributed

by two principles: “Build project around motivated

individual. Give them the environment and support

they need and trust them to get the job done” and

“The most efﬁcient and effective method of convey-

ing information to and within a development team is

face-to-face conversation”. Each principles is empha-

ICSOFT 2017 - 12th International Conference on Software Technologies

122

Table 2: Mapping between agile values, principles and features.

Value Principle Agile feature

V1:

Individuals and

interactions over processes

and tools

P1:

Build projects around motivated individuals.

Give them the environment and support they

need, and trust them to get the job done.

F1:

Motivated individuals

F2: Good environment

F3: Support

F4: Trust

P2:

The most efficient and effective method of

conveying information to and within a

development team is face-to-face conversation.

F5:

Efficiency (for conveying

information)

F6: Communication

P3:

Agile processes promote sustainable

development. The sponsors, developers, and users

should be able to maintain a constant pace

indefinitely.

F7:

Sustainability

F8: People

P4:

The best architectures, requirements, and

designs emerge from self-organizing teams

F9:

Self-organization

P5:

At regular intervals, the team reflects on how

to become more effective, then tunes and adjusts

its behavior accordingly.

F10:

Built-in improvement of

efficiency and behavior

V2:

Working software over

comprehensive

documentation

P6:

Our highest priority is to satisfy the customer

through early and continuous delivery of valuable

software.

F11:

Customer satisfaction

F12: Continuous delivery

F13: Value

F14: Early delivery

P7:

Deliver working software frequently, from a

couple of weeks to a couple of months, with a

preference to the shorter timescale.

F15:

Frequent deliveries

P8:

Working software is the primary measure of

progress.

F16:

Measure progress via

deliverables

P9:

Simplicity the art of maximizing the amount

of work not done is essential

F17:

Simplicity

F18: Optimize work

V3:

Customer collaboration

over contract negotiation

P10:

Business people and developers must work

together daily throughout the project

F19:

Collaboration

V4:

Responding to change

over following a plan

P11:

Welcome changing requirements, even late

in development.

F20:

Adaptability

F21: Competitiveness

F22: Customer benefit

P12:

Continuous attention to technical excellence

and good design enhances agility

F23:

Focus on technical excellence

sized by multiple agile features such as “Trust”, “Sup-

port”, “Good environment” and “Motivated individu-

als”. Each agile feature can be achieved by multiple

agile practices of the method Scrum and XP. For ex-

ample, we can achieve the feature “Trust” by using

the practices “Collective ownership” and “Sign up”.

An Intentional Perspective on Partial Agile Adoption

123

Task

Resource

Softgoal

Legend:

Contribution Link

Individuals and

interactions over

processes and tools

Build projects around motivated

individuals. Give them the

environment and support they need,

and trust them to get the job done

The most efficient and effective

method of conveying information

to and within a development

team is face-to-face conversation

Motivated

individuals

Trust

Good

environment

Planning

poker

Three

questions

Pair

programming

Daily

meeting

Collective

ownership

Backlog

grooming

Support

Efficiency

Communication

Backlog

User stories

Some +

Figure 3: Relationship between value, principles, features and practices.

4.2 Application at Operational Level

The previous section describes how our conceptual

model is created and can be used for partial agile

adoption at the tactical level. We present here the

operational level describing the importance of social

interaction, particularly dependencies between roles,

during agile practices implementation.

In the conceptual model, a role is in charge of car-

rying out a practice. By visualizing this concept in i*,

one can easily understand how each role is involved

in a particular process to achieve a goal. Dependen-

cies between roles, goal and resources needed are then

explicitly represented. The description of all the de-

pendencies, critical roles and artifacts can help the or-

ganization and the software team to better analyze the

chances of success or the probability of failure and

thus be prepared to mitigate the risks. For instance,

if many critical goals heavily depend on a particular

role, the probability of failure increases when that role

is not reliable. Thus, software teams must carefully

assign it or adopt better practices to reduce or avoid

such risks. Our conceptual model built so far con-

tains only abstract deﬁnitions of practices. We show

below that it can be instantiated on difference agile

methods, as here in example, on Scrum and XP. Prac-

tices in each method are collected and mapped into

agile features and the mapping list can be found in the

Table 2. Figure 4 shows the dependencies between

roles to perform the practices illustrated in Figure 3

at the operational level. Such representation is use-

ful to show how different roles depend on each other

to perform a certain tasks which can lead to achieve

a speciﬁc goal at the tactical level. For instance, the

Scrum master depends on the product owner to per-

form the following tasks: “backlog grooming”, “cre-

ating user stories”, “building the backlog” and “plan-

ning poker”. These practices are necessary in order

to achieve the “efﬁciency” agile feature. If the prod-

uct owner fails to perform them, this goal will most

probably also fail. To avoid that, it is necessary to

make sure that the scrum master manages to interact

with the product owner despite tight schedules or to

choose other practices which do not depend on the

product owner.

ICSOFT 2017 - 12th International Conference on Software Technologies

124

Task

Resource

Legend:

Planning

poker

Three

questions

Pair

programming

Daily

meeting

Collective

ownership

Backlog

grooming

Backlog

Product

owner

Scrum

master

Development

team

User stories

Dependency Link

Role

Figure 4: Scrum methodology at the operational level.

When practices in different methods are merged,

so will do the roles. The software team has to decide

which roles to keep and which can be eliminated. In

our example, there are only two practices from XP

in which the XP coach depends on the developer to

perform “pair programming” and “collective owner-

ship”. Since the XP coach is just a depender which

is not crucial, it can be replaced by the Scrum mas-

ter. As for the developer role, even if it is necessary

to perform the practices, it is already included in the

software team.

5 CONCLUSION

This paper introduced a new conceptual model to rep-

resent agile methods in a goal perspective and allows

partial method adoption. Our model offers two main

advantages. First, the goal perspective enables the

software team to quickly understand the objective of

each concept (i.e., value, principle,agile feature and

practice) and consequently enables the software team

to select only the relevant concepts for partial agile

adoption. Second, using the i* framework to visualize

the relationships between roles and their intentional

dependencies allows the team to identify the possi-

ble vulnerabilities resulting from adopting the chosen

practices. Hence, the software team can avoid risks of

project failure by reinforcing the role performance or

choosing the alternative practices which can achieve

the same goal.

While this conceptual model offers a lot of advan-

tages, we acknowledge that a formal methodology is

needed on top of it to practically validate it. Two pos-

sibilities can be chosen based on either a systematic

review and a survey. We chose to focus on the em-

pirical survey because we believe that it would offer

a more evidential information from a practical per-

spective. At the time of writing, the survey is being

conducted and we hope to publish the results in a next

iteration of this research work.

To make sure that the software team can success-

fully adopt agile methods, we would also like to add

another dimension for evaluating the speciﬁc process

of adoption. In this regards, we aim not only at of-

fering a roadmap for the software team to adopt agile

methods, but also a set of performance indicators dur-

ing the adoption process.

As our work aims at creating a generic conceptual

model for any agile methods, it would be interesting if

we can choose to adopt practices coming from differ-

ent methods. This will enable organizations to have

more variety of choices in term of practices. How-

ever, this should be done with caution. Ideally, to al-

low such possibility, one can introduce a weighting

scheme, between different alternatives, as a risk indi-

cator when adopting a particular practice. Finally, in

the long term, we aim at developing a tool for show-

casing our conceptual model.

REFERENCES

Abrahamsson, P., Warsta, J., Siponen, M. T., and

Ronkainen, J. (2003). New directions on agile meth-

ods: A comparative analysis. In Clarke, L. A., Dil-

lon, L., and Tichy, W. F., editors, Proceedings of the

25th International Conference on Software Engineer-

ing, May 3-10, 2003, Portland, Oregon, USA, pages

244–254. IEEE Computer Society.

An Intentional Perspective on Partial Agile Adoption

125

AgileAlliance (2017). Subway map to agile practices,

https://www.agilealliance.org/.

Ahmad, M. O., Markkula, J., and Oivo, M. (2013). Kan-

ban in software development: A systematic literature

review. In Software Engineering and Advanced Appli-

cations (SEAA), 2013 39th EUROMICRO Conference

on, pages 9–16. IEEE.

Ambler, S. (2002). Agile modeling: effective practices for

extreme programming and the uniﬁed process. John

Wiley & Sons.

Ambler, S. (2005). The Agile Uniﬁed Process

(AUP). Ambysoft, http://www. agilealliance.

hu/materials/books/SWA-AUP. pdf.

Beck, K. (2000). Extreme Programming Explained: Em-

brace Change. Addison-Wesley Longman Publishing

Co., Inc., Boston, MA, USA.

ezivin, J. (2004). In search of a basic principle for model

driven engineering. Novatica Journal, Special Issue,

5(2):21–24.

Campanelli, A. S. and Parreiras, F. S. (2015). Agile methods

tailoring - A systematic literature review. Journal of

Systems and Software, 110:85–100.

Chiarini, A. (2013). Lean Organization: from the Tools

of the Toyota Production System to Lean Ofﬁce.

Springer-Verlag.

Cockburn, A. (1998). Surviving Object-oriented Projects:

A Manager’s Guide. Addison-Wesley Longman Pub-

lishing Co., Inc., Boston, MA, USA.

Cohn, M. (2004). User Stories Applied: For Agile Software

Development. Addison Wesley Longman Publishing

Co., Inc., Redwood City, CA, USA.

Damiani, E., Colombo, A., Frati, F., and Bellettini, C.

(2007). A metamodel for modeling and measuring

scrum development process. In Concas, G., Dami-

ani, E., Scotto, M., and Succi, G., editors, Agile

Processes in Software Engineering and Extreme Pro-

gramming, 8th International Conference, XP 2007,

Como, Italy, June 18-22, 2007, Proceedings, volume

4536 of Lecture Notes in Computer Science, pages

74–83. Springer.

Eric, S. Y. (2009). Social modeling and i. In Conceptual

Modeling: Foundations and Applications, pages 99–

121. Springer.

Esfahani, H. C., Cabot, J., and Yu, E. S. K. (2010). Adopt-

ing agile methods: Can goal-oriented social modeling

help? In Loucopoulos, P. and Cavarero, J., editors,

Proceedings of the Fourth IEEE International Confer-

ence on Research Challenges in Information Science,

RCIS 2010, Nice, France, May 19-21, 2010, pages

223–234. IEEE.

Esfahani, H. C., Yu, E. S. K., and Annosi, M. C. (2011).

Towards the strategic analysis of agile practices. In

Nurcan, S., editor, Proceedings of the CAiSE Fo-

rum 2011, London, UK, June 22-24, 2011, volume

734 of CEUR Workshop Proceedings, pages 155–162.

CEUR-WS.org.

Fowler, M. and Highsmith, J. (2001). The agile manifesto.

Software Development, 9(8):28–35.

Henderson-Sellers, B. and Gonzalez-Perez, C. (2005). A

comparison of four process metamodels and the cre-

ation of a new generic standard. Information and soft-

ware technology, 47(1):49–65.

Henderson-Sellers, B., Ralyt

e, J.,

Agerfalk, P. J., and Rossi,

M. (2014). Situational Method Engineering. Springer.

Jacobson, I., Ng, P. W., and Spence, I. (2006). The essential

uniﬁed process-a fresh start for process. Dr Dobbs

Journal, 31(9):40–+.

Kolp, M., Giorgini, P., and Mylopoulos, J. (2002). Organi-

zational multi-agent architectures: a mobile robot ex-

ample. In Proceedings of the ﬁrst international joint

conference on Autonomous agents and multiagent sys-

tems: part 1, pages 94–95. ACM.

Kolp, M. and Mylopoulos, J. (2001). Software architec-

tures as organizational structures. In Proc. ASERC

Workshop on The Role of Software Architectures in

the Construction, Evolution, and Reuse of Software

Systems, Edmonton, Canada.

Kroll, P. and MacIsaac, B. (2006). Agility and Dis-

cipline Made Easy: Practices from OpenUP and

RUP (Addison-Wesley Object Technology (Paper-

back)). Addison-Wesley Professional.

Laanti, M., Simil

a, J., and Abrahamsson, P. (2013). Def-

initions of agile software development and agility.

In McCaffery, F., O’Connor, R. V., and Messnarz,

R., editors, Systems, Software and Services Process

Improvement - 20th European Conference, EuroSPI

2013, Dundalk, Ireland, June 25-27, 2013. Proceed-

ings, volume 364 of Communications in Computer

and Information Science, pages 247–258. Springer.

Liker, J. K. (2004). Toyota. Esensi.

Lin, J., Yu, H., Shen, Z., and Miao, C. (2014). Using goal

net to model user stories in agile software develop-

ment. In 15th IEEE/ACIS International Conference

on Software Engineering, Artiﬁcial Intelligence, Net-

working and Parallel/Distributed Computing, SNPD

2014, Las Vegas, NV, USA, June 30 - July 2, 2014,

pages 1–6. IEEE Computer Society.

Madeyski, L. (2010). Test-Driven Development: An Empir-

ical Evaluation of Agile Practice. Springer Publishing

Company, Incorporated, 1st edition.

Madi, T., Dahalin, Z., and Baharom, F. (2011). Con-

tent analysis on agile values: A perception from soft-

ware practitioners. In Software Engineering (MySEC),

2011 5th Malaysian Conference in, pages 423–428.

IEEE.

Martin, R. C. (2003). Agile Software Development: Prin-

ciples, Patterns, and Practices. Prentice Hall PTR,

Upper Saddle River, NJ, USA.

Mikul

enas, G., Butleris, R., and Nemurait

e, L. (2011). An

approach for the metamodel of the framework for a

partial agile method adaptation. Information Technol-

ogy And Control, 40(1):71–82.

Mylopoulos, J., Kolp, M., and Giorgini, P. (2002). Agent-

oriented software development. In Hellenic Confer-

ence on Artiﬁcial Intelligence, pages 3–17. Springer

Berlin Heidelberg.

Palmer, S. R. and Felsing, M. (2001). A Practical Guide to

Feature-Driven Development. Pearson Education, 1st

edition.

ICSOFT 2017 - 12th International Conference on Software Technologies

126

Poppendieck, M. and Poppendieck, T. (2003). Lean

Software Development: An Agile Toolkit: An Agile

Toolkit. Addison-Wesley.

Pressman, R. S. (2005). Software engineering: a practi-

tioner’s approach. Palgrave Macmillan.

Schuppenies, R. and Steinhauer, S. (2002). Software pro-

cess engineering metamodel. OMG group, November.

Schwaber, K. (2004). Agile project management with

Scrum. Microsoft press.

Schwaber, K. and Beedle, M. (2002). Agile software devel-

opment with Scrum, volume 1. Prentice Hall.

Schwaber, K. and Sutherland, J. (2011). The scrum guide.

Scrum Alliance, 21.

Shen, Z., Miao, C., Tao, X., and Gay, R. (2004). Goal

oriented modeling for intelligent software agents. In

Intelligent Agent Technology, 2004.(IAT 2004). Pro-

ceedings. IEEE/WIC/ACM International Conference

on, pages 540–543. IEEE.

Sidky, A. S., Arthur, J. D., and Bohner, S. A. (2007). A

disciplined approach to adopting agile practices: the

agile adoption framework. ISSE, 3(3):203–216.

Stapleton, J. (1997). Dsdm: The Method in Prac-

tice. Addison-Wesley Longman Publishing Co., Inc.,

Boston, MA, USA.

Tripp, J. F. and Armstrong, D. J. (2014). Exploring the rela-

tionship between organizational adoption motives and

the tailoring of agile methods. In 47th Hawaii Interna-

tional Conference on System Sciences (HICSS), pages

4799–4806. IEEE.

VersionOne (2016). 10th annual state of agile development

survey.

Wautelet, Y., Heng, S., Kolp, M., and Mirbel, I. (2014).

Unifying and extending user story models. In

Jarke, M., Mylopoulos, J., Quix, C., Rolland, C.,

Manolopoulos, Y., Mouratidis, H., and Horkoff, J.,

editors, Advanced Information Systems Engineering -

26th International Conference, CAiSE 2014, Thessa-

loniki, Greece, June 16-20, 2014. Proceedings, vol-

ume 8484 of Lecture Notes in Computer Science,

pages 211–225. Springer.

Yu, E., Giorgini, P., Maiden, N., and Mylopoulos, J. (2011).

Social modeling for requirements engineering. MIT

Press.

An Intentional Perspective on Partial Agile Adoption

127