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)