Thesis - Agile and Plan-driven Methods Co-existence

Agile and Plan-driven Software
Development Methodologies
Co-existence: a Case Study
A thesis submitted in partial fulfilment of the requirements for
the degree of Master of Project Management
John Paterson (3093545)
School of Property, Construction and Project Management
College of Design and Social Context
RMIT University
Date Submitted: 26th
October 2009

iii
Abstract
Agile methodologies represent the latest attempt to reign in the problems typically
associated with software development: time and cost blowouts, fewer features or functions
delivered than originally specified or incorrect features delivered. These methodologies
operate on the basis that change in a software project is inevitable. Therefore they advocate
the development in an incremental fashion, using many rapid releases to maximise
responsiveness in order to minimise the cost of change in scope or priorities. Opinion on
agile methodologies still divides sections of the information technology industry. Some
characterise agile methodologies as in industry silver bullet, while others characterise them
as a hacker’s charter. Another body of opinion sees agile and plan-driven methodologies as
part of a planning spectrum, quite capable of co-existing within the one organisation.
Despite the differences in opinion, agile methodologies, once considered new, and used in
niche areas, are becoming mainstream as organisations attempt to improve their
development project success rates, replacing previously used plan-driven methodologies.
Little research has been undertaken into how agile methodologies are used within larger
organisations, and how they might be used in conjunction with plan-driven methodologies,
leaving a gap in knowledge in these areas. The objective of this research is to bridge that
gap. To that end, a case study was conducted within the technology section of a large
organisation which had recently started adopting the use of agile methodologies, exploring
their use, benefits, and possible co-existence with plan-driven methodologies. An agile –
plan-driven hybrid methodology is used to describe how the organisation manages to make
both forms of methodology work together. The research concluded that the agile and plan-
driven methodologies can co-exist and in doing so deliver synergies to the development of
software.

iv
Declaration
I certify that except where due acknowledgement has been made, the work is that of the
author alone; the work has not been submitted previously, in whole or in part, to qualify for
any other academic award; the content of the thesis is the result of work which has been
carried out since the official commencement date of the approved research program; and,
any editorial work, paid or unpaid, carried out by a third party is acknowledged.
John Paterson
Full Name Signature Date

v
Permission to Copy
I hereby grant permission to the staff of the RMIT University Library and to the staff and
students of the School of Property, Construction & Project Management – RMIT University
to copy this Minor Thesis in whole or in part without reference to me. This permission covers
only single copies made for study purposes, subject to the normal conditions of
acknowledgement.
John Paterson
Full Name Signature Date

vi
Acknowledgements
This thesis relies on the assistance of many people during its preparation.
Firstly I would like to express my thanks to Doctor Tayyab Maqsood, my thesis supervisor,
for his astute advice, patient direction, and dogged persistence during a process that was
longer than might normally be expected.
To Paul Wilson, thanks for pointing the direction to an organisation with suitable
interviewees. Without your recommendation, I’d never have found such a good source of
data.
To my anonymous interviewees - you know who you are - my thanks for some time in your
busy schedules, and your enlightening conversations. It would be interesting to converse
with you again in a few years to see how your journey with agile methodologies is
progressing.
Thanks to Pete and Kirsty for proofreading a draft version. Any remaining errors are all
mine.
Thanks to my broader family for taking care of my son Simon during school holidays in the
final push to complete. The time freed up to quickly make some really significant advances
was invaluable.
Thank you to Simon for coping with his daddy hogging the computer and not being as
available for fun activities as might normally be the case.
Finally I would like to thank my wife Alison Hunter for her patience and support during the
time that it has taken to research for and write this thesis. It would not have been possible
without her.

vii
TABLE OF CONTENTS
Abstract ..................................................................................................................................................iii

Declaration .............................................................................................................................................iv

Permission to Copy.................................................................................................................................v

Acknowledgements................................................................................................................................vi

List of Figures ......................................................................................................................................viii

List of Tables........................................................................................................................................viii

1
Introduction......................................................................................................................................1

1.1
Background ...............................................................................................................................1

1.2
Rationale / Problem Statement ..............................................................................................1

1.3
Research Objectives..................................................................................................................2

1.4
Research Framework / Conceptual Model ..........................................................................2

1.5
Research Questions ..................................................................................................................3

1.6
Limitations of Research ...........................................................................................................3

1.7
Structure of the Thesis .............................................................................................................3

2
Literature Review...........................................................................................................................4

2.1
A Short History of the Software Development Crisis.........................................................4

2.2
Agile: a Reaction to Heavyweight Methodologies ..............................................................5

2.3
Agile Methodologies: Assumption Analysis........................................................................6

2.4
Agile Critical Success Factors .................................................................................................8

2.5
Agile Methodologies and the Changing Role of the Project Manager .............................9

2.6
Adopting Agile Methodologies into Software Development Organisations ................10

3
Research Methodology................................................................................................................13

3.1
Interview Questions Development ......................................................................................13

3.2
Interviewee Profiles................................................................................................................15

4
Data Analysis ................................................................................................................................16

4.1
Organisation Background..........................................................................................................16

4.2
Agile Adoption Programme Background...........................................................................16

4.3
Case Study Data Summary........................................................................................................17

4.3.1
Agile Methodology Adoption ..............................................................................................17

4.3.2
Agile Project Mechanisms ..................................................................................................18

4.3.3
Agile Adoption Benefits ......................................................................................................22

4.3.4
Agile Adoption Issues..........................................................................................................26

4.3.5
Agile and Plan-driven Methodologies Co-use....................................................................31

4.3.6
Future Methodology Use ....................................................................................................39

5
Discussion and Conclusions...........................................................................................................41

5.1
Discussion..................................................................................................................................41

5.2
Conclusions .............................................................................................................................44

5.3
Further Research.....................................................................................................................45

5.4
Reflection .................................................................................................................................46

References .............................................................................................................................................47

Appendix A – Research Interview Questions ....................................................................................50

Appendix B – Master Theme Map......................................................................................................53

Appendix C – Notes from Interview 1 ................................................................................................63

Appendix D – Notes from Interview 2 ................................................................................................66

Appendix E – Notes from Interview 3 ................................................................................................69

Appendix F – Notes from Interview 4.................................................................................................72

Appendix G – Notes from Interview 5................................................................................................75

viii
Appendix H – Notes from Interview 6 ................................................................................................78

Appendix I – Notes from Interview 7..................................................................................................80

Appendix J – Notes from Interview 8 .................................................................................................82

Appendix K – Notes from Interview 9 ................................................................................................84

Appendix L – Notes from Interview 10...............................................................................................87

Appendix M – Notes from Interview 11..............................................................................................89

List of Figures
Figure 1: Development Methodologies Use...................................................................................... 2

Figure 2: Agile Introduction. Source Adams (2007)....................................................................... 11

Figure 3: Agile Programming. Source Adams (2005) ................................................................... 12

Figure 4: Variation in Support through the Organisation Hierarchy ......................................... 42

Figure 5: Agile - Plan-driven Hybrid Project Model ..................................................................... 43

List of Tables
Table 1: Project Success / Failure Rates. Source Johnson (1994)................................................... 4

Table 2: Agile Manifesto Principles. Source Back et al. (2001) ....................................................... 6

Table 3: Agile Methodologies Critical Success Factors. Source Cao (2006).................................. 8

Table 4: Agile Methodologies Auxiliary Success Factors. Source Cao (2006).............................. 8

Table 5: Agile Methodologies Non-contributory Factors. Source Cao (2006).............................. 9

Table 6: Mapping of Interview Question Groups to Literature ................................................... 14

Table 7: Interviewee Characteristics................................................................................................. 15

Table 8: Agile Project Mechanisms................................................................................................... 18

Table 9: Example Iterative Project Document Review and Approval Matrix............................ 35

Table 10: Project Artefact Interview Reference............................................................................... 36

Table 11: Plan-driven Reporting Mechanisms................................................................................ 38

Table 12: Agile Cycles Within an Agile - Plan-driven Hybrid Project........................................ 44

1
1 Introduction
1.1 Background
Agile software development methodologies1
are new ways of developing software; a new
answer to the problems inherent in developing software. They attempt to eliminate scope
risk by breaking the project down into short cycles, known as iterations, introducing time-
boxing. These methodologies give the promise of delivering value to customers quickly and
completing quicker than more traditional, plan-driven planning-based methodologies. Being
iterative in nature, they represent a complete change to earlier development methods: there
is no work breakdown structure, no Gantt chart, no change control process and potentially
little documentation. For this reason Agile software development methodologies are very
popular with some sections of the software development community who see themselves
freed from the drudgery of process to focus purely on coding.
The introduction and application of agile development methodologies provide challenges to
organisations (Boehm and Turner 2005). They can particularly be an issue for larger
organisations that have used plan-driven methods for software development. The lack of
formal documentation used in the agile methods is but one. Organisations already
successfully delivering software are unlikely to consider the need to adopt them. They are
more likely to be considered and introduced when the projects are not going well
(Abrahamsson et al. 2002).
Agile methods are good at answering questions that require looking back: what has the
project delivered to date; how much has the project cost so far? Due to their iterative, short-
term focus, they are not good at answering forward-looking critical questions that
organisations often require answers for: what is left to deliver, when will the project be
completed, what will the total project cost be?
1.2 Rationale / Problem Statement
While plenty of literature exists on introducing agile methods into organisations, for example
(Angioni et al. 2006, Boehm and Turner 2005, Cohn and Ford 2003, Lycett et al. 2003,
Rasmusson 2003) most of this literature is prescriptive, written by agile methodologies
advocates, or it is theoretical in nature. There is a dearth of knowledge that investigates real-
world organisations and their clients, attempting to make deductions in an analytical,
detached manner based on empirical research. There is a need to establish how
organisations make use of agile methodologies when developing software.
The researcher’s interest in the subject stems from having worked at a number of
organisations that attempted to introduce agile methodologies with varying degrees of
success. Within these organisations, cultural clashes between the agile enthusiasts and plan-
driven project management enthusiasts were a contributing factor to the mixed success.
Support for the different development methods varied within the organisational hierarchy.
Some of the literature suggests that in the future, organisations, particularly larger ones, will
need both agility as well as the rigour of plan-driven methodologies (Boehm and Turner
2004), indicating that there will be a premium on having methodologies available that
combine agility and rigour in ways that can be modified for particular circumstances.
1
The terms methods and methodologies are used interchangeably throughout the literature. This thesis will use the term
methodologies.

2
1.3 Research Objectives
This research project will examine how larger organisations that have taken on agile
methodologies make them work in a context where plan-driven methods of project
management are the norm. Boehm (2002) suggests that aspects of both should be able to co-
exist, and in some circumstances “a combined approach is feasible and preferable”, a view
addressed in more detail in a later publication (Boehm and Turner 2004). Based on this, the
principal objective of this research is to investigate the use of agile methodologies and
establish if agile and plan-driven methodologies can co-exist successfully within a larger
organisation.
To fulfil this objective this research will investigate the various agile methodologies adopted
by the organisation, their method of adoption and any issues created by their adoption. It
will analyse what aspects and techniques within agile and plan-driven methods can work
together. As well, the research will examine how these aspects and techniques are made to
work together, and what obstacles needed to be overcome in order to agile and plan-driven
methodologies to co-exist within an organisation.
1.4 Research Framework / Conceptual Model
Some software development organisations will continue to embrace plan-driven software
development methodologies. Others will take on the newer agile development
methodologies. Still others will use aspects of both to manage software development. In
Figure 1 organisations X, Y and Z denote the types of organisation that use both to varying
degrees. It is these types of software development organisations that the research will
examine, using the research objectives.
Figure 1: Development Methodologies Use

3
1.5 Research Questions
Stemming from the research framework and objectives, the main research question is: what
methodologies are in use within a large organisation? Can these agile methodologies and
plan-driven development methodologies work together within the one organisation? What
obstacles need to be overcome for the two styles of methodology to co-exist? How does
support for plan-driven and agile methodologies vary across the hierarchy of the
organisation? What are the clients’ reactions to the use of agile methodologies? Do agile
methodologies give the clients increased acceptance of and satisfaction with software
development and its outcomes?
1.6 Limitations of Research
Due to time constraints this research did not follow software projects in real time. This
excluded the possibility of performing experiments using multiple projects. It also excluded
the possibility of conducting a longitudinal study. The time constraints limited the research
to what could be observed in a case study of a single organisation.
1.7 Structure of the Thesis
The thesis follows a commonly used five section structure (Perry 1998). Section 1 contains
introductory material: the background, a problem statement, the research objectives, a
research framework, research questions, research limitations and a description of the thesis
structure. Section 2 contains a review of literature pertaining to the research problem.
Section3 describes the methodology used to gather, analysis and subsequently report data.
Section 4 presents an analysis of the data gathered. Section 5 summarises the data analysis,
draws some conclusions, recommends some further research and shows a reflection by the
researcher.
Following the five main discussion sections is a reference section followed by a series of
appendices which contain the questions used in interviews, a master theme map and notes
from the interviews held.

4
2 Literature Review
2.1 A Short History of the Software Development Crisis
Software first appeared as a distinct technology in its own right, separate from the hardware,
creating independent products and using specialised skills in the 1950s. The original
programmers, usually mathematicians or hardware engineers, used the ad-hoc techniques of
their earlier careers (Rajlich 2006).
Attempts in the 1960’s to scale up these ad-hoc techniques onto large scale projects did not
work. A new discipline of software engineering was created to deal with the resulting
‘software crisis’. With it came waterfall2
methodologies (Royce 1970). These required each
phase of the project to be completed before the next phase begins. Other formal
methodologies: requirements gathering, designing and developing software and testing
were also introduced to address the software development problems. All these new
processes, driven by up-front planning, worked well in some projects, but not all. Plan-
driven methodologies froze requirements during system development, making system
development easier (Rajlich 2006), but it also made for overall inflexibility if circumstances
changed.
While plan-driven methodologies made for some improvement, failure rates remained high.
In the late 1908s and early 1990s various project management methodologies were
introduced in an attempt to improve software development project success rates. Case
studies were conducted to examine their effectiveness (Raz 1993). No one software
development methodology was suitable for all conceivable situations (Turk et al. 2005).
Despite this, methodologists, often large consultancies, promoted their one-size-fits-all
methodologies which purported to offer ‘the solution’. These methodologies were big on
process and documentation, becoming known in some circles as heavyweight (Henderson-
Sellers and Serour 2005).The introduction of heavyweight processes did not resolve the
software development crisis. Various researchers (Dalcher and Benediktsson 2006, Damian
and Chisan 2006, Erickson et al. 2005, Little 2006, Rajlich 2006) cite either the 1994 or 2000
edition of the CHAOS report, summarising research into software development failure rates
and costs (Johnson 1994, Johnson 2000). Results from the 1994 CHAOS report can be
summarised:
Table 1: Project Success / Failure Rates. Source Johnson (1994)
Software Project Result % of Projects
Success 16.2 %
Challenged 52.7%
Cancelled 31.1%
Success was defined as the project finishing on time and budget, with all originally specified
features and functions included. Challenged projects are those that were completed but over
time, over budget or with fewer features and functions than initially specified. Cancelled
projects never completed. From the perspective of the CHAOS report, cancelled and
challenged projects failed.
2
It should be pointed out that Royce never used the term waterfall in his paper. The term plan-driven, as used by
Boehm and Turner (2004) will instead be used throughout this thesis.

5
In 1995, failed IT projects cost American organisations $81 billion US, with an additional $59
billion overspent on challenged projects. There has been marginal improvement since. The
2000 CHAOS report shows that in 1998, failed projects cost of $75 billion and 20% of software
development projects finished on time relative to their original plan. All these failures have
various causes.
Lindstrom and Jeffries (2004) identified the major causes of software project failures as being:
• Requirements were not clearly communicated
• Requirements and subsequent software did not solve the business problem
• Requirements changed prior to project completion
• Software was not fully tested prior to release
• Software was not being tested as the user uses it
• Software was developed in a way that is difficult to modify
• Software was used for functions for which it was not intended
• Projects were not staffed with the resources required in the project plan
• Schedule and scope commitments were made prior to fully understanding the
requirements and technical risks
With the coming of the internet, the pace of change in the software industry accelerated.
Often business volatility forced late requirements changes (Rajlich 2006). Rapid changes in
business requirements do not suit waterfall process software development (Nerur et al.
2005). More often of late, companies need to develop high quality software at ‘internet
speed’. Constraints of these projects can include: a desperate rush to market, a new and
unique software market environment and a lack of experience developing software in the
conditions the market imposes (Baskerville et al. 2003).
2.2 Agile: a Reaction to Heavyweight Methodologies
Starting in the mid 1990s some developers began reacting against the heavyweight processes,
creating development methodologies that saw success coming more through communication
and people and less through ‘burdensome’ processes (Lindstrom and Jeffries 2004). The new
methodologies assume that all the requirements cannot be known at the outset, and that the
proper way to build timely, quality software in a cost effective manner is to build flexibility
into the development activities (Germain and Robillard 2005). This culminated with the
creation in 2001, by a number of leading, like-minded developers, of the Agile Manifesto:
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
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.
(Beck et al. 2001).

6
With the publication of the manifesto, these new methodologies became collectively known
as agile methodologies; their proponents referred to as agilists. Agile methodologies are a
fundamental departure from previous methodologies and seen by some as a completely new
paradigm (Abrahamsson et al. 2002, Rajlich 2006). The number of agile methodologies is
growing rapidly; many now exist. Of the methodologies eXtreme Programming, XP, (Beck
2000, Beck et al. 1999) is widely acknowledged as the starting point for the various Agile
methodologies (Abrahamsson et al. 2002) and is the most pervasive (Lindstrom and Jeffries
2004).
All the agile methodologies have a common set of core principles (McAvoy and Sammon
2005). These core principles are drawn from the twelve principles of the manifesto.
Table 2: Agile Manifesto Principles. Source Back et al. (2001)
1. Satisfy the customer through early and frequent delivery of software.
2. Welcome changing requirements even late in the project.
3. Keep delivery cycles short, from fortnightly to quarterly, with shorter cycles preferred.
4. Customers and developers must work together daily throughout the project.
5. Build projects around motivated individuals, and let them get on with the job.
6. Face-to-face conversation is the best method of conveying information.
7. The primary measure of progress is working software.
8. Promote a sustainable development pace.
9. Pay continuous attention to technical excellence and good design.
10. Simplicity, the art of maximizing the amount of work not done, is essential.
11. Self organising teams create the best results.
12. The team regularly reflects on how to improve, and adjusts its behaviour accordingly.
2.3 Agile Methodologies: Assumption Analysis
The agile manifesto’s principles are derived from a set of assumptions. Agile methodologies
are less likely to be applicable in situations in which the core assumptions do not hold, due
to the limitations they lead to (Turk et al. 2005).
A principle core assumption of agile methodologies is that the cost of change over the life of
the project can be made linear rather than exponential, as was assumed with waterfall
methodologies.
“This is one of the premises of XP. It is the technical premise of XP. If the cost of change rose
slowly over time, you would act completely differently from how you do under the assumption
that costs rise exponentially.” (Beck 2000)

7
This assumption provides the justification for developing software in an incremental fashion
with many rapid releases. As yet there is no empirical evidence that this assumption is valid
(Turk et al. 2005). For that matter, in some cases having an incremental development cycle is
seen as leading to an unpredictable project scope (Turk et al. 2005).
Each incremental cycle of software release carries with it a non-coding effort overhead. As
the cycle length decreases, and the project potentially more responsive to customer
requirements change, the total proportion of non-coding effort increases. There is little
research on modelling, planning and controlling incremental development. Some work has
been done to determine the optimum number of development cycles, allowing for the costs
of cycle overheads, (Benediktsson and Dalcher 2004), but further empirical research is
needed to confirm the preliminary postulated formulations.
With each development cycle releasing working software, agile methodologies can be seen as
reducing the time for development with a fixed sized team. Many development projects
have fixed time and effort constraints, effectively removing some of the trade-offs that a
project manager normally has. Time and effort constraining has implications which are
largely unstudied (Dalcher and Benediktsson 2006). Dalcher and Benediktsson indicate that
more work is needed to determine the relationship between incremental delivery and team
size.
The members of a team are a critical aspect to agile methodologies. There is no such thing as
an all-purpose system developer, and developer skill levels vary immensely. Getting the
right people on the team improves the chances of project success (Howard 2001). There is, as
yet, no evidence to suggest that agile methodologies will work in the absence of competent
and above average people (Nerur et al. 2005). This leads to potential resourcing problems.
As Boehm (2002) points out: “a significant consideration here is the unavoidable statistic that
49.9999 percent of the world’s software developers are below average.” There is also the
possibility that a culture of elitism may develop within the agile teams affecting the morale
of non-agile teams within the same organisation.
The availability of on-site customers, usually in the same room as the developers, is another
key assumption of agile methodologies (Baskerville et al. 2003, Turk et al. 2005). A dedicated
customer resource on a project can be a large expense to some organisations. Critics view
on-site customers as generally being junior, thus lacking in experience (Nord and Tomayko
2006). Also, by the very nature of being with the development team, the on-site customer
representative can sometimes be removed from users’ and other stakeholders’ requirements.
While the customer needs to be co-located, an initial studies indicate that they are only
required by the agile development team about 21% of the time, so could also be working on
other tasks (Koskela and Abrahamsson 2004).
To date projects developed using agile methodologies have tended to be small. There is
significant debate as to the scalability of these methodologies (Henderson-Sellers and Serour
2005). The requirement to have the team co-located would suggest that there is limited
support for using external subcontractors or for distributed development environments
(Turk et al. 2005).

8
Recent debate centres on the application of agile methodologies to global software
development, GSD. In this situation the team is geographically dispersed, rather than in the
same room, which is an agile requirement. This makes face-to-face communication between
team members and with the customer representation more difficult.
Some companies are attempting to use Agile methodologies within the global software
development framework (Armour 2007) and preliminary results suggest that in fact some
aspects of agile methodologies may be more amenable to global software development than
previously thought, with a reduction in “temporal, geographical and sociocultural distances”
(Holmström et al. 2006). Another study concluded that agile methodologies are essential to
addressing challenges to communication, control, and trust in distributed teams
(Balasubramaniam et al. 2006). To others, the application of agile methodologies to global
software development does not answer the communication problems inherent with teams
that are not co-located (Parnas 2006).
2.4 Agile Critical Success Factors
Some preliminary research has been done on the critical success factors in agile projects (Cao
2006). This was a survey of Agile practitioners in 109 Agile projects across 25 countries. The
results are summarised in the tables below. Table 3 maps critical success factors for Agile
methodologies against Agile Manifesto Principles and also Agile practices.
Table 3: Agile Methodologies Critical Success Factors. Source Cao (2006)
Critical Success Factors Manifesto
Principles
Agile Practices
Delivery Strategy 1, 3 Continuous delivery of valuable, working
software in short time scales.
Agile Software
Engineering Practices
9, 10 Continuous attention to technical excellence and
simple design.
Team Capability 5 Building projects around motivated individuals.
A number of auxiliary success factors were identified. Table 4 shows the mapping of
auxiliary success factors to Manifesto Principles and Practices.
Table 4: Agile Methodologies Auxiliary Success Factors. Source Cao (2006)
Auxiliary Success
Factors
Manifesto
Principles
Agile Practices
Project Management
Process
6, 8 Face to face conversation within the team, and
sustaining a constant pace.
Team Environment 11 Having a self-organising team.
Customer Involvement 1, 4 Satisfying the customer and having business
people working closely with developers.

9
By inference there are a number of agile Manifesto principles that would not appear to be
success factors, critical or auxiliary, for Agile Methodologies. These are summarised in Table
5.
Table 5: Agile Methodologies Non-contributory Factors. Source Cao (2006)
Manifesto
Principles
Description
2 Welcoming changing requirements even late in the project.
7 The primary measure of progress is working software
12 The team regularly reflects on how to improve, and adjusts its behaviour
accordingly.
2.5 Agile Methodologies and the Changing Role of the Project Manager
Agile software development methodologies are very popular with some sections of the
software development community who see themselves freed from the drudgery of process to
focus purely on coding. They are however an anathema to some plan-driven project
managers who with Agile no longer control the software development project and process.
Views differ on what roles the project manager now plays. They are now:
• Team historians and communicators (Beck 2000)
• Progress trackers (Angioni et al. 2006)
• Adaptive leaders, setting direction, establishing simple rules for the system, and
encouraging constant feedback, adaptation, and collaboration (Augustine et al. 2005)
• Trackers and coaches (Abrahamsson et al. 2002)
Interestingly, Augustine et al. (2005) notes that project managers invariably tend to revert
back to plan-driven methodologies in an attempt to reduce increasing volatility.

10
2.6 Adopting Agile Methodologies into Software Development
Organisations
The adoption of agile methodologies has not necessarily been widespread, particularly with
larger organisations. A 2004 workshop held at The University of Southern California Centre
for Software Engineering held a workshop in 2004 on the adoption of agile methodologies. It
indicated that some large aerospace, manufacturing and IT companies have begun
experimenting with agile methodologies. Early adopters have trialled agile methodologies
in small pilot programs, applying them to isolated or possibly failing projects. These have
met with success; however the companies have only been able to minimally extend agile
methodologies deployment (Boehm and Turner 2005).
Given that agile methodologies represent a paradigm shift, successful implementation
requires a complete overhaul of the way the development organisation works. These
changes do not affect just the development team (Cohn and Ford 2003). Organisational
changes need to be made to: fundamental assumptions, control mechanisms, management
style, knowledge management, role assignment, communication, customer’s role,
development model, defined organisational structure and technologies in order for the
implementation to be a success (Nerur et al. 2005). Implementation brings with it many
challenges in terms of: development process conflicts, business process conflict and people
conflicts (Boehm and Turner 2005).
The change to using agile methodologies is therefore not to be considered lightly. Nerur et
al. (2005) citing Boehm (2002) notes: “While the opportunities and benefits that agile
methodologies afford make them attractive, organisations should be circumspect in
embracing them or in integrating them with existing practices.” Organisations which can
successfully deliver software are unlikely to consider the need to adopt agile methodologies.
They are more likely to be considered and introduced when the projects are not going well
(Abrahamsson et al. 2002).
However, Agile project managers and coaches should not be concerned when introducing
Agile methods to an organisation where Agile is completely foreign (Cao 2006). Cao’s study
suggests that those ‘introductory’ Agile projects have a better probability of success than
those Agile projects carried out in more Agile methodology aware organisations.
It can be argued that there is no such thing as a universal development methodology
(Germain and Robillard 2005). The list of agile methodologies is still growing. Each has
their own defined niche, and it may not be possible to transfer methodologies from one
project to another. This could lead to adverse knowledge transfer implications for
organisations running multiple projects (Abrahamsson et al. 2003). Choosing the
appropriate agile methodology from all those available may be the biggest problem for
organisations (Nerur et al. 2005). This is particularly the case as the methodologies used to
determine which methodologies are appropriate are still inadequate (Lindstrom and Jeffries
2004). Some initial work has been done in creating agile adoption assessment matrices
(McAvoy and Sammon 2005) but these only assist with determining if an agile methodology
should be used, and not which one.

11
Interestingly, McAvoy and Sammon’s study discovered that managers were more optimistic
and positive about the adoption of agile methodologies than software developers. This is the
reverse of what might normally be presumed given that agile methodologies are a move
away from rigid management towards increased empowerment and trust in the developers,
giving them more flexibility in how they work. This optimism is captured in a Dilbert
cartoon. (Adams 2007)
Figure 2: Agile Introduction. Source Adams (2007)
While agile methodologies offer flexibility and responsiveness to developers, the
methodologies themselves are static, offering little or no support for large scale software
process improvement (Alshayeb and Li 2005). Software process improvement is needed
within organisations to develop organisational maturity over time (Börjesson and
Mathiassen 2005). A potential way forward is to use methodology engineering approaches,
supporting intra-project and inter-project flexibility (Henderson-Sellers and Serour 2005).
An organisation would create a repository of agile methodology fragments, and then for
each project select the methodology fragments most appropriate. Studies have produced
mixed results. One longitudinal study shows that software process improvement can be
difficult and needs to be agile in nature in order for organisations to respond to changed
circumstances (Börjesson and Mathiassen 2005); however another study indicates that
method tailoring can be implemented successfully (Fitzgerald et al. 2006).
The arrival of agile software development methodologies created controversy, dividing the
software development community into two: the agilists and traditionalists. Each group
proclaims the superiority of their methodologies (Nerur et al. 2005). Agilists are extremely
vocal as to the apparent benefits of agile methodologies (Erickson et al. 2005). The old guard
traditionalists, with their credentials tied to the old plan-driven waterfall methodologies, are
resistant to paradigm change (Rajlich 2006). Discussions on agile methodologies in both
industry and academia can degenerate into arguments between the agilists and
traditionalists (McAvoy and Sammon 2005). Some see agile methodologies as a silver bullet3
,
while others see them as a hackers’ charter (Cowham and Stephens 2005), a view elegantly
captured by in the satirical Dilbert cartoon below. (Adams 2005)
3
It should be pointed out that it is considered a gospel truth within the Information Technology industry that
there is no such thing as a silver bullet (Brooks, 1986), (Brooks, 1995).

12
Figure 3: Agile Programming. Source Adams (2005)
Others take the view that both agile and plan-driven approaches have a responsible centre
and form part of the planning spectrum. They recommend a combined approach (Boehm
2002, Boehm and Turner 2004). Is should be noted that there is little or no research available
that explores how agile methodologies relate to improving the organisation’s capability to
develop quality software (Börjesson and Mathiassen 2005).
Meanwhile, agile methodologies continue to migrate into traditional development
organisations. Some research, a longitudinal study, has examined the introduction of agile
methodologies into a smaller organisation (Mann 2005). The organisation studied was a
software development company with fewer than eight software development staff. There is
a dearth if literature examining the introduction of agile methodologies into larger
organisations. For the purposes of this research, a larger organisation is defined as one in
which there is a dedicated in-house software development department running a number of
concurrent projects. This department will be sufficiently mature enough to have used formal
project management techniques, for example: Gantt charts, work breakdown structures, risk
registers, in the past. More research is needed to examine new approaches to
implementation and harmonising with the existing organisational environment.

13
3 Research Methodology
Due to time constraints this research did not follow software projects in real time. These
constraints limited the research to what could be observed in a case study. The case study
examined and analysed a larger organisation that was using agile methodologies, and
identified traits that can be used to develop hypotheses in follow-up studies by other
researchers (Yin 2003). Case studies have been used in the past to examine aspects of agile
methodologies within organisations (Layman et al. 2004).
The earlier-mentioned time constraints precluded various forms of research which would
have required lengthy data gathering such as experiments. This research explored the
possibilities of agile and plan-driven development methodologies co-existing. It was
conducted as a single-case design case study. Yin (2003, pp. 1-14) forcefully agues that case
studies are a legitimate formal research method, particularly for exploratory research.
Interviews are a flexible and adaptable means of information gathering. The bias of the
researcher can be difficult to eliminate (Robson 2002), but, done well, interviews have the
ability to provide high-quality, interesting data. Semi-structured interviews with a mix of
specific and open-ended questions can elicit unexpected types of information (Layman et al.
2004).
The case study consisted of semi-structured interviews within the software development
department of a larger organisation that has used plan-driven project management
methodologies in the past. Robson (2002, pp. 270-271) notes that in semi-structured
interviews there are predetermined questions, but these can be modified based on the
interviewer’s perceptions of appropriateness. They are used in flexible, qualitative designs,
either as the sole information source, or in conjunction with our information sources (ibid, p.
278). Within the department in the case study 11 key personnel were interviewed.
These key personnel had different levels of responsibility, varying from senior developers
through to management. It is expected that the senior developers are likely to be more
amenable or biased towards the use of agile methodologies. Their managers, who have to
deal with the broader business, are likely to have the need for a broader tool-set than what
agile methodologies deliver. Hence it is likely they will use aspects of the more plan-driven
methodologies as well.
The interviews were recorded and the recordings transcribed / converted into text. Data
drawn from the interviews in the case study was collated and analysed to determine
common themes and draw conclusions.
3.1 Interview Questions Development
To provide some structure to the interview, broad question groups were determined. These
groups were designed to elicit information across broad areas of the research being
undertaken. The question groups created appear on the next page.

14
Question Groups
1. Background
1.1 Organisation Background
1.2 Interviewee Background
2. Introduction of Agile Methodologies
2.1 Organisation History
2.2 Organisation Current Situation
3. Retention / reintroduction of Plan-driven Methodologies
4. Co-use of both methodology types
5. Client Experience
6. Agile Tools / Mechanisms
Questions posed in the interviews have a strong grounding in literature. Table 6 below
provides a map of question groups to literature links. Appendix A contains details of the
Research Interview Questions based on the above question groups.
Table 6: Mapping of Interview Question Groups to Literature
Question Groups Related Literature
1. Background (Yin 2003).
2. Introduction of Agile Methodologies (Boehm 2002)
(Boehm and Turner 2005)
(Cohn and Ford 2003)
2.1 Organisation History (Nerur et al. 2005)
(Cao 2006)
2.2 Organisation Current Situation (Boehm and Turner 2005)
3. Retention / Reintroduction of Plan-driven
Methodologies
(Augustine et al. 2005)
4. Co-use of both methodology types (Boehm and Turner 2004)
5. Client Experience (Abrahamsson et al. 2002)
(Cao 2006)
6. Agile Tools / Mechanisms (Abrahamsson et al. 2003)
(Lindstrom and Jeffries 2004)

15
3.2 Interviewee Profiles
Eleven people in total were interviewed. Interviews ranged in duration from under an hour
to an hour and a half. Table 7 summarises some characteristics of interviewees:
• Position within the organisation
• The length of experience with agile methodologies
• An indication of project size
Table 7: Interviewee Characteristics
Interviewee Position Title Years Agile
Experience
Project Size4
($ Millions)
1 Test Manager 3 .2 - 2
2 Project Manager 3 .2 - 2
3 Development Lead 2 2.5
4 Development Manager / Solution Architect 3 .2 - 2
5 Development Lead / Technical Specialist 1 1 - 5
6 Project Director 185
50
7 Project Manager 1.5 2 - 5
8 Project Manager 1 <5
9 Development Manager 7 <5
10 Senior Software Developer 4.5 4
11 Development Lead 1.5 2
Neither developers nor representatives from upper management were available for
interviewing. This limited the vertical spread of first-hand experiences and opinions within
the organisation hierarchy. Some inferences of these experiences and opinions can be drawn
from the interviewees’ observations.
Content analysis is a method of identifying, and analysing occurrences of specific messages
and message characteristics within texts (Frey et al. 2000). Qualitative content analysis was
used to identify and analyse the occurrences of themes within the interview transcripts.
Themes were identified within each of the transcripts. These were categorised into ordered
notes that can be found in Appendices C – M. The notes were further summarised into a
theme map table, which lists the various themes and which interviewees discussed them.
The theme map table can be found in Appendix B.
4
The project size column is merely an indication of order of project magnitude rather than a precise project
budget figure.
5
The length of agile experience noted here predates the use of the term agile as used for software development;
however the techniques and processes described in the interview fall well within purview of agile methodologies.

16
4 Data Analysis
4.1 Organisation Background
The organisation to which the interviewees all belong is a large Australian division of a
financial services company, and shall be referred to throughout this document as “the
organisation”. It has 2,500 employees in Australia, New Zealand, the United Kingdom and
the United States. The company provides funding, risk management and investment
solutions to large corporate clients around the globe. It is involved in capital markets and
foreign exchange trading. In order to improve its competitiveness the organisation invests
heavily in technology thus improving productivity and increasing economies of scale.
The Information Technology group of the organisation is a large component, with between
500 to 1,000 people associated with system development activities. It supports about thirty
different primary data repository systems, along with associated middleware to buffer
messages between systems and data warehouses. The clients of the Information Technology
division are all internal, business sections of the organisation.
Because the organisation being studied is part of a financial services company, Australian
federal government legislation requires that the Australian Prudential Regulatory Authority,
APRA, prudential regulator of the Australian financial services industry, supervises the
organisation’s activities. Part of this supervision is done through requiring external auditing
of the organisation’s activities. This includes external auditing of development projects to
ensure that proper project governance is taking place.
4.2 Agile Adoption Programme Background
Agile methodologies were introduced across the organisation about eighteen months ago at
the behest of the then new Chief Information Officer, CIO, who introduced an Agile
Capability program. There was a view that the development process across the organisation
was broken6
. Requirement turnaround was slow. Projects were running late and over
budget; those that delivered on time and on budget were seen as rare. There were significant
quality issues, with a high number of production issues. Agile methodologies were seen as a
way to improve the whole development process, including quality.
It should be noted that four interviewees reported that one development team started
successfully using agile methodologies two years before the official agile adoption
programme commenced. An incoming practice manager was willing to expand the use of
agile methodologies to other teams. In one interviewee’s mind this pilot provided the
impetus for the wider adoption programme.
To expedite the adoption of agile methodologies the CIO brought in a core executive team
who had been associated with agile methodologies outside the company. Agile
methodologies were championed by the CIO and the executive team, with their adoption
being promoted to the technical development teams, i.e. from the bottom of the organisation
up, with some, but not total success.
6
So broken in fact that one interviewee referred to an apocryphal rumour that the organisation had considered outsourcing
their entire IT function, to be prevented by government regulatory issues, and that agile methodologies were considered after
that. There was no other mention of this rumour from other interviewees.

17
While many teams were encouraged to adopt agile methodologies, not all were able to do so.
In fact, at least one higher-risk project was excluded from the agile adoption programme.
The current situation was described by one interviewee as being: “… islands of people who are
very committed to Agile and able to deliver very well using Agile, in a sea of still waterfall.”
Funding for the agile adoption programme was available for about six months before drying
up. One interviewee attributed this to another change in CIO and subsequent management
restructure. The new CIO has other priorities, focussing on the management of people,
ensuring there is a good set of leaders, rather than how projects are delivered, so the push for
change from the upper levels of the organisation appears to have gone. In the view of one
interviewee: “official agile transformation is dead.” In part this may be due to the introduction
of agile methodologies being seen as something political within the organisation and hence
divisive. In the view of another interviewee, project management is “back to plan-driven”;
however, there does not seem to be any push for those teams within the organisation that
have adopted agile methodologies to drop them. Indeed, according to one interviewee,
training is still available for teams wishing to adopt methodologies, and there is an in-house
project management tool being developed which will accommodate either plan-driven or
agile workflows.
4.3 Case Study Data Summary
4.3.1 Agile Methodology Adoption
External consultants from ThoughtWorks7
, versed in agile methodologies, were brought into
the organisation as part of the official adoption programme. In conjunction with the
software development competency group they devised an agile competency program. Much
of their time was spent with teams in the process of adopting agile methodologies. They
acted as coaches, providing training in and assisting with various agile activities as the teams
familiarised themselves with developing software in an agile manner. Experience of the
coaches was mixed. One interviewee lamented that the coaches were not able to answer
some difficult questions their team was attempting to deal with.
The consultants brought with them the agile methodology with which they were familiar. A
version of Open Unified Process8
, OpenUP, an open-source version of Rational Unified
Process9
, was localised. This was made available across the technology group. In the view
of one project manager interviewee it was adapted in order to provide traceability, and be
repeatable. There was also a need to accommodate the reporting requirements of internal
process compliance audits as well as external audits.
There is an indication that not all teams which adopted agile methodologies are using
localised OpenUP. A number of interviewees from the one team referred to their team using
XP / Lean Software Development and Test Driven Development instead. They reported
knowing of another team using Scrum.
7
ThoughtWorks is a global IT consultancy specialises in agile methodologies, as well as delivering systems.
8
Open Unified Process is a part of the Eclipse Process Framework developed within the Eclipse Foundation
(Eclipse, 2008).
9
Rational Unified Process, RUP, an iterative software development process, was created by Rational Software
which is now a division of IBM. It was first described in 1999 (Jacobson, Brooch and Rumbaugh, 1999).

18
Adoption of agile methodologies was not universal; however at the end of the adoption
programme more teams are using agile methodologies. One interviewee described the
current situation within the organisation as having some pockets of agile, with other areas
viewing it with distrust, while some have no understanding of agile methodologies at all.
Of those teams that have adopted the localised agile methodology, there were varying levels
of maturity. Some teams are quite mature with their use of agile methodologies, although
one interviewee suggested that this is seen as something rare at the moment. Other teams
are viewed as only paying lip service to the principles, with a broad spectrum of maturity
between these two extremes. In one interviewee’s mind it seems that younger teams are
more amenable to adopting agile methodologies.
4.3.2 Agile Project Mechanisms
Agile methodologies use a number of mechanisms: tools, meetings and techniques in order
to run smoothly and achieve project aims. Some are not unique to agile methodologies, and
most are not new. Most are common sense. As put by interviewee: “I think the only thing that
I’ve started to come to a realisation is that the processes basically facilitate what I would describe as
commonsense activities.” Put more simply by another interviewee: “… most of Agile is just
common sense. It’s nothing revolutionary.” This section summarises the mechanisms used by
interviewees when conducting agile projects in table 8 and subsequently examines them in
more detail.
Table 8: Agile Project Mechanisms
Mechanism Type Function
Build indicator light Tool Displays status of current software build: working
or broken
Continuous integration Practice Uncover problems as soon as possible
Continuous integration
tools
Tool Continuous system building
Instant messaging Tool Communication with distant client
Kick-off meeting Meeting Set project / phase / release direction and goals
Mingle Tool Agile Project Management
Planning games Meeting Iteration planning – start of iteration
Planning poker Tool Adjunct to planning game
Quality Centre Tool Automated testing tool – functional testing
Quick Test Pro Tool Automated testing tool
Refactoring Practice Making more easily understood code
Retrospectives Meeting Team improvement – end of iteration
Share Point Tool Information Repository

19
Mechanism Type Function
Showcases Meeting Demonstrated completed stories – end of iteration
Spreadsheets Tool Story repository, progress tracking
Stand-ups Meeting Daily information sharing
Stories Tool Small functional requirements adding value
Story Board / Wall Tool Story Repository
Team Play Tool Collecting of timesheet data
Test Driven Development Practice Writing tests for new code before writing code
Video Conference Tool Communicate with distant clients
Visio Tool Story requirements, timeline, assignments
4.3.2.1 Stories, Story Boards / Walls and Other Information Repositories
The use of stories is central to agile methodologies. Almost all interviewees made direct
reference to their use. A story is a business functional requirement, with enough detail to
write onto an index card and no more. Stories must be business-oriented, testable and
estimable (Beck et al. 1999)
For many of the interviewees, the story board or story wall10
, an office wall covered with
story index cards, is seen as the primary agile methodologies tool. It provides a visual
means, easily accessible to all in the project, of showing the status of each story requirement
for the system being developed: completed, in progress or awaiting development. In an
appreciation of story cards, one interviewee described their use as: “Very tactile, the team is
quite comfortable and likes … working with cards that they can just scribble on and draw on.”
The team of another interviewee used Microsoft Visio as an alternative tool for capturing and
displaying information. Visio diagrams were posted onto a wall in the team space where the
team hold their daily stand-up meetings. In this case the diagrams showed a timeline,
deliverables and deliverable assignees.
A project manager interviewee’s team, working on a high-risk project was required by senior
management to show evidence of the project’s requirements up front. Their solution for this
was innovative: they wrote the acceptance test cases first, using these as effective functional
requirements. This was deemed superior to producing written documentation that quickly
became obsolete. Other teams included acceptance test details in the story definitions.
For the teams of a number of interviewees a Share Point repository acts as a single source of
electronic project information. The repository contains spreadsheets, story lists, reports for
project control boards, etc. Wikis are also used to store common knowledge.
10
The terms story board and story wall are interchangeable.

20
4.3.2.2 Mingle
Mingle11
, an agile project management tool, is starting to replace the use of story boards for
some teams, although it does not yet enjoy widespread use. It contains a virtual story wall,
acceptance criteria, requirements test cases and to a lesser degree, planning information.
Mingle also contains reporting facilities which provide progress and budget details. In the
view of one development lead, Mingle allows project managers to communicate with their
peers and the project control board, while still relating to the storyboard. In their view it is a
good crossover tool, giving project visibility to all.
This view is not universal. Another team have stopped using Mingle and reverted to using
the story wall. Their view was that Mingle did not allow for the input of capturing complex
story requirement details. The formatting and management of stories was not ideal. It was
seen as being good for requirements relating to user interfaces, which are relatively simple.
For this team’s system the user interface is just a small part. A great deal of back-end
processing takes place, using complex rules and calculations that cannot easily be entered
into Mingle.
One interviewee saw Mingle as being difficult to extract information that allows scheduling
and task tracking, something they require from a project management tool. Mingle also has
no financial reporting capability. This team instead uses Excel spreadsheets for progress
tracking and reporting. The spreadsheets contain lists of stories, statuses and a calendar of
staff availability. It can be used to determine the expected amount of work that can be
achieved in an iteration.
4.3.2.3 Development Practices
The use of agile methodologies brought in new development practices. Interviewees
referred to refactoring, Test-driven Development, continuous integration and automated
testing. All of these are aimed at improving quality. Their use is described in this section.
Refactoring is an activity whose aim is to improve the internal structure of the code in a
system, without altering the code’s business behaviour (Fowler 1999). Refactoring makes the
code easier to understand and modify. Normally refactoring would be done on an as needs
basis; however one interviewee’s team included refactoring iterations into their work
schedule. In these iterations the priorities were determined by which code needed
refactoring.
Three interviewees reported that their teams use Test-driven Development, TDD, as a coding
practice. To develop a change using TDD first requires the developer to write an automated
test case that fails, which defines the behaviour required by the change. Then the developer
writes code to make the test case pass. Finally, the code is refactored to acceptable standards.
TDD is attributed with encouraging simple designs and inspiring confidence in the code that
is produced (Beck 2003). Empirical research demonstrates that TDD can improve software
design quality while reducing defects at minimal cost (Janzen 2006).
11
Mingle, an agile project management and collaboration tool, was developed by ThoughtWorks.

21
Continuous integration is a practice in which each member of the team integrates their work
frequently, at least daily, into a single code source repository. An automated build process
verifies that the integrated code does not give errors. A number of interviews explicitly
referred to their teams using continuous integration; however given that the practice is
essential to agile methodologies, most likely it would be used by the teams of all
interviewees. One interviewee reported that their team has a build light, a visible indicator
of the build status, enabling quick identification and rectification if code recently integrated
has broken the build.
Automated testing is an essential part of continuous integration. Three interviewees
reported that their teams use Quality Centre12
to manage their automated tests. Another
interviewee’s team uses Quick Test Pro13
.
Interestingly, one aspect of various agile methodologies, that of having programmers
develop code in pairs, does not seem to used. Instead, one development lead reported that
code is being formally reviewed prior to being handed over for QA testing. Another
indicated that developing code in pairs only happened when particularly complex sections
of code were being written, and then this was done to share the knowledge.
4.3.2.4 Meetings
The adoption of agile methodologies introduced new meetings into the development
process. These meetings have varying purposes and are held at different points in
development iterations. They are described in this section.
Stand-up meetings are daily team status update meetings in which team members relate
what they’ve achieved since the last stand-up meeting, what they are currently working on
and if they have anything blocking their progress. Participants stand as a reminder that the
meeting is short. One interviewee’s team does not hold stand-up meetings. They are
deemed unnecessary, as the team believes there is already enough interchange between team
members.
Planning meetings known in some circles as planning games are held at the start of an
iteration to determine what work will be done in the iteration. These meetings establish how
much work was done in the previous iteration versus how much was planned in order to
give a feel for how much work might be achieved in the current iteration. Interviewees
reported that planning games are attended by the development team, testers, client /
business analyst and the project manager. The client or client’s proxy provides the team with
a prioritised list of stories, for which the team will provide effort - both development and
testing - estimates. With this information it is possible to determine what can be achieved in
the iteration. Almost half of the interviewees referred to planning meetingas. One
interviewee referred to the use of network collaboration tools in order to include a
geographically remote client.
12
Quality Centre, a web-based system for managing automated tests, was created by Mercury Interactive, which
is now a division of Hewlett Packard.
13
Quick Test Pro is an automated graphical user interface testing tool, created by Mercury Interactive, that allows
for the automation of user actions on a web or client desktop interface.

22
One interviewee also referred to playing what is known as planning poker during planning
games. In planning poker, each participant has a stack of cards on which are printed
numbers. When asked to estimate the likely effort for a piece of work, each participant holds
up a card with the number corresponding amount of effort they believe appropriate. This
enables the team to quickly establish a consensus on the likely estimate.
Retrospectives are meetings held at the end of iteration to review how the iteration went.
The purpose of these meetings is to promote team self-improvement. Three interviewees
referred to their teams regularly holding retrospectives.
Showcases are an opportunity at the end of an iteration to demonstrate what has been built
during the demonstration. They provide clients an opportunity to provide feedback and for
development teams to celebrate their successes. For one interviewee’s team with clients in
another location running showcases was proving problematic. Clients needed to be a part of
the meeting, to see what was being done. Video conferencing and the use of online
collaboration tools have alleviated these difficulties.
Another interviewee indicated that while showcases are held every iteration, clients were not
invited to them all. In fact their team found: “… from experience that showing them very small
pieces of work where we have to contrive the mechanism for them to see what it’s delivering is actually
counter productive.” Instead the team demonstrates fit for purpose pieces of work that are
visible on a screen, and hence can be easily understood.
The teams of two interviewees hold story-telling meetings, alternately known as story
walkthroughs. These are held during an iteration to flesh out the details of stories, due for
development in the next iteration, of which the story card only has the bare details. Story-
telling meetings are designed to forge a common understanding about the stories being
examined. Developers, testers, and the business analyst attend these meetings.
4.3.3 Agile Adoption Benefits
The introduction of agile methodologies produced a number of benefits within the
organisation. One interviewee asserted that those teams which had successfully adopted
agile methodologies delivered software on time and on budget, of higher quality with much
lower production defect rates, all of which is seen historically as something rare inside the
organisation. Another interviewee related how their project, with the adoption of agile
methods, in their view, went from being considered a candidate for outsourcing to being
regarded as highly successful. This team achieved outcomes that teams twice its size, still
using plan-driven methodologies, were not able to achieve in the same amount of time.
Agile successes tended to be on smaller projects, although one project manager interviewee
had success with agile methodologies on their larger project.
The iterative nature of agile methodologies enabled high-value and high-risk development
requirements to be delivered first. Also it enabled development teams to be able to rapidly
respond to changing circumstances, leading one interviewee to describe agile methodologies
as: “more realistic”.

23
Development activities were broken down to tasks, which are defined by stories, that could
be completed within a development iteration. At the start of each iteration sufficient stories
were scheduled that could be completed in that iteration. In most cases iterations were two
weeks long. Having short iterations, with precise estimates made at the commencement of
an iteration, gave more confidence with estimates. Improved estimates also meant that
developers were able to work regular hours. The need for heroic efforts to bring the actual
progress in line with plan when nearing the end of a project was reduced or eliminated.
At the end of an iteration a story was understood to be either complete or not complete. This
led to a better understanding of the actual progress in development. A number of
interviewees indicated that this meant it was possible to “actually know where you are”, and so
have actually control over the schedule rather than no control. One of them indicated that
because of this, agile methodologies made their job easier.
Using agile methodologies provided a better understanding of the project management iron
triangle of time, cost and quality. For a number of interviewees there was “no going back” to
plan-driven methodologies. There was increased job satisfaction and a feeling of enablement
and in their view plan-driven methodologies led to less productivity.
Some interviewees indicated that the iterative nature of the software development allowed
for an increased frequency of regular production software rollouts, thus bringing value more
quickly to the client. It was suggested that not all groups in the organisation that adopted
agile did this.
A couple of interviewees noted that projects constantly delivering business value were able
to keep going. As one put it: “…if you’re delivering business value constantly, they’re going to
find the money to keep your project going… They can run on forever if they keep delivering value.”
Every iteration should have completed software, ready for delivery into the production
environment at the end of the iteration. Business value should be created in every iteration.
However, even if the funding stopped the client still had the value of the software deliveries
already made to date, as well as any software completed in iterations but as yet not
delivered. This is unlike plan-driven projects where potentially all the development
investment might be lost. Projects using agile methodologies could potentially be stopped at
any point, still having delivered value.
One interviewee went so far as to say that his team did not develop things that were not
needed; they would only build what was absolutely required14
. Their development team
pushes very hard to get the client to define business value for any requested changes. A
typical question would be: “what is the value in doing this piece of work?” Prior to the adoption
of agile methodologies apparently nobody was looking to define benefits. This can now be
done as work is broken up into small enough chunks that can be given a business value. Of
course the answer to these questions may be that a piece of work does not proceed. The
interviewee stated:
“… we suddenly realise that for them, it’s going to take ten years to recover the value on a five
week piece of work. And once they actually look at it and realise this is actually costing us five
weeks, they had no visibility on that before, but now they know. Why are we even doing it?”
14
This has inspired the term You Aren’t Going to Need it, or YAGNI.

24
This view on development stems from an attitude of whole group ownership. The
technology team are a part of the value delivery stream and are not just there to develop
code, an attitude apparently not widely held within the technology group. The interviewee
would not be happy with a team member who delivered software that while fulfilling the
stated requirements, did not add value. For them: “Software business is not about producing
software; it’s about adding business value.” In one case a project went agile, performed some
analysis, and found funding was out by 50%. The project was determined not worth doing
and hence closed. Clients appreciated that the software development team did not want to
waste the client’s money.
While there are general benefits to the adoption of agile methodologies, there are also
benefits pertaining to particularly groups of stakeholders involved in projects. The following
four subsections look at the benefits relating to clients, business analysts, project managers
and testers.
4.3.3.1 Benefits for Clients
Interviewees report improved client satisfaction with systems development. One
interviewee reported that his team is now exceeding clients’ expectations, and also
delivering “nice to haves” rather than just “must haves”.
Those clients who were educated in the use and benefits of agile methodologies became
willing participants in the development process, able and eager to watch their systems being
developed. They were prepared to increase their involvement, attending planning meetings
and demonstrations, determining priorities and being available to answer questions from the
development team in order to achieve an improved outcome.
Clients are now more closely engaged with development teams who have an increased
feeling of immediacy with the client. This was due to the clients deciding story priorities for
each iteration as a result of them seeing the system being developed on a regular basis,
enabling development teams to be more responsive. A number of interviewees noted that
when using plan-driven processes this was not possible or was at the very least problematic
with projects, leading to a sense that technology was not delivering. Another interviewee
reinforced this view, noting that historically there had been a huge divide between the
business and technology groups. Crossing this divide took some effort. One interviewee
reported that a lot of work was required to bring clients to the point where they understood
the benefits of agile methodologies and how they worked.
Engaged clients like the use of common language to define problems. One interview
reported that it is far easier for them to understand “we’re going to provide a guaranteed
recovery in the event of any system failure within 12 hours” rather than “we’re going to set up a
whole heap of databases and connections between these” and be able to made informed priority
choices, which might include not doing the work.
Client involvement in the planning game ensures that the client’s priorities are being worked
on. Given that at these meetings the stories are estimated, clients can have a level of
confidence as to what will be achieved on their behalf in the coming iteration.

25
In most cases the client attended end of iteration showcases. This provided a mechanism for
greater and more immediate feedback from the client on what had been developed, rather
than waiting until the end of the development phase of the entire system. Showcases assist
with getting clients more engaged.
Planning meetings and Showcases also provide forums to help settle priority disputes
between multiple client stakeholders, providing a common understanding to all as to what
work is to be done in the next iteration; however one interviewee noted that priority changes
on projects with multiple major client stakeholders can become political. Having the client
determine the priorities in planning meetings also makes the development team’s life easier.
The combination of increased immediacy with clients, early delivery of higher value
requirements along with an increased frequency of software delivery enabled development
teams to be able to respond quickly to business requirements priority changes, giving them
what they wanted, which led to an increased level of customer satisfaction. One interviewee
cited their client business area head as stating that the project, which had been failing before
adopting agile methodologies, was the most successful delivery ever.
4.3.3.2 Benefits for Business Analysts
Business analysts are freed up from writing large and detailed requirements specifications,
now acting as proxies for the client within projects. They prioritise large blocks of work with
the clients, thus able provide requirements guidance, and deal with requirement risk. Often
they will have specialised knowledge on how systems interact and what particular data is
stored, knowledge that a client might not have. One interviewee reported that business
analyst roles are changing with business analysts being given more responsibility, being
used more as operations managers, facilitating day-to-day agile methodologies mechanics.
4.3.3.3 Benefits for Project Managers
One interviewee, a development lead, indicated that their project manager “loves” agile
methodologies. These give a clear and transparent way to track work progress, without
having to dedicate time to work allocation and management, as would have previously been
the case with plan-driven methodologies. The team is self-managing, with a flatter team
structure, leaving the project manager to act more as a facilitator. The organisation’s project
management community is starting to be more open to agile methodologies due to the
success of a number of projects.
Another interviewee stated that their project manager works to minimise distractions,
keeping a micro-managing programme manager away from the team. This project manager
coordinates all the participants in the agile process so that work progresses efficiently.
A number of development lead interviewees reported that their project managers are able to
concentrate on the system big picture and long term, along with funding and financials. This
leaves the development team to concentrate on rapid, high-quality deliveries, described as:
“small chunks with real business value”.

26
4.3.3.4 Benefits for Testers
One interviewee recounted the changes that have taken place with testing across the
introduction of agile methodologies. In their opinion there has been an improvement for
testers. Previously, with plan-driven projects there is a tendency for system development
time to overrun. This situation created pressures for the testing team, particularly if there
was a fixed delivery date. System testing was squeezed for time, the result being that the
testing team had to work very long hours in an attempt to catch up. In the time available the
testing team prioritised testing on the basis of perceived risk, starting with the riskiest issues
first. Less risky items might not be tested in the time allocated for testing.
Automated regression testing brings with it a number of benefits. Automated testing
processes are far quicker than manual processes, and hence can be used far more often.
Automated tests are repeatable, and not prone to human error. All this leads to better
quality software being created. One interviewee indicated that on their project, some
regression testing is still done at the end of a development cycle, due automated acceptance
tests not having full system coverage. This will improve in the future as more automated
tests are developed; however they foresee that there will always be some manual regression
testing required.
There were large amounts of documentation that had to be understood before testing could
be done. Testers were swamped with this documentation. There were risks that the
documentation was not up to date or misinterpreted by the developers. In some cases the
documentation was not consistent, which led developers to make assumptions, not
necessarily the correct ones when developing. All this led to defects getting though to
production, with testers inevitably being blamed for missing them.
Now, using agile methodologies, testers are still blamed when defects are found in
production, but the production defect rate is dramatically reduced. Testers are a much more
integral part of the development team, actually driving the requirements process,
establishing the objectives and the business value of a change so that they are in a position to
be able to test properly. With this extra knowledge testers have become subject matter
experts, sometimes fielding calls from users and the support team on system use. There is a
sense in which they have become the de facto system manual, as their knowledge is of the
overall system whereas that of a developer’s might be in depth but of a particular segment.
Importantly, testers have the power of veto to prevent software deemed defective from being
released into production.
4.3.4 Agile Adoption Issues
While the adoption of agile methodologies within the organisation, which was welcomed by
the generally pro-agile technical teams, brought benefits and had some successes, it was not
trouble free. The following sections describe the issues experienced with adopting agile
methodologies.

27
4.3.4.1 Organisational Change Resistance Issues
The change to using agile methodologies was difficult for the organisation. In the view of
one project manager interviewee: “This is in part due to the organisation being conservative. “
Plan-driven methodologies had been embedded within the organisational culture for quite
some time. The organisation was quite used to sign-offs, specific stage gates, due process,
formal responsibilities, etc. Another interviewee suggested that the move to agile
methodologies was a quite significant cultural change, particularly for many in the upper
echelons of the information technology part of the organisation who did not have an
information technology background, but instead had migrated into the information
technology area from the business part of the organisation.
4.3.4.2 Method of Introduction Issues
Another stumbling block was the manner in which agile methodologies were introduced.
Effort was made with introducing these into the technical teams without much apparent
thought to other parts of the organisation. Buy-in to agile methodologies by the business
part of the organisation was not sought. One interviewee alleged that the business were told
what was happening, that is agile methodologies were going to be used, but not why or what
benefits there would be. Individual teams found that they needed to take the low-key
approach and educate clients in these matters themselves. In fact this may be the better
approach for getting business engagement. One interviewee suggested that: “going in for the
big bang is a bad idea. It frightens the life out of people.”
Also, no thought seems to have been given to introducing agile methodologies into the
higher levels of the technology organisation. For example, a practice capability support area,
championing use of agile methodologies, covers business analysts, developers and testers
but not project managers. In the view of one interviewee, no expectations about agile
methodologies had been set for upper management. This led some parts of upper
management to resist agile methodologies, creating friction and resistance. These parts of
the organisation still require education about agile methodologies and their benefits;
however some more general project management education may be required as well.
One interviewee went so far as to suggest: “some parts of upper management do not understand
the iron triangle.” Their suggestion about adopting agile methodologies was that talking to
the CIO and CFO about this was to risk bad news escaping at board level, a single project
failure potentially being seen as systemic failure. Instead, using small pilot projects and
building up from those might provide the path of least resistance to broader agile
methodology adoption.

28
4.3.4.3 Organisational Issues
One area in which the lack of understanding regarding agile methodologies played out was
with project reviews and audits. Historically the organisation has had software development
projects that were late and over budget. Project Control Boards15
are in place to protect the
organisation and are risk averse, particularly so for this organisation given the nature of the
business and the magnitude of the transactions it undertakes. They relied on plan-driven
methods to provide control and plan-driven project artefacts for information.
In contrast, Agile methodologies in part rely on trust, with increasing trust allowing for more
agility. “Trust me” according to one project manager interviewee does not work easily for
Project Control Boards particularly with higher risk, larger budget projects. There is a high
turnover of project managers so there is limited opportunity for building trust. Some teams
that built trust with early successes have been restructured or deployed once the successful
project is over, so the built up trust is lost.
Project Control Boards found that some project artefacts, for example Gantt charts,
previously produced as part of the planning and control processes, were no longer being
produced. In at least one case this led to project control boards being at loggerheads with
clients. Clients / sponsors wanted delivery commitments which the team agreed to;
however the up-front documentation burden then placed on the team by senior management
made the delivery dates unachievable.
This was part of a dichotomy where the organisation wanted efficient agile delivery, but
senior stakeholders wanted certainty with time and cost, which is something agile
methodologies do not provide. One interviewee described this as a Catch 22 situation where
it is not possible to have certainty and a rapid delivery cycle. A proposed solution was to get
the project sponsor on side and have them fight the “governance wars”, leaving the technical
team to focus on developing.
One interviewee noted that some inter-departmental office politics concerning the
introduction of agile took place, possibly created by some in the organisation who viewed
agile methodologies as rogue and hence not desirable. This created friction in some quarters.
4.3.4.4 Team Inadaptability Issues
Some development teams were unwilling to change and adopt agile methodologies. “The
method of getting them to change hasn’t actually included enough consideration for the change
process”: said one interviewee.
15
Interviewees used different terms: governance groups, audit committees, Project Control Boards and Project
Review Boards to mean the same thing. The term Project Control Board will be used for these in the context of
interview data summarisation.

29
Other teams have made multiple attempts to adopt agile methodologies, but for one reason
or another have not successfully made the transition. They need extra coaching, which may
not happen given the end of the official agile adoption programme. Alternately, the issue
might be with the members of the team. One development lead interviewee indicated that
agile methodologies require people of above average ability to be successful. A team with
members of mixed or average ability would struggle.
4.3.4.5 System Support Handover Issues
Agile methodologies assume that the development team has ownership of the system. One
interviewee reported that for their team this was not so. They are required to hand over the
system to the support group once it is in production. The handover process has been
problematic. The support group have no background in the system and are not seen as
technically savvy. They are often dealing with day-to-day issues and find it difficult to see
an overarching story. There has been some turnover in the support group, complicating
matters. Agile methodologies documentation produced, principally stories and acceptance
tests, is not amenable to the system handover process.
The team is still attempting to work out the answer to this issue. During the agile adoption
programme, the external coaches / mentors were asked about this issue, but no answers
were provided. The development team are involving the support group more in the system
development, inviting them to showcases where appropriate. It was noted that plan-driven
methodologies have a handover phase, which agile methodologies do not. More
documentation is now being produced than pure agile methodologies would require. As yet
there is not a single document template that can be used for all systems. The interviewee
suggested that: “we still haven’t got the silver bullet for that.”
4.3.4.6 Stakeholder Geographic Dislocation Issues
Another issue for this team is that of dealing with geographically removed clients. Agile
methodologies assume physical co-location. Fortunately the relationship with the client
business analyst, who works in another time zone, is carefully managed and works well.
Use of network-based collaboration tools during showcases helped alleviate some of the
difficulties.
This issue seems fairly common. A number of other interviewees also reported that they
were dealing with clients or business analysts in a separate location. One team had the
added complication of their physically distant business analyst also being somewhat
disengaged from the development team. Getting that engagement, took some effort,
winning them over only after succeeding with some success with challenging changes. In
the interim it meant the team had to deal with the added complication of translating business
requirements into technical requirements in isolation.
4.3.4.7 Issues With Clients
Some clients were resistant to the change, due to the increased client involvement demands
that agile methodologies make. In some cases projects required a dedicated person from the
client business to be seconded to the project team, putting pressure on business resourcing.
Some teams have circumvented this issue by using business analysts as client proxies. Even
so, the degree of customer engagement with projects is variable.

30
One interviewee noted that despite the development having changed to using agile
methodologies, some clients still expected to see plan-driven reporting: progress and budget
tracking as a project progresses.
Some clients do not want to engage in thinking about the business value of changes. This
might require them to drop parts of a system that are not used in order to reduce
maintenance costs. They are likely to hand over set requirements and expect the
development team to understand how their part of the business operates. Other clients want
quick delivery but also have plan-driven controls in place. These are largely mutually
exclusive.
Some resistance continues to come from clients at the start of a new project; however this can
be broken through, usually by someone with charisma, verve and a reputation for getting
things done, according to a development lead interviewee. Another interviewee indicated
the issue of customer engagement is ongoing, that they were dealing with a: “… constant
battle to get customer or customers into a role that really can drive that customer side of the Agile
process forward.” Their solution was to escalate the use of business analysts as customer
proxies, with a reasonable degree of success.
For one interviewee the issues of client resistance will reduce over time, provided those
people who owned the customer relationship were advocates for agile methodologies. For
the issue to completely disappear in the long term would take changes at tertiary courses,
such as Master’s of Business Administration. In their mind, these courses at best only refer
fleetingly to agile methodologies rather than acknowledging that they have now entered the
mainstream.
4.3.4.8 Business Analyst Issues
Some business analysts do not know where they fit into the organisation, given that they are
now no longer required to write detailed requirements. One interviewee suggested that
business analysts could use the time freed up from producing voluminous detailed
requirements by spending more time with the business, developing a higher level of
expertise with the system.
4.3.4.9 Project Manager Issues
Some project managers did not adopt agile methodologies, despite their teams doing so.
These project managers, more used to a hierarchical team set-up, would not attend the
various team meetings: daily stand-ups or end of iteration retrospectives, in an attempt to
hold onto decision-making power, leading to fundamental disconnection within the team16
.
One interviewee suggested solving this issue by raising the profile of project management
within the organisation: training project managers in agile methodologies, instilling project
management as a separate discipline rather than just having general managers running
projects and establishing a project management community within the organisation.
16
One of the interviewees rescued a project from this very situation.

31
Some resistance from project managers is a result of them not having received training in
agile methodologies and not understanding the changes going on around them in other
teams. They were happier using the known processes, knowing what was expected of them.
In the absence of funding for training these project managers, one interviewee suggested that
a form of internal coaching could take place. Project managers familiar with agile
methodologies would mentor those for whom these were new or unknown. One of the
interviewees is currently acting in this role; however their brief is to work with whole teams
and not just project managers.
4.3.5 Agile and Plan-driven Methodologies Co-use
This section investigates the co-use of agile and plan-driven methodologies within the case
study organisation.
Prior to the introduction of agile methodologies the organisation used a project delivery
methodology that was based on the Project Management Institute’s PMBOK, requiring the
production of numerous written artefacts. One interview described the organisation as:
“fixated on project investment boards, project control boards and stage-gating.”
4.3.5.1 Post-Agile Project Oversight Environment
Since the introduction of agile methodologies into the organisation, project control boards
still have oversight of development projects. An interviewee noted that amongst other things
project control boards need to be certain that “the business and technology have agreed to bodies
of work.” While some project control boards have adapted their methods to allow for agile
processes, one interviewee describes these as: “Few and far between.”
Some issues with project control boards, of differing views as to project artefact production
and of building trust, have already been mentioned in the section 4.3.4 Agile Adoption
Issues. As far as one interviewee is concerned, these issues can be dealt with. Yet there are
some people in the organisation who are apparently “stuck to the old way of doing things”,
including what information they expect from a project; however this is not a systemic
problem, instead a problem with some individuals, and can be worked around.
One major project has had use of agile methodologies accepted by their project control
board. One interviewee reported that their project control board was sold on the use of agile
methodologies as a delivery mechanism, on the basis that high risk is eliminated early. For
other project control boards, agile artefacts are translated to plan-driven: for example burn
chart to earned value. In the mind of the interviewer these are essentially the same thing;
however project control boards prefer to see things in terms of what they know. Earned
value provides an estimate of cost at project end, giving the project control board some
information with which to make go or no-go choices.

Thesis - Agile and Plan-driven Methods Co-existence

Thesis - Agile and Plan-driven Methods Co-existence

Recommended

Recommended

More Related Content

Similar to Thesis - Agile and Plan-driven Methods Co-existence

Similar to Thesis - Agile and Plan-driven Methods Co-existence (20)

Thesis - Agile and Plan-driven Methods Co-existence