Critical Changes in Adopting Agile Practices in Software Development

This report, based on a survey of 241 respondents, investigates the critical changes necessary for transitioning from traditional plan-driven software development to agile practices. The study, conducted by Misra, Kumar, and Kumar, examines changes in culture, management style, knowledge management, and development processes. The findings highlight the importance of moving towards iterative, test-driven, and people-centric development. While no single class of changes was deemed significantly more important, the transition from process-centric approaches was considered crucial by a majority of respondents. The research also identifies additional changes related to personal characteristics, customer attitudes, and stakeholder knowledge. This work aims to aid project managers in prioritizing changes during the transition to agile methodologies and provides valuable insights for software engineering professionals. The study emphasizes that a holistic approach is needed when adopting agile practices, considering multiple dimensions of change.

International Journal of Quality & Reliability Management
Identifying some critical changes required in adopting agile practices in traditional
software development projects
Subhas Chandra Misra Vinod Kumar Uma Kumar
Article information:
To cite this document:
Subhas Chandra Misra Vinod Kumar Uma Kumar, (2010),"Identifying some critical changes required in
adopting agile practices in traditional software development projects", International Journal of Quality &
Reliability Management, Vol. 27 Iss 4 pp. 451 - 474
Permanent link to this document:
http://dx.doi.org/10.1108/02656711011035147
Downloaded on: 27 June 2016, At: 03:11 (PT)
References: this document contains references to 59 other documents.
To copy this document: [e-mail]
The fulltext of this document has been downloaded 2211 times since 2010*
Users who downloaded this article also downloaded:
(2012),"Agile software development practices: evolution, principles, and criticisms",
International Journal of Quality & Reliability Management, Vol. 29 Iss 9 pp. 972-980 http://
dx.doi.org/10.1108/02656711211272863
(2015),"A contingency fit model of critical success factors for software development projects: A comparison
of agile and traditional plan-based methodologies", Journal of Enterprise Information Management, Vol. 28
Iss 1 pp. 7-33 http://dx.doi.org/10.1108/JEIM-08-2013-0060
(2011),"Understanding agile project management methods using Scrum", OCLC Systems
& Services: International digital library perspectives, Vol. 27 Iss 1 pp. 18-22 http://
dx.doi.org/10.1108/10650751111106528
Access to this document was granted through an Emerald subscription provided by emerald-srm:18
For Authors
If you would like to write for this, or any other Emerald publication, then please use our Emerald for
Authors service information about how to choose which publication to write for and submission guid
are available for all. Please visit www.emeraldinsight.com/authors for more information.
About Emerald www.emeraldinsight.com
Emerald is a global publisher linking research and practice to the benefit of society. The company
manages a portfolio of more than 290 journals and over 2,350 books and book series volumes, as w
providing an extensive range of online products and additional customer resources and services.
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

Emerald is both COUNTER 4 and TRANSFER compliant. The organization is a partner of the Committee
on Publication Ethics (COPE) and also works with Portico and the LOCKSS initiative for digital archive
preservation.
*Related content and download information correct at time of download.
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

Identifying some critical changes
required in adopting agile
practices in traditional software
development projects
Subhas Chandra Misra
Indian Institute of Technology (IIT), Kanpur, India and
Vinod Kumar and Uma Kumar
Carleton University, Ottawa, Canada
Abstract
Purpose – Agile softwaredevelopment(ASD) is currently an emerging approach in software
engineering forimproving quality,initially advocated by a group of17 software professionals
who practicea set of “lightweight”methods,and share a common setof values ofsoftware
development.Owing to the attractive claims of successes of the ASD approach,many traditional
projects,which used to practice plan-driven software development,are gradually transitioning
into ASD-based development.This paper seeksto reportthe resultsfrom a survey-based
ex-post-factostudy aimed at determiningthe relativeimportance,if any, of the changes
traditional plan-driven software development projects have to undergo to adopt ASD practices.
Design/methodology/approach – Thestudy wasconducted using a web-based survey with
ASD practitioners who had experience of practicing plan-driven software development in the past.
ASD practitioners from a wide range ofindustrialsectors participated in the study.Similarly,
the study is notrestricted to any specific organisation/projectsize,culture,or nationality – the
respondents were widely geographically distributed across continents.
Findings – The study received 241 responses, of which 165 were usable. The study did not reveal any
substantialdifferencein importanceof the four classesof changeshypothesised – changesin
culture,changes in managementstyle,changes in knowledge managementstrategy and changes
in development processes. The authors believe that this is an important finding because it is indicative of
notisolating one class of changes from another in practicaltransition exercises.However,another
noteworthy observation wasthat transitioning from heavily process-centricto short,iterative,
test-driven,and people-centric development was considered by the largest percentage (roughly 77 per
cent) of respondents to be very important.The open-ended questions in the study also revealed three
additionalclasses of changes:changes in personalcharacteristics,changes in customer attitude,and
changes in knowledge and education of stakeholders.
Originality/value – In this work an attempt was made to gain an understanding of the relative
importance of the different critical changes that would be helpful to a project manager who is involved
in the transition from traditionalplan-driven software developmentpractices to agile software
development practices.
Keywords Software engineering, Change management
Paper type Research paper
1. Introduction
ASD (Abrahamson et al., 2002; Cockburn, 2001, 2002a, b; Fowler and Highsmith, 2001;
Highsmith,2004;Fowler,2002;Larman,2004;Schwaber and Beedle,2002;Schwaber,
The current issue and full text archive of this journal is available at
www.emeraldinsight.com/0265-671X.htm
Adopting agile
practices
451
Received May 2009
Revised October 2009
Accepted October 2009
International Journal of Quality &
Reliability Management
Vol.27 No.4,2010
pp.451-474
q Emerald Group Publishing Limited
0265-671X
DOI 10.1108/02656711011035147
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

2004) is currently an emerging software development approach, constituting of
principles,initially advocated by a group of17 software practitioners[1],and now
practiced by many software professionals.The principles they advocated,leading to
the emergence ofthe ASD philosophy,are based on previous success and failure
experiences with many software developmentprojects regarding whatworks and
what doesnot in practice.Each of thesepractitionershad theirown different
philosophies about how they approached software development. However,all of them
advocated some common principles. These principles underlie the philosophy o
In the case of traditional software development projects,prior to the birth of the ASD
paradigm,were more focusedon following well-definedplans and detailed
documentations.In February 2001,the advocatesof the ASD philosophy met
together, and prepared the Manifesto for ASD, which is stated below (Cockburn,
2002a,b; Fowler and Highsmith,2001;Fowler,2002;Schwaber and Beedle,2002;
Schwaber,2004).
We are uncovering better ways of developing software by doing it and helping
others do it.Through this work we have come to value:
. individuals and interactions over processes and tools;
. working software over comprehensive documentation;
. customer collaboration over contract negotiation;and
. responding to change over following a plan.
That is,while there is value in the items on the right,we value the items on the left
more (Agile Manifesto).
Following 2001, many other software practitioners were inspired by the philos
behind ASD.It is pertinent to mention that prior to the birth of the ASD paradigm,
differentpractitioners used to follow some ofthe practices suggested by the ASD
paradigm in their software development projects.However,it is only after 2001 that
these set of practices were formalised and were together coined the term “agile
The overall goalof this work was to improve the understanding of the emerging
ASD approach by attempting to address the following question:
What are the important changes required for adopting ASD practices in projects prac
traditional plan-driven software development? Can we rank them according to their le
importance?[2]
We conducted a moderately large-scale[3]empiricalstudy involving 241 returned
survey questionnaires.While the existing articles available in the literature report
experientialinformation,anecdotalinformation and empiricalresults on different
aspects, there is no literature available,to the best of our knowledge, that use surveys
to attempt to identify the relative importance of the changes required in the sam
manner that we did.Important pieces of related existing literature are presented in
sections2 and 3. The feedback wereceived whileconducting thesurvey was
overwhelming. Many of the respondents, who are also experts in this area, have
interest in the work and its results.
The rest of the paper is organised as follows. In section 2, we review the back
and motivation of this work.In section 3,we describe the various changes required
based on intuition and existing literature.In section 4,we describe ourresearch
methodology.In section 5 we describe the results ofthe analysis ofthe data we
IJQRM
27,4
452
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

obtained from the survey we conducted. In section 6, we discuss the research findings
from different perspectives.Finally,in section 7 we conclude the paper and provide
some directions for future research.
2. Motivation and background
The primary motivation behind this work is to attempt to identify some of the changes
that should be prioritised by organisations who are transitionalto agile.With this
motivation ofattempting to help projectmanagers involved in such transitioning
activities, we conducted a survey-based empirical study. Before elaborating our work,
for the sake of maintaining the continuity of our discussions,we articulate below,in
short, some of the other empirically-based research works related to that were done in
the past. However, the list of references related to previous empirical studies should not
be construed to be exhaustive.
Detailed discussions on some of the empirical studies relating to different aspects
and perspectives of ASD projects exist in Abrahamson and Koskela (2004),Arisholm
et al.(2007),Bahetiet al.(2002),Baskerville et al.(2003),Ceschiet al.(2005),Chong
(2005),Dagnino etal. (2004),Dalcher etal. (2005),Jokela and Abrahamsson (2004),
Karlstroem and Runeson (2005),Layman et al.(2004),Macias et al.(2003),Mann and
Maurer (2005),Mannaro etal. (2004),Melnik and Maurer (2002),Middleton (2001),
Reifer (2002),Robinson and Sharp (2004),Rumpe and Schroder (2002),Sharp and
Robinson (2004), Shine Technologies (2003), Sillitti et al. (2005), Salo and Abrahamsson
(2008),Wellington et al.(2005),Misra et al.(2009) and Young et al.(2005).Apart from
the above, as mentioned in footnote 2, recent surveys on ASD by VersionOne and Scott
Ambler also exist. However, none of them are directly related to identifying the critical
changes required.
In a recent work,Dyba˚ and Dingsøyr (2008) published an excellent work in which
they systematically reviewed all the empirical studies,including the above,that have
been conducted tillrecently.However,none of these works is extremely similar in
nature and scope with the study reported in this paper.Therefore,in order to avoid
redundancy of discussions in the literature and to present our work contextually and
briefly,we avoid presenting a review of allthe above papers.Interested readers are
referred to Dyba˚ and Dingsøyr(2008)to geta detailed overview ofthe studies
presented in the works mentioned in the last paragraph.Instead,we articulate below,
in short,only a selection of those works.
Reifer (2002) is one of the first articles reporting survey results on agile methods.
Although the nature of the survey was very simple,using only a small data space,it
was important because it captured various experiences of ASD practitioners in various
industry types.Reiffer found thatfive firms reported thattheir defectrates from
product were at par with their other projects.
Baheti et al.(2002) conducted empirical studies on distributed pair programming.
They gathered empirical data in favour of pair programming in distributed teams,a
very important issue in the current world of off shoring and outsourcing of IT business
processes. Their study resulted in the creation of a special environment for distributed
programming using dual screen projectors,and hypermedia-enhanced video streams.
Rumpe and Schroder (2002)conducted a survey on extreme programming (XP)
projects.They found out that the continuous presence of customers was important in
XP projects. They also found out that although there are a plenty of problems in XP’s
success,it was found to be superior to some oftraditionalsoftware development
Adopting agile
practices
453
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

approaches.However,their survey had few limitations in terms of size,application
domains,and seeded biases.They called for further surveys on XP.
Kalermo and Rissanen (2002) used an empirical case study in the context of a
in-house software development in corporate venturing to find results supporting
principlesand valuesof the Agile Manifesto.Their study confirmed thattacit
knowledge,motivation ofemployees,and theirskills and knowledgelevelsare
important in ASD.
Shine Technologies (2003) conducted a simple survey of the global experienc
ASD.They found that companies that follow agile practices have lower costs,better
productivity,better quality,and better business satisfaction.
Abrahamson and Koskela (2004)performed a controlled case study on XP in
practicalsettings.In their study,they gotfour software engineers to implementa
web-based system of 7,698 lines of code over a period of 820 hours in eight wee
obtained favourable results in support of the usefulness of XP. It may be noted t
of these studies are limited in their magnitude and exhaustiveness of investigat
Arisholm et al. (2007) conducted another controlled case study to evaluate di
aspects of pair programming. The subjects they chose were required to perform
change tasks using professional Java tools on two Java-based systems. Their stu
not find evidence that pair programming reduces time to resolve tasks correctlyThe
readers may refer to the other detailed findings from their study.
Salo and Abrahamsson (2008)reported another interesting study in which they
attempted to gain an understanding ofthe actualuse and usefulness ofextreme
programming and Scrum in embedded systemsindustries.They surveyed 13
European organisationsand found outthat agilemethodshavepenetrated the
embedded systems industries and thatthe increase in adoption ofagile practices
increased the appreciation for such practices in such organisations.
Jokela and Abrahamsson (2004)attempted to study therelationship between
usability engineering and extreme programming.They investigated in a project the
extent to which extreme programming guides the development of usable softwa
Their findings reveal that extreme programming is poor in explicitly attending to
usability of software.
Karlstroem and Runeson (2005)reported the results of study of the feasibility of
using agile methods in traditional stage-gate project management environment
findings show that despite there are possibilities of some initial management re
of such an attempt, it is definitely possible to use agile methods in such environ
Wellington et al.(2005)performed yet another study in which they reported the
comparison of student experiences with both plan-driven and agile methods.They
measured team cohesion and students’attachments to projects throughout.They also
monitored the applications that were developed by the different teams. They fo
that all the teams developed almost the same amount of functionality,the XP team’s
code had better metrics. The teams that used the traditional process had to wri
code to implement the same functionality.
For reasons cited in the earlier part of this section, without discussing the pre
distantly related works any further,we now summarise the motivations behind our
work and our contributions.Let us assume that a software practitioner who used to
practice plan-driven software development wants to adopt ASD practices in a pr
that is about to start.He/she would be interested to know – what are the important
changes to be focused on to adopt ASD practices? There are potentially many c
IJQRM
27,4
454
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

to focus on. What is interesting to know are the critical changes, if any. As mentioned
previously, although there are some existing pieces of literature reporting the changes
required (to be elaborated in section 3),none of them relate to empirically identifying
the importance of the changes, if any, relative to one another. We have addressed this
issue in this work.This affirms the motivations behind the work.
3. The changes required for adopting ASD practices in traditional projects
3.1 Home-ground characteristics: rationale for change
Before discussing further about what changes would be involved for transforming
projects practicing traditional approaches into Agile ones,let us first look at some of
the home-ground characteristics of both of these development approaches.This will
help us further to understand what changes in these home-ground characteristics the
projects that want to adopt agile approaches would need to make.Before proceeding
further,we feel it is pertinent to explain the term “home-ground”.The term was used
by Boehm and Turner (2003) to refer to the fact that each of agile and the traditional
plan-driven approaches works better than the other.
A theoreticalanalysis ofthe propositions ofboth the agile approaches and the
traditional plan-driven disciplined ones was already done by Boehm and Turner (2003).
According to them, no one methodology can be regarded as the best, because in reality
it is hard to find some approach which can be regarded as a “silver bullet”. Boehm and
Turner proposed that instead of adopting just one methodology, balanced approaches
dealing with a mix of both the Agile and plan driven practices would be successful in
the future.While Agile approaches are betterin dealing with issues relating to
customer satisfaction,lower defectrates,faster changeability ofrequirements,and
fasterdevelopmenttimes,the traditional/plan-drivenapproachesare betterin
ascertaining thepredictability,stability,and high-assurancein the development
processes (Boehm and Turner,2003;Cockburn,2001;Deias et al.,2002;Elssamadisy,
2001;Mahanti,2006).
We believe Boehm and Turner’s suggestions are valuable.However,we even
believe,given the substantially opposite philosophies ofthe two approaches (viz.,
emphasis on well-documented plans in traditionalapproaches versus paying less
importance on plans in agile approaches),it would be usefulto stick to one type of
philosophy in its most part to avoid confusions in the adoption of a particular type of
philosophy over another during the course of the project.For traditional development
projects,intending to transform into Agile,what should be instead done is to identify
the most important changes required (instead of changing them all), and then focus on
only those that are critical for the success of projects.
Irrespective of whether a project wants to transform in whole or in part to Agile, in
any transformation project,it is a common practice to focus on the key areas at first
and then gradually move attention to the other areas. To be able to do that, identifying
the key changes required for adopting agile philosophies in a project would be useful.
3.2 Changes required
In this section,we present our work that may be helpful for software projects in the
future while transforming traditional software development processes into agile.Key
to the work is the identification of the different key changes that will be required for
adopting agile methods in a traditional software development project. In this paper, we
do not focus on the technical and application level changes.
Adopting agile
practices
455
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

There are a plenty of pieces of literature that suggest the changes required (b
experiences)in the transformation of traditionalprojects into agile,e.g.Boehm and
Turner (2005), Cohn and Ford (2003), McMahon (2004), and Nerur et al. (2005).
identified below some of the changes,which have gained popularity among different
researchers and practitioners.Initially, we attempted to classify all the changes based
on literature findings and intuition.Our contribution is to obtain a ranking ofthe
changes according to their levels ofimportance perceived from survey data.This
ranking will help the managers planning to adopt agile practices in the future to
on only the most important items instead of getting buried under the heavy load
working with all of them during a planned transition.
3.2.1 Changes in organisationalculture.One of the most important,but extremely
difficult to achieve,classes of changes that is required is the change in organisation
culture. Organisational culture needs a change from policy and procedure-based
of freedom of development and management by team members.The incorporation of
Agile practicesinfluencesthe values,norms,behaviourand actionsof people
(Cockburn and Highsmith,2001;Turnerand Boehm,2003),the decision making
processes,problem resolution strategies,customary practices,and the relationships
between employees and managers (Neruret al., 2005).The culturalchanges are
challenging to achieve,as these require the change in the habits and mindsets of th
people with which they have worked over the years.
Many authors,for example Boehm and Turner (2005) and Nerur et al.(2005),have
identified people issues to play an important role in the adoption of agile practicIn
traditionalorganisations,many developersare used to solitaryprogramming
activities.These developmenthabits the programmers in traditionalorganisations
have inculcated over the years can be resistive in the successfuladoption ofagile
practices.Many agile practices are based on the concepts ofpair programming,
collaborative decision making, onsite customers, and shared learning. The succ
all of these activities are dependent on the attitudes of people in the team towa
another.Nerur et al.(2005) proposed that working effectively in a team,high level of
competence,and the relationships with the customers in terms of the commitment
knowledge,proximity,trust, and respectand importantpeopleissues that
organisations should be concerned while transforming the existing processes in
the agile ones.
Customer-centric people issues are especially importantin agile organisations,
because most agile practices require the developers to work closely with the cu
Both thecustomersand developersare responsiblefor successfulcollaborative
decision-making.As a result,due to the involvement of many people from different
backgrounds and psychology, decision making can be more difficult than in trad
organisations,where the project managers are primarily responsible for most of th
decision-making activities (Nerur et al.,2005).
3.2.2 Changes in management style.The adoption of Agile processes in traditional
organisationsrequirea changein managementstyles(Beck,2000;Cohn,2005;
Williams and Kessler, 2002) from command-and-controlmanagementto
leadership-and-collaboration.In traditionaldevelopmentprojects,the project
managers’roles are that of someonewho would form a well-definedand
documented plan and would exercise and controlthem.However,because ofthe
paradigm shift from traditional/plan-driven in traditional projects to depending o
hoc plans in agile,the role of the project managers also requires a change to someo
IJQRM
27,4
456
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

who would facilitate the overalldevelopmentof the projects,work with the team
members equally,collaborate with them and coordinate their activities to ensure a
smooth completion of the projects. Therefore, as we see, the project managers who are
keen on adopting agile approaches in their organisations would also need to change
their management style.
3.2.3 Changes in knowledge management strategies.Another important issue is a
paradigm shift in knowledge management strategies from heavy documentation-based
to that of the management of tacit knowledge that mostly resides within the agile
developers.This is a consequence of the agile approaches paying less importance on
documentation. If there is a lack of documentation, most of the knowledge resides with
the developers or some of some of the information may be buried in the code as well.
Consequently, how this tacit knowledge will be managed brings in a new focus area in
agile projects.
3.2.4 Changes in development processes.One of the important differences between
traditionaldevelopment practices and the agile practices is that while the former is
heavily process-based, the emphasis on processes is relatively less in the latter. Instead,
the agile practices pay more importance to people-centric development.
Developmentprocesses need to change[4]from heavily process-centric to short,
iterative,test-driven,people-centric development,from standards compliance and
measurement-drivendevelopmentto developmentunder uncertainty,from
contract-compliantto change-tolerantdevelopment,and from lifecycle-based
development to feature-driven evolutionary and iterative development (Nerur et al., 2005).
Based on the discussions above,we come up with an a priorilist of changes we
believe are important.This list is available in Table I and it was drawn based on
information obtained from existing literature identified in sections 2 and 3.2.From a
systematic review of the existing literature,we attempted to collect assertions and/or
established facts about the potential changes required.It should be emphasised that
this list is merely an assertion at this point,as is reflected by the word “a priori”.
Through survey (with both quantitative and qualitative analysis)we try to get an
indication ofwhich ofthese change items the respondents believed to be valid
according to their opinion.
4. Research methodology
The research methodology we used in this work is one thatis typically used in
survey-based management information systems research (Creswell,2003;Lazaro and
Marcos, 2005; Newman, 2005; Pfleeger, 1995; Zelkowitz and Wallace, 1998). The core of
the methodology is survey-based,post-facto investigation.Broadly,it consists of the
following three phases:
(1) Phase I.Formulation of the research question,and the a priori list of changes
required.
(2) Phase II.Designing the survey instrument and the collection of data through
surveys.
(3) Phase III.Analysis of the data collected as part of phase II.
We used the a priorilist of changesto design a questionnaire (with primarily
closed-ended questions),which werepre-tested forits validity,usefulness,and
readability before itwas sentout for data gathering from the field.Requestfor
Adopting agile
practices
457
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

pre-testingwas sent out to ten potentiallyqualifiedsoftwaredevelopment
professionals.Out of the ten requests,only five agreed tohelp (50per cent
turnaround rate).Pre-testing was finally done with the help of those five software
development professionals.They had different experience levels and work functions
and worked in both the government and the private sectors.While four of the five
respondents did not have any major suggestions for improvement, one suggest
changes forimproving the clarity ofthe questions.Overall,there was notmuch
revision that was required as a result of the pre-testing.
Pre-testing the questionnaire was helpfulfor clarifying any ambiguities in the
questionnaire, its readability, and the ordering of the questions. Based on the re
the pre-test, the original questionnaire was revised to reflect the feedback of th
respondents.
In the questionnaire,we also collected any additional changes that were suggeste
by the respondents.The crucialportion ofthe questionnaire is presented in the
Appendix. To maintain the brevity of this paper, only the portions of the questio
that relate to the changes required are given. In the original questionnaire, ther
additionally,questions seeking the background information of the respondents.The
advantage of the open-ended questions is that they enable the respondents to
some additionalinformation,which was not captured in the close-ended questions.
These open-ended questions were not used in statistical analysis, but their resp
such questions are summarised atthe end ofsection 5.The multiple-choice type
questions ask the respondents to rank their responses on a Likert’s scale of 1 to
Change items Label
Changes in organisational culture (from plan-driven to agile) C1
From policy and procedure-based development culture to freedom of
development and management by team members
C1.1
From individually assigned roles to that of teamwork C1.2
From solitary development attitudes of team members to that of working in
teams
C1.3
From no technical and interpersonal competency requirements in team
composition to establishing a minimum set of competency requirements of team
members
C1.4
From non-customer-centric to customer-centric development. C1.5
Changes in management style (from plan-driven to agile) C2
From command-and-control management to leadership-and-collaboration C2.1
From authoritative to collaborative and pluralistic decision making (i.e.where
all the development team members are given sufficient importance in decision
making)
C2.2
Changes in knowledge management strategy (from plan-driven to agile) C3
From heavy documentation-based to tacit (not spoken) knowledge managementC3.1
Changes in development processes (from plan-driven to agile) C4
From heavily process-centric to short,iterative,test-driven,and people-centric
development
C4.1
From standards compliance and measurement-driven development to
development under uncertainty
C4.2
From contract-compliant to change-tolerant development C4.3
From lifecycle-based development to feature-driven evolutionary and iterative
development
C4.4
Table I.
Labels used for the
change items in the
analysis
IJQRM
27,4
458
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

(1 – strongly disagree and 5 – strongly agree).The close-ended multiple-choice type
questions helped us to perform statistical analysis on the available data.
The data obtained from the closed-ended questions were then statistically analysed
using suitabledata analysistechniques.We used thesetechniquesto gain an
understanding ofthe importantchanges required foradopting ASD practices in
projects practicing traditionalplan-driven software development,and ranking them
according to their levelof importance.Multiple projects practicing ASD techniques
were surveyed. We did not restrict our surveys to any particular industry type, sector,
or size.The only requirement we had was that the survey respondents practice ASD,
and they had transitioned in the past from traditional software development practices
to those advocated by the ASD community.
The survey was administered using a web-based questionnaire technique.Since
we were interested in gathering the experiences of a large number of users of ASD
practices,we sentour survey questionnaireto potentialrespondentsin various
industrial sectors (such as manufacturing, electronics, telecommunications, aerospace,
oil and gas)that are practicing ASD.Similarly,we did not restrict ourselves to any
particular organisation/projectsize,culture,or nationality.With this approach we
were able to survey ASD practitioners thatare widely geographically distributed
across continents,it was cost-efficient,and the respondents were able to answer the
questionsmorethoughtfully.The web-based questionnaireallowed thesurvey
respondents to complete parts of the survey according to their own time.This also
enabled them to do some “homework”, if necessary, before being able to answer some
of the questions.
In our research, identifying the respondents was a challenge, because ASD is still an
emerging approach that has gained popularity only in the last four to five years.In
organisations,often only a few teamsare practicing ASD.Therefore,it was
challenging to identify the specific respondents (and teams)in organisations who
qualify to respond to our questionnaire.We did considerable amount of research on
this issue,and have been fortunate to find the following sources for collection of data:
. CIO Magazine’s August 2004 issue lists the awardee organisations of the “Agile
100” awards.However,this list identifies only the candidate organisations on
which we can focus. Determining the specific contacts in these organisations still
remained a challenging issue.
. Agile Alliance (www.agilealliance.org)has a publicly available listof all its
corporate members.As they are members of the Agile Alliance,it is likely that
these organisations have teams who practice ASD.
. Agile Alliance was also requested to circulate the questionnaire to its individual
members as they were not willing to reveal the contact e-mail addresses of those
members.They agreed to help in this process.
. Previous research papers and experience reports published in this area by
industry-based authors were collected. Those authors were approached by e-mail
to fill out the web-based questionnaire.
. The contactperson ofdifferentagile user groups throughoutthe world was
contacted by e-mailto fill out the web-based questionnaire.They were also
requested to forward the questionnaire to other members in their user group and
also to the other team members at their place of work.
Adopting agile
practices
459
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

. The committee members ofthe differentagile conferences thatare currently
announced or have already taken place in the past were also approached.
. Severalblog and website postings ofthe survey link were also done.The
respondents were also requested to help in doing this in blogs they were
associated with.
In almost allcases in which we were successfulin obtaining the specific names of
individuals who potentially practice agile, we sent out a reminder after a week o
remind them,in case they had not already filled out the questionnaire.
The depth ofdata analysis thatwe could perform depended on the number of
responses that we could obtain. Our initial target was to obtain at least 150 resp
The respondenteligibility criteria thatwere setto consider responses for further
consideration of data analysis were:
(1) Does the respondent’s team practice at least six of the 12[5] ASD principle
(2) Has he/she ever been part of a team that used to practice traditional, plan
software development,and had adopted agile practices in the past?
We received 241 responses,of which there were 165 were eligible responses,i.e.
responses which satisfied the eligibility criteria mentioned above,for the changes
required survey.In Tables II to VI,we present some of the background information
about the respondents who took part in the survey.
5. Analysis and results
The approach for data analysis was quantitative (statistical)in nature,with some
qualitative analysis of the data collected through replies to the open-ended que
Size of the organisation (number of employees) Percentage respondents
Greater than 1,000 26.8
501-1,000 27.6
101-500 10.2
41-100 7.9
21-40 9.8
10-20 5.9
Fewer than 10 11.8
Table III.
Number of employees in
the organisations of the
respondents
Primary line of business Percentage respondents
Computer-related 32.5
Consulting organisations 29.8
Banking/insurance 10.2
Education/research 5.1
Medical/healthcare 2.4
Travel,logistics,transportation,government contractor,agriculture,
and integrated workplace management 7.9
Others (hospitality,legal services,and non-profit organisations) 12.1
Table II.
Primary line of business
of the industries to which
the respondents belong
IJQRM
27,4
460
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

the questionnaire.The data analysis forthese studies was performed using two
datasheets.Each of the datasheets showed separate lists of changes required.Every
survey respondent had ranked his/her judgment of the level of importance of each of
the change items on a five-point Likert scale. The results of the statistical analyses are
summarised[6] below.
5.1 Descriptive statistics
We first performed descriptive statistics to gain an understanding ofthe overall
distribution of the survey responses to the closed-ended questions. We determined the
median statistics corresponding to each change item, as the data are primarily ordinal
in nature.The medians obtained from this step were then assessed to gain an
understanding of the relative importance of each of the change items as viewed by the
survey respondents. The different change item variables used and their corresponding
labels are listed in Table VI.
Table VII shows the medians[7]corresponding to the data obtained from the
respondents for each ofthe differentchange item variables.It shows that,on an
average,the respondents felt that the majority of the change items are in the range
(“somewhat important”,“very important”).
The consolidated distribution of the responses (in percentage figures) obtained from
all the respondents for the different change items was captured.They are shown in
Table VIII.The verticalcolumns in the table representthe differentpoints in the
Size of the teams (number of employees) Percentage respondents
Fewer than 5 19.4
5-10 33.3
11-20 26.3
21-40 10.3
Greater than 40 10.7
Table IV.
Number of employees in
the teams of the
respondents
Job function Percentage respondents
Developers/testers 29.5
Team leaders 18.9
Project managers 17.7
Functional managers 7.9
Other roles (director,business analyst,software
architect,scrum master,and usability analyst) 26.0
Table V.
Job functions of the
respondents
Number of years Percentage respondents
Less than 1 19.6
1-3 30.0
3-5 26.4
Greater than 5 24.0
Table VI.
Number of years
developing software
using agile
principles/methods
Adopting agile
practices
461
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

Likert-scale.Just from analysing the data presented in the table,amongstall the
change items,C4.1 (i.e.from heavily process centric to short,iterative,test-driven,
and people centric development) was considered by the largest percentage (am
all the percentagefigures)of respondents(roughly77 per cent)to be very
important.
5.1.1 Test of internalconsistency reliability.We also attempted to investigate the
internal consistency of the change items. Table IX shows the reliability statistics
1 (%) 2 (%) 3 (%) 4 (%) 5 (%) X (%)
C1
C1.1 1 2 13 32 46 6
C1.2 2 2 11 29 53 3
C1.3 0 1 3 24 69 3
C1.4 2 5 13 39 33 6
C1.5 1 3 6 21 65 4
C2
C2.1 1 2 3 23 67 4
C2.2 1 3 7 37 49 4
C3 1 5 11 52 26 5
C4
C4.1 1 1 3 15 77 3
C4.2 3 6 16 42 26 6
C4.3 0 5 7 33 48 6
C4.4 0 2 7 27 60 3
Table VIII.
Consolidated distribution
of the responses (in
percentage figures)
Variables n Median
C1 165 4.4
C1.1 165 4.0
C1.2 165 5.0
C1.3 165 5.0
C1.4 165 4.0
C1.5 165 5.0
C2 165 4.5
C2.1 165 5.0
C2.2 164 4.0
C3 165 4.0
C4 165 4.5
C4.1 165 5.0
C4.2 164 4.0
C4.3 165 5.0
C4.4 165 5.0
Table VII.
Median values of the
different change items
Cronbach’s Alpha Cronbach’s Alpha based on standardised itemsNumber of items
0.822 0.833 4
Table IX.
Reliability statistics
IJQRM
27,4
462
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

the four consolidated change items C1,C2,C3,and C4.It can be seen that the value of
Cronbach’salpha is 0.822,which impliesthat thereis 82.2 percentof internal
consistency, whereas 17.8 percent inconsistency in test scores. Also, since the value of
Cronbach’s alpha is well above the acceptable cut-of-limit of 0.6 and the adequate cut of
limit of 0.7,there is significant internal consistency between the test items.
The reliability statistics and the correlations between items constituting to form the
higher levelchange variables C1,C2,and C4[8]were also computed.The value of
Cronbach’s alpha for items within C1 is 0.819,that corresponding to the items within
C2 is 0.799 and that corresponding to the items within C4 is 0.786. All of these values of
Cronbach’s alpha are well above the adequacy cut off limit of 0.7.
5.1.2 On the issue of determining the relative importance of the change items.For
attempting to determine the relative importance of the change items, we primarily have
the median scores of all the responses from all the respondents in Table VII on which
we can base our analysis.Based on allthe median scores from allthe consolidated
change items,we observe thatchanges in organisationalculture (C1),changes in
management style (C2) and changes in development processes (C4) have close median
values (4.4-4.5).Although,the median value of changes in knowledge management
strategy (C3) is slight less (4.0) compared with the above three,it is not substantially
different.Additionally,given that different consolidated change item was measured
with varying number of constituentchange items,the authors personally feelthat
purely based on the median analysis of this study, there is no substantial quantitative
evidence of ranking one of the four change items (C1-C4)more important than the
others.
Visual inspection of the constituent change items within each of the consolidated
change items (C1-C4)show that it would not be much meaningfulto conclude one
changeitem to be substantiallymore importantthan another.For example,
consideringthe constituentchangeitems within C1, we observethat “from
individually assigned roles to that of team-work” (C1.2),“from solitary development
attitudesof team membersto that of working in teams”(C1.3)and “from
non-customer-centric to customer-centric development” (C1.5)have a slightly higher
median (5.0)compared to “from policy and procedure based development culture to
freedom ofdevelopmentand managementby team members” (C1.1)and “from no
technicaland interpersonalcompetencyrequirementsin team compositionto
establishing a minimum setof competency requirements ofteam members” (C1.4),
whose median is 4.0.Similar observations can be made for the other consolidated
change items C2-C4 as well.
However,inspecting the percentage response figures for each of the change items
presented in Table VIII,it can be observed that change item C4.1 was considered by
largest percentage (amongst allthe percentage figures)of respondents (roughly 77
percent)to be very important.This is followed by change items “from solitary
development attitudes of team members to that of working in teams” (C1.3),“from
command-and-control management to leadership-and-collaboration” (C2.1) and “from
non-customer-centric to customer-centric development” (C1.5), for which the figures are
69, 67 and 65 percentrespectively.All theseobservationsare apparently not
counter-intuitive.
5.1.3 Responses to open-ended questions.The respondents were also requested to
list up to five additional changes they believed are required for adopting ASD practices
in organisations practicing traditional,plan-driven methodologies.Being an optional
Adopting agile
practices
463
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

question, some of the participants responded to the open-ended questions, whi
did not.Let us now present the consolidated discussion of the results obtained fr
both quantitative and qualitative data we obtained from the survey.
5.2 Changes in management style
Transitioning from command-and-controlmanagementto leadership-and-
collaboration wasranked asthe mostimportantchangerequired,followed by
transitioning from authoritative to collaborative and pluralistic decision making.
Changes in the managementstyle for agile approaches was also suggested by
respondents through the open-ended questions in different ways.Changes suggested
include having management permissive of making changes,having the openness in
management activities, trusting their developers, shifting away from large-scale
management to continuous (micro)scope management (without micromanaging the
activities ofthe developers),risk and uncertainty acceptance by the management,
having transparent radiators of project status and information,being honest while
communicating about the progress of the project,and having non-dictating or non
micromanaging management.According to the view of one of the respondents:“drive
to agile has to come from within the team – allow team to controlnotmanagers
dictating method”.It was suggested that,in agile practices,the business analysts
should be engaged from the early stages by the management.One of the respondents
also cautioned that (since the agile approaches part away from quantitative me
of control) it can be disastrous for the project if there is a significantly diminishe
of focus on progress measurement.
5.3 Changes in organisation culture
Through statisticalanalysis the following change items belonging to “changes in
organisation culture” were ranked (according to their decreasing order of impor
(1) From solitary development attitudes of team members to that of working
teams.
(2) From non-customer-centric to customer-centric development.
(3) From individually assigned roles to thatof teamwork (note:based on the
discussions above,although this change item have been ranked below the
immediately preceding one (with Rank 2 above)purely on the basis of their
respective means,there is no statistically significant difference of their means
as indicated by pair wise t-test).
(4) From policy and procedurebaseddevelopmentcultureto freedom of
development and management by team members.
(5) From non-customer-centric to customer-centric development.
Through the analysis of qualitative data obtained through open-ended questionit
was suggested that,for ASD,there should be changes in organisation culture that is
supportive of continuous communication, knowledge sharing, increasing the cul
trust that is generally absent in many organisations,making the business sponsors
responsible for prioritisation of tasks, and planning of the releases, increasing th
of honesty and openness in communication in the organisations,having a suitable
development team environment,involvement of allmembers in team activities,and
increasing the culture ofbeing adaptive rather than being predictive.It was also
IJQRM
27,4
464
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

suggested thatthereshould be“a right to errorsculture”,meaning thatthe
organisation culture should be such that errors can happen and the developers should
not be penalised for the same.
5.4 Changes in development processes
Through statisticalanalysis the following change items belonging to “changes in
developmentprocesses”were ranked(accordingto their decreasingorder of
importance):
(1) From heavily process-centric to short,iterative,test-driven,and people-centric
development.
(2) From lifecycle-based development to feature-driven evolutionary and iterative
development.
(3) From contract-compliant to change-tolerant development.
(4) From standardscomplianceand measurementdriven developmentto
development under uncertainty.
Through the analysis of qualitative data obtained through open-ended questions,it
was suggested that, the development processes in agile require a shared team room for
pair programming and continuous interactions, performing continuous integration and
mocks,performing test-driven development (in which the test plans dictate further
development activities),having tools that enable the kind of collaboration required in
agile practices,reducing the scope ofthe projects,performing lots ofprototyping,
performing continuousbuilds in small stepsand performing weekly releases,
performing functional testing along with coding,and having the customers and other
stakeholdersto providecontinuousfeedback.It was also suggested thatthe
developmentprocessesin ASD require the architectsto work alongsidethe
programmers.
5.4.1 Changesin knowledgemanagementstrategies.Traditionally,in heavy
process-centric organisations there is a high emphasis on documentation as a medium
for knowledge management.However,the agile practices tend to partaway from
heavy documentation-centric development approach and emphasise more on “show
working software” type development approach. As aptly put by forward by one of the
respondents:
One of the ability to reject structured documentation,such as a survey instrument,when it
doesn’t help my client.
Apart from the above,the followingadditionalchangeswere suggestedby
respondents through the responses to the open-ended questions.
5.4.2 Changes in personalcharacteristics.Different suggestions for changing the
personal characteristics of the team members were also received. It was suggested that
individual team members should be self-motivated to make continuous changes as and
when required,they should be knowledgeable aboutthe business,they should be
courageous,they should develop the habit of collectively owning the solutions,they
should earn the trust of the customers and other stakeholders,and they should have
high degrees of tenacity. It was also suggested by a respondent that the technical folks
in the teams should have sales skills. However, the reason for that is not apparent, but
it is worth capturing.
Adopting agile
practices
465
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

5.4.3 Changes in customer attitude.It was suggested by a few respondents that
adopting agile practices require changes in attitudes and behaviours of custome
as trusting the development team members and their willingness to negotiate w
required (of course,the willingness to negotiate is also expected of the developmen
team members).It was also suggested thatthe unlike in traditionalplan-driven
development,in the agiledevelopmentculture,the programmersshould notbe
required to provide justification of each task they perform.It should be sufficient if
they deliver the required working software.
5.4.4 Changes in the knowledge and education.All stakeholders (particularly the
upper management)should be educated about the principles and values guiding the
agile practices.The same holds for the development team members.They should,in
fact, be knowledgeableabout how to perform developmentusing the agile
methodologies.In the words of one of the survey respondents:
If one person does not have the knowledge about agile development and is unwilling
he can be a real stopper for the project (management included).
The above discussions show thatmostof the change categories were considered
earlier.However,many new individualchangeitemsmeasuring thehigh-level
change categories are discussed.It should be noted that the list of changes already
considered aspart of the closed-ended questionshavebeen prepared based on
literature review and review ofa plenty ofexperience reports.Therefore,it is not
surprisingthat most of the importantdimensionsof changewere already
considered.
We have seen that solely from the analysis of the quantitative data obtained,
change dimensions thatwe considered show statistically significantresults.In the
absence ofany particularliterature justifying ourranking results,based on the
qualitative logical reasoning,the discussions from the existing pieces of literature in
this area,and the results obtained from the analysis ofthe qualitative responses
obtained through the open-ended questions, we find that all the four change ca
are appropriately justifiable.
6. Limitations and scope
The studies of this nature are often accompanied by different limitations of vary
severities.It is, therefore,important to view the research outcome presented in this
paper within the bounds of these limitations.These limitations and those specifically
presented in section 7 should be considered together to inspire future research
this topic:
(1) In this work, we attempted to find evidences based on surveys. However,
technique has its own limitations.For instance,it may notbe advisable to
construe these findings as universally applicable in all kinds of environmen
such as project types and sizes,application domains and organisationaland
communal cultural domains.
(2) The variables used in the study are each complex in their nature.There are
highly subjective and there is likely to be only limited conceptualagreement
within the field.Therefore,the results relating to them should be viewed
accordingly.
IJQRM
27,4
466
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

(3) Owing to limited availability of sufficiently related concrete literature in the
specific problem we address in this paper,the pieces of literature that are used
to conceptualise each construct are not always scientific.This may sometimes
influence the research findings.We tried to measure each ofthe change
variables in terms of multiple factors. We had to resort to measuring each of the
constructs in terms ofonly a selection ofconstituentfactors.The more the
number ofsuch constituentfactors,the betterrepresentative the construct
measures whatit is trying to measure.However,too many such factors
measuring a constructhave a negative impacton the length ofthe survey
instrument.In our case,we had to restrictourselves to only a few such
constituent factors, as we were dealing with a large number of constructs in the
survey instrument already.
(4) The methodology of asking a few people for their opinion without a mediated
focus group methodology has its limitations, even if the questions were tested to
be reliable in terms of Chronbach alpha and the questionnaire was pre-tested for
its validity, usefulness, and readability before it was sent out for gathering data
from the field.Although this research methodology is often undertaken in
similar kinds of research in empiricalsoftware engineering and management
information systems, it is possible that biasness and other psychological factors
may have an influentialeffect on the overallresearch results.It is, therefore,
advisable to treat the research results accordingly.More fresh and follow-up
work in the future is called for to address some of these deficiencies.
(5) In this work,we have limited ourselves to analysing the consolidated data
obtained from various respondents of different continents around the world.
We have not conduct a detailed investigation of the transcontinental/cultural
differencesin the successfactors.As we may haverealised from our
previous discussions, ASD is influenced by behavioural/personal
characteristicsof respondents.Such an investigationwould require
capturing notonly the country/continentof origin of the respondent,but
also theirplacesof work. There is a significantamountof complexity
involved in this kind of research,becausein today’s global economy,
organisations are distributed throughoutthe world,many employees travel
across continents,they might have been educated/trained in one culture,but
their work behaviourhas changed overthe years by working in different
culturalenvironments.The investigation of this issue was scoped out of this
study,butis encouraged in the future.
(6) We targeted individuals butasked them aboutteam information (including
other liasing teams) and company issues and indeed societal issues. This means
that responses from individuals in the same team, company or the same country
would not be independent for some questions. In cases where the questionnaire
was circulated through usergroups and otherforums,it was indeed not
possible to identify how many ofthe respondents belonged to a particular
company, project or society. We maintain that, this is, in fact, something that is
best achievable using other research methodologies such as case studies and
interviews. Other similar issues, such as the relationship between societal-based
questions and the nationality of respondents and checking whether respondents
from differentcountriesare consistentwith respectto the societal-based
Adopting agile
practices
467
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

questions are certain issues that have been left behind. This would require
capture other information such as the nationality of the respondents.As the
questionnairedid not capturethe ethnicorigin, the nationalityof the
respondents,etc.,we listthis issue here as a limitation ofthis study worth
investigating in future studies of similar nature.
(7) This study is limited within the assumption bounds thatthe data obtained
across different work functions are equally important. It would have been
interesting to investigate if at allthere willbe any differences in the results
based on thework functionsof the respondents.However,that required
changes in the original survey design and instrument preparation – we lea
this as a future activity of potential interest.
(8) In our research methodology,we take the various variables in each area and
simply take their average (median).However,the conclusions are likely to be
influenced by the choice of,and categorisation of,the questions.
7. Conclusions and future work
In this work we attempted to gain an understanding ofthe relative importance,if
any,of the different changes that are required for transition to ASD.We undertook
a survey-based ex-post-facto study.First,the required changes were hypothesised
based on intuition and previous literature.Thereafter,different software
developmentpractitionerspracticingagile principlesin their projectswere
approached with both closed-ended and open-ended typequestions.While the
closed-ended questionsformed thecoreof the study,the open-ended questions
helped in getting fresh perspectives from currently practicing ASD practitioners
from different industry sectors.The responses were obtained from different industry
sectors including those having the primary line ofbusiness as computerrelated
(hardware/software/IS/MIS),consulting,banking/insurance,healthcare,and
aerospace.The respondents belonged to both smalland large sized organisations
and teams.Responses came from allrole types – software developers/testers,and
all management levels.
The feedback we received while conducting the survey has been overwhelmin
Many of the respondents,who are also experts in this area,have had even shown
interest in the work and its results.
Let us now summarise our research contributions:
(1) Determining the relative importance ofthe changes.There was no strong
evidence to rank any of the four hypothesised consolidated change items
changes in organisationalculture,changes in management style,changes in
knowledge managementstrategy and changes in developmentprocesses–
more important than the other.This is indicative of the fact that one cannot
isolateone kind of changefrom another.Anotherobservation wasthat
transitioning from heavily process-centric to short,iterative,test-driven,and
people centric development was considered by the largest percentage (ro
77 percent) of respondents to be very important.
(2) Determining additionalchanges, if any.From the responses obtained from the
open-ended questions, we were successful in finding additional changes. T
seeminglyimportantchangecategoriesemerged.They are: changesin
customerattitude,changes in personalcharacteristics and changes in the
IJQRM
27,4
468
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

knowledge and education of the stakeholders. The above items did not initially
appear in our hypothesised list of changes. This is because we hypothesised all
the changes based on oursearch ofexisting literature,and oursearch of
existing literature did not find sufficient evidences supporting the consideration
of such factors in the literature.This, however,does not indicate that these
newly suggested changes are notimportant.As the identification ofsuch
changes is a complex problem guided by several factors,we call for additional
research to examine them.
Many issues are worthy of detailed investigation in the future. Three important issues
are outlined as follows:
(1) Further research should be done to validate the results obtained from this
study in practice.Practitioners should attempt to use the results obtained in
this study in actual projects and test the degree of usefulness of the results in
practice.This is importantbecausealthough the resultsobtained in this
paperhavebeen obtained by statistically analysing theresponsesfrom
currently practicing agile software professionals,unless they are deemed to
be of use in practice,the research results would be of limited use other than
serving as an inspiration for future researchers to conduct further research in
this direction.
(2) Owing to the nature ofthese studies,controlled experiments,where by one
factor is kept constant while varying others to different degrees,are difficult
to conductin real-lifeprojects.To overcometheseit is suggested that
computer-based simulation studiesshould beperformed tovalidatethe
resultsobtained from thisstudy.Such controlled experimentswould be
helpfulto examine the detailed behaviour/characteristics ofone particular
issue.
(3) Not all agile methodologies are light on process.For example,Feature Driven
Development(FDD),Agile Unified Process (AUP)and MicrosoftSolutions
Framework (MSF) for agile software development. All these have quite specific
and detailed processes.It would havebeen extremely usefulto have a
breakdown of which particular agile methods they were employing.
Notes
1. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin
Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,
Robert C.Martin,Steve Mellor,Ken Schwaber,Jeff Sutherland,Dave Thomas.
2. There are many tasks (with respectto projectquality)required for transitioning for a
software practitioner who used to practice plan-driven software development,but wants to
adopt ASD practices in a project that is about to start. The word “importance” refers to those
tasks that should probably bedonebeforethe many othertasks required forthe
change/transition.
3. Reports on other large-scale surveys also exist.For instance,Version One runs an annual
survey.The second annualsurvey,conducted in 2007,was aimed at identifying the state
of agile software development.It is available at: www.versionone.com/pdf/
StateOfAgileDevelopmet2_FullDataReport.pdfAnothernotablelarge-scalesurvey was
conducted by Scott Ambler and was published in June 2008 in the Dr Dobb’s journal.It is
Adopting agile
practices
469
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

availableat www.ambysoft.com/surveys/agileFebruary2008.htmlThis survey was
particularly aimed at identifying the agile adoption rate.In contrast to their studies,our
study was particularly focused atidentifying the changes required foradopting ASD
practices.
4. It is importantto note atthis juncture thatthis statementmakes many assertions,and
each assertion has assumptions and values thatdrive it.For example,it states that
organisations need to move from contractcompliantto change-tolerant.However,the
domain in which the organisation works may be very contract-driven,and thus it may be
necessary to remain contract-compliant.In practice,it is not as simple as just choosing to
give up one approach and adopt another.A big question arises in this case,if one has to
remain contract-compliant,then how one reconciles this with ASD.These issues are
complex and they require in-depth analysis probably using other research methodolo
They cannotbe addressed through the study thatwe conducted.We encourage future
work to investigate these.
5. The rationale behind this is that it might be infeasible to find projects that follow all t
agile principles.This is because,as ASD is still an emerging philosophy,finding projects
that follow the agile practices is difficult,and finding projects that follow all the practices
was even more difficult (if not,nearly impossible).Therefore,initially we set the target to
identifying projects that follow at least 50 percent of those principles.While there was no
hard rationale behind choosing this figure,we felt that this figure was neither too high nor
too low.
6. Details of all results can be found in Misra (2007).
7. As pointed outby one ofthe reviewers,the data thatwe primarily have is ordinal.
Calculating means,standard deviations and variances are not much meaningfulin such
cases.The problem is that we do not know if the “distance between” various points on
Likert scale are equal or not, nor what their distances are, and, thus calculating thes
is not much meaningful.
8. It should be noted that C3 is measured with only a single item.
9. The questionnaire also collected the background information of the respondents.These are
not shown here,but can be included,if the reviewers so request.
References
Abrahamson,P. and Koskela,J. (2004),“Extreme programming:a survey ofempiricaldata
from a controlled case study”,Proceedings ofthe 2004 InternationalSymposium on
EmpiricalSoftwareEngineering(ISESE’04), RedondoBeach, California,USA,
pp.73-92.
Abrahamson,P., Sallo,O. and Ronkeinen,J. (2002),“Agile software developmentmethods –
review and analysis”,VTT PublicationsNo. 478,availableat: www.inf.vtt.fi/pdf/
publications/2002/P478.pdf (accessed December 2005).
Arisholm, E., Gallis, H., Dyba˚, T. and Sjøberg, D.I.K. (2007), “Evaluating pair programming wit
respect to system complexity and programmer expertise”, IEEE Transactions on So
Engineering,Vol.33 No.2,pp.65-86.
Baheti,P., Williams,L., Gehringer,E., Stotts,D. and Smith,J.M. (2002),“Distributed pair
programming:empiricalstudiesand supportiveenvironments”,technicalreport
TR02-010,Departmentof ComputerScience,University ofNorth Carolina atChapel
Hill,Chapel Hill,NC,March.
IJQRM
27,4
470
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

Baskerville,R.,Ramesh,B.,Levine,L.,Pries-Heje,J. and Slaughter,S.(2003),“Is internet-speed
software development different?”,IEEE Software,Vol.20 No.6,pp.70-7.
Beck,K. (2000),Planning Extreme Programming,Addison-Wesley,Boston,MA.
Boehm,B. and Turner,R. (2003),“Observationson balancingdisciplineand agility”,
Proceedings of the Agile Development Conference (ADC’03), Salt Lake City, Utah, USA,
June,pp.32-9.
Boehm,B. and Turner,R. (2005),“Management challenges to implementing agile processes in
traditional development organizations”,IEEE Software,Vol.22 No.5,pp.30-9.
Ceschi, M., Sillitti, A., Succi, G. and De Panfilis, D. (2005), “Project management in plan-based and
agile companies”,IEEE Software,Vol.22 No.3,pp.21-7.
Chong, J. (2005), “Social behaviors on XP and non-XP teams: a comparative study”, Proceedings
of the Agile Development Conference (ADC’05),pp.39-48.
Cockburn,A. (2001),Agile Software Development,1st ed.,Addison-Wesley,Boston,MA.
Cockburn, A. (2002a), “Learning from agile software development – part one”, CrossTalk: Journal
of Defense Software Engineering,October,available at:www.stsc.hill.af.mil/crosstalk/
2002/10/cockburn.html
Cockburn,A. (2002b),“Learning from agile software development– part two”,CrossTalk:
Journalof Defense Software Engineering,pp. 9-12,available at:www.stsc.hill.af.mil/
crosstalk/2002/11/cockburn.pdf
Cockburn, A. and Highsmith, J. (2001), “Agile software development: the people factor”, Software
Management,November,pp.131-3.
Cohn,M. (2005),Agile Estimating and Planning,Prentice-Hall,Upper Saddle River,NJ.
Cohn, M. and Ford, D. (2003), “Introducing an agile process to an organization”, IEEE Computer,
June,pp.74-8.
Creswell,J.W. (2003),ResearchDesign:Qualitative,Quantitative,and Mixed Methods
Approaches,Sage Publications,Thousand Oaks,CA.
Dagnino,A., Smiley,K., Srikanth,H., Anton,A.I. and Williams,L. (2004),“Experiences in
applying agile software development practices in new product development”, Proceedings
of the 8th IASTED InternationalConference on Software Engineering and Applications,
Cambridge, MA, November 9-11.
Dalcher, D., Benediktsson, O. and Thorbergsson, H. (2005), “Development lifecycle management:
a multi-projectexperiment”,Proceedingsof the 12th InternationalConferenceand
Workshops on the Engineering of Computer-Based Systems (ECBS’05),pp.289-96.
Deias,R.,Mugheddo,G. and Murro,O. (2002),“Introducing agile in a start-up”,available at:
www.agilealliance.org/system/article/file/873/file.pdf (accessed March 4,2007).
Dyba˚, T. and Dingsøyr, T. (2008), “Empirical studies of agile software development: a systematic
review”,Information and Software Technology,Vol.50 Nos 9/10,pp.833-59.
Elssamadisy,A. (2001),“XP on a large project – a developer’s view”,available at:www.xpuni
verse.com/2001/pdfs/EP202.pdf (accessed December 2005).
Fowler,M. (2002),“The agile manifesto:where it came from and where it may go”,available at:
http://martinfowler.com/articles/agileStory.html (accessed December 2005).
Fowler,M. and Highsmith,J. (2001),“The agile manifesto”,Software Development Magazine,
August, availableat: www.sdmagazine.com/documents/s¼844/sdm0108a/0108a.htm
(accessed December 2005).
Highsmith,J. (2004),Agile Project Management,Addison-Wesley,Boston,MA.
Adopting agile
practices
471
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

Jokela,T. and Abrahamsson,P. (2004),“Usability assessmentof an extreme programming
project:close cooperationwith the customerdoes not equal good usability”,
Product-Focused Software ProcessImprovement,Lecture Notesin ComputerScience,
Vol.3009,pp.393-407.
Kalermo,J. and Rissanen,J. (2002),“Agile software developmentin theory and practice”,
Master’s paper, Department of Computer Science and Information Systems, Univer
Jyva¨skyla¨, Jyva¨skyla¨.
Karlstroem,D. and Runeson,P. (2005),“Combining agile methods with stage-gate project
management”,IEEE Software,Vol.22 No.3,pp.43-9.
Larman,C. (2004),Agile and Iterative Development:A Manager’sGuide,Addison-Wesley,
Boston,MA.
Layman,L., Williams,L. and Cunningham,L. (2004),“Exploring extreme programming in
context:an industrialcase study”,Proceedings ofthe Agile DevelopmentConference
(ADC’04),pp.32-41.
Lazaro,M. and Marcos,E. (2005),“Research in software engineering:paradigms and methods”,
Proceedingsof the 1st InternationalWorkshopon PhilosophicalFoundationsof
Information Systems Engineering, Porto, Portugal, June.
McMahon,P.E. (2004),“Bridging agileand traditionaldevelopmentmethods:a project
management perspective”, CrossTalk: The Journal of Defense Software Engineering
availableat: www.stsc.hill.af.mil/crosstalk/2004/05/0405McMahon.html(accessed
December 2005).
Macias,F., Holcombe,M. and Gheorghe,M. (2003),“A formalexperiment comparing extreme
programming with traditionalsoftware construction”,Proceedings ofthe 4th Mexican
IternationalConference on Computer Science (ENC 2003),pp.73-80.
Mahanti,A. (2006),“Challenges in enterprise adoption of agile methods – a survey”,Journalof
Computing and Information Technology,Vol.14 No.3,pp.197-206.
Mann, C. and Maurer, F. (2005), “A case study on the impact of scrum on overtime and
satisfaction”,Proceedings of Agile Development Conference (ADC’05),pp.70-9.
Mannaro,K., Melis,M. and Marchesi,M. (2004),“Empiricalanalysis on the satisfaction of IT
employees comparing XP practices with other software developmentmethodologies”,
Proceedings of Extreme Programming and Agile Processes in Software Engineering
Vol.3092,Springer-Verlag,pp.166-74.
Melnik, G. and Maurer, F. (2002), “Perceptions of agile practices: a student survey”, Proc
of ExtremeProgramming/AgileUniverse2002,LectureNotesin ComputerScience.
Vol.2418,Springer-Verlag,pp.241-50.
Middleton,P. (2001),“Lean software development:two case studies”,Software Quality Journal,
Vol.9 No.4,pp.241-52.
Misra,S.C.(2007),“Adopting agile software developmentpractices:success factors,changes
required,and challenges”,PhD thesis,SprottSchoolof Business,Carleton University,
Ottawa.
Misra,S.C.,Kumar,V. and Kumar,U. (2009),“Identifying some important success factors in
adopting agile software development practices”, Journal of Systems and Software,
No.11,pp.1869-90.
Nerur,S., Mahapatra,R. and Mangalaraj,G. (2005),“Challengesof migrating toagile
methodologies”,Communications of the ACM,Vol.48 No.5,pp.73-8.
IJQRM
27,4
472
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

Newman,W.L. (2005),SocialResearch Methods:Quantitativeand QualitativeApproaches,
Allyn & Bacon,Boston,MA.
Pfleeger,S.L.(1995),“Experimentaldesign and analysis in software engineering”,Annals of
Software Engineering,Vol.1,pp.219-53.
Reifer,D.J.(2002),“How good are agile methods?”,IEEE Software,Vol.19 No.4,pp.16-18.
Robinson, H. and Sharp, H. (2004), “The characteristics of XP teams”, Extreme Programming and
Agile Processes in Software Engineering,Lecture Notes in Computer Science,Vol.3092,
Springer-Verlag,Berlin.
Rumpe,B. and Schroder,A. (2002),“Quantitative survey on extreme programming projects”,
Proceedings of InternationalConference on Extreme Programming and Flexible Processes
in Software Engineering (XP2002), Alghero, Italy, May,pp.95-100.
Salo,O. and Abrahamsson,P. (2008),“Agile methods in European embedded development
organizations: a survey study of extreme programming and scrum”, IET Software, Vol. 2
No.1,pp.58-64.
Schwaber,K. (2004),Agile ProjectManagementwith Scrum,MicrosoftPress,Redmond,
Washington.
Schwaber,K. and Beedle,M. (2002),Agile Software Developmentwith Scrum,Prentice-Hall,
Upper Saddle River,NJ.
Sharp,H. and Robinson,H.(2004),“An ethnographic study of XP practice”,EmpiricalSoftware
Engineering,Vol.9 No.4,pp.353-75.
Shine Technologies (2003),“Agile methodologies:survey results”,Shine Technologies Pty Ltd,
available at:www.shinetech.com (accessed December 2005).
Sillitti,A., Ceschi,M.,Russo,B. and Succi,G. (2005),“Managing uncertainty in requirements:
a survey in documentation-drivenand agile companies”,Proceedingsof the
11th InternationalSoftware Metrics Symposium (METRICS 2005),p.17.
Turner,R. and Boehm,B. (2003),“People factors in software management:lessons from
comparing agile and plan-driven methods”,CrossTalk: The Journalof Defense Software
Engineering,December,pp.4-8.
Wellington,C.A.,Briggs,T. and Girard,C.D.(2005),“Comparison of student experiences with
plan-driven and agile methodologies”,Proceedings of the 35th ASEE/IEEE Frontiers in
Education Conference,pp.T3G18-T3G23.
Williams,L. and Kessler,R. (2002),Overcoming Management Resistance to Pair Programming,
1st ed.,Addison-Wesley Professional,Boston,MA.
Young, S.M., Edwards,H.M., McDonald,S. and Thompson,J.B. (2005),“Personality
characteristics in an XP team:a repertory grid study”,Proceedings of the Human and
SocialFactors of Software Engineering (HSSE), St.Louis, MI, USA,pp.1-7.
Zelkowitz,M.V. and Wallace,D.R.(1998),“Experimentalmodels for validating technology”,
IEEE Computer,Vol.31 No.5,pp.23-31.
Further reading
Ambler, S.W. (2005), “Communication on agile software projects”, available at: www.agilemodeli
ng.com/essays/communication.htm (accessed December 2005).
Dingsoyr,T. and Hansen,G.K. (2004),“Extending agile methods:postmortem reviews as
extended feedback”,Lecture Notes in Computer Science,Vol.2630,pp.4-12.
Adopting agile
practices
473
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

Appendix
Here we present a partial view[9] of the survey questionnaire we used (Figure A1).
Figure A1.
Survey questionnaire
IJQRM
27,4
474
To purchase reprints of this article please e-mail:[e-mail]
Or visit our web site for further details:www.emeraldinsight.com/reprints
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)

This article has been cited by:
1. Kim Dikert, Maria Paasivaara, Casper Lassenius. 2016. Challenges and success factors for la
transformations: A systematic literature review. Journal of Systems and Software 119, 87-10
2. Lise Tordrup Heeager, Jeremy Rose. 2015. Optimising agile development practices for the m
operation: nine heuristics. Empirical Software Engineering 20:6, 1762-1784. [CrossRef]
3. PramodK. Vijayaraghavan,SrikrishnanSundararajan,MarathBhasi.2014.Casestudyon risk
management practice in large offshore-outsourced Agile software projects. IET Software 8:6
[CrossRef]
4. Maria Paasivaara, Benjamin Behm, Casper Lassenius, Minna HallikainenTowards Rapid
Large-Scale XaaS Development at Ericsson: A Case Study 16-25. [CrossRef]
5. Maria Paasivaara, Casper Lassenius, Ville T. Heikkila, Kim Dikert, Christian EngblomIntegrat
Sites into the Lean and Agile Transformation at Ericsson 134-143. [CrossRef]
6. Mohammad D. AL-Tahat, Khaled M. Bataineh. 2012. Statistical Analyses and Modeling
Implementation of Agile Manufacturing Tactics in Industrial Firms. Mathematical Problems in
2012, 1-23. [CrossRef]
Downloaded by UNIVERSITY OF LIVERPOOL At 03:11 27 June 2016 (PT)