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.

32

One interviewee indicated that some project control boards: “buy into agile.” In these cases, the project can be commenced with production of a vision scope document, essentially a high-level requirements document, about twenty pages in length, which will be added to as the project progresses. Project control boards will apparently often want more detail; however the approval of the vision scope could see certain funds allocated, or perhaps initial funding obtained to do early agile stages, with a review in the future. Alternately, funding might be provided to host an initial requirements workshop, enabling the creation of release plan that would give a long-term big-picture view of the project for which more definite funding could be obtained.

Australia Prudential Regulation Authority, APRA, auditing requirements have had some effect on the methodologies used in projects, although opinions on the effects vary. One interviewee saw APRA as the ultimate reason behind the retention of plan-driven methodologies:

“Agile is still considered the way we should do things, but, for regulatory purposes and for regulatory reasons, we are required to use a waterfall methodology. It’s one we have committed to with effort and so therefore, if we use Agile, we must still fulfil all the waterfall requirements legally.”

In contrast, a few other interviewees were of the opinion that APRA is not concerned about the actual method of project governance, but is more interested that the form of governance applied to a project is appropriate, is applied consistently and is predictable. Similarly, another interviewee when talking about the auditing of testing, remarked that the project control board is not interested in specific tests, but rather that the there is a consistent testing policy which is being used.

4.3.5.2 Agile - Plan-driven Hybrid Model

Project managers are having successes using agile methodologies to manage smaller17 projects while still reporting to project control boards that think in plan-driven terms. A number of interviewees stated that they use an agile – plan-driven methodology hybrid model in which the agile delivery aspects of a project are “book-ended” by plan-driven methodologies. This model keeps some of the rigour of plan-driven methodologies while taking in the previously mentioned advantages of agile methodologies. At the start of the project a business case is made. Then documents relating to project funding, benefits and project governance are written. The plan-driven aspects do not prescribe the delivery mechanism, so this can be left up to the choice of the development team. At the completion of a project a final assessment is made of the benefits realisation, although with agile delivery this can be done periodically, potentially after each delivery, or even each iteration.

Progress reporting for the project control board uses high-level Gantt charts, or an equivalent, showing release blocks of eight to twelve week’s duration. Agile methodologies are used to juggle the priorities within those blocks. This gives sufficient progress detail for the project control board, which meet fortnightly or monthly, depending on the project. Ultimately the project control board is looking for details of software delivered in a certain period of time.

17 Projects with budgets up to five million dollars might not be considered small in some circles.

33

Various techniques have been used to report costs, varying from deriving an earned value from the completed stories to reporting which stories have been delivered and giving a team velocity figure. These can be represented graphically: either showing what the team has delivered against that planned for the time block. Alternately a worm chart can show the derived earned value over time, or the value delivered over time. Traditional plan-driven type earned values can be fuzzy since they rely on estimating partial completion values on incomplete tasks, with a degree of imprecision. By contrast, measuring what has been fully completed is absolutely precise. One interviewee intimated that if the delivery rate is not as high as originally hoped for, their project control board will very quickly focus on those items that are considered less urgent, so that the delivery date remains unchanged.

On a monthly basis project managers report the high-level plan-driven aspects of progress to the project control board. The project control board somewhat are shielded from the use of agile methodologies. One interviewee reports that project control boards are getting the information they require, and seem happy with the arrangement.

The project control board holds funding stage gate reviews quarterly. These meetings determine if project benefits initially put forward to the business as a part of the business case are still valid. It examines costs and that deliveries are on schedule. Non-performing projects can be closed down. Performing projects receive continued funding.

One interviewee’s view is that until agile methodologies are more accepted, bracketing agile with a more traditional control structure works in the interim:

“… bracketing it all with a rather more traditional control structure gets us going, it gets it started, it enables us to use the core bits of Agile that are going to deliver the value as far as we can see.”

A development lead interviewee noted that the development team were too far removed from the view of their project control board on their project. Their project manager dealt with the more high-level plan-driven aspects of the project. This gave them the freedom to run the development phase fairly independently without interference, provided outcomes were being met: delivering software and keeping accurate track of completed software. The development lead had a degree of influence on the processes and methodologies to be used. It should be noted that the relationship between the developers and project manager in this team was functional, unlike some of the dysfunctional teams referred to in section 4.3.4.9 Project Manager Issues.

This view was reinforced by a number of other interviewees who felt that the co-use of methodologies was invisible to the developers, particularly when the project was going well. Their project managers act as the interface between the agile development team and the plan-driven project control board. One project manager interviewee suggested that project managers are able to choose the appropriate methodology as a case-by-case basis. Aspects such as the requirements of the project and the development team’s capabilities are aspects that would be taken into consideration.

34

4.3.5.3 Large Budget Agile Plan-driven Hybrid Success

Most of the interviewees reporting on agile plan-driven hybrid project success worked on smaller projects. One project manager interviewee managed a very successful, high-risk, large-budget hybrid project. The project budget for this project was a factor of ten in magnitude larger than for the smaller projects. In this case, senior management had more stringent project governance requirements. They required evidence of requirements up front, in a plan-driven fashion, and demonstrated adherence to these. The project was broken up into packages, which were built iteratively and put into production in stages, with some early production releases done quickly to gain trust. It was this project, referred to in section 4.3.3.1 Benefits for Clients, which was described as the most successful ever.

Dealing with management risk aversion on this project was difficult, described as “walking a delivery / governance tightrope”, with there being a “constant stream of internal and external reviews.” The interviewee’s view on methodology co-use was one of striving for a balance which would change with the project size, larger projects needing more plan-driven aspects. They suggested: “… planning should lead to project transparency, facilitated by suitable communications mechanisms and project plans.”

This balance of plan-driven and agile methodologies was noted by an interviewee, a development lead of another team, on a smaller project, in that their team seemed to be less heavily internal audited than some other teams. Of course the balance might also depend on the client involved and the project manager running the project.

4.3.5.4 Iterative Project Artefact Production

In some cases interviewees’ teams were breaking projects down from having one large release at the of the project project’s end, to having a number of smaller phased releases. One project manager interviewee was able to negotiate with their project control board for some project governance artefacts to be produced in an agile fashion, on an iterative basis, after having negotiated with the project control board as to what documents were required for the project in order to minimise the amount of documentation effort required.

In one case these documents were produced and updated in each development iteration requiring the creative generation and use of documents. As an example, one Interviewee used an Iterative Project Document Review and Approval Matrix to document what artefacts were being produced, when they might be expected and to track their production. Table 9 is based on an example of a medium sized project with two releases of software into production. Iteration zero is a planning iteration.

For the various project artefacts, referred to as deliverables in this instance, the table shows:

• whether or not the artefact was mandatory,

• owner,

• status,

• location,

35

• approval status,

• creation / update schedule.

Table 9: Example Iterative Project Document Review and Approval Matrix. Project Deliverables (Medium Project) Mandatory Owner Status Location Approved 0 1 2 3 R1 4 5 6 7 8 R2 Initiation & Assessment Phase Change Proposal Yes PM Complete Lotus Notes Yes C - - - - - - - - - - Review and Approval Matrix Yes PM Complete This XLS No X X X X - D C - - - - Business Case Yes Sponsor Complete SharePoint Yes C - - - - - - - - - - Benefits Realisation Plan Yes Sponsor Complete SharePoint Yes C - - - - - - - - - - Project Management Plan Yes PM Complete SharePoint Yes X U D D - C - - - - - Inception Phase Technical Project Risk Checklist Yes PM Complete SharePoint Yes X X C - - - - - - - - Requirements Specification - Release 1 Yes BA Complete SharePoint Yes U U U U C - - - - - - Requirements Specification - Release 2 Yes BA In progress SharePoint No - - - - - U U na U U - Non-functional Requirements Yes Incorporated into User Stories (Requirements Specification) Development Practices Plan Yes Dev Lead In progress SharePoint No X X X X - U X X X X Solutions Architect Document Yes Exemption Requested and Granted by SAF Test Strategy / Design Yes Test Lead Not Started SharePoint No X X X X - X U X U U - Execution Phase Acceptance Criteria Documented BA In progress SharePoint No - C C C - C C C C C - Manual Unit Test documented (as required) BA In progress SharePoint No - na na na - X X C C na - Code coverage report created BA In progress SharePoint No - C C X - X X C C X - Code review documentation / action items, standards BA In progress SharePoint No - X X C - C C C C C - Code: labelled, documented, checked-in, packaged BA In progress Clear Case No - X C C - C C C C C - Test: QC updated with test cases Test Lead In progress QC No - C C C - C C na C C - Test: QC updated with test execution & results Test Lead In progress QC No - C C C - X C na X C - Test: Defects documented in QA Test Lead In progress QC No - C X C - X C na C C - Transition Phase Test Summary Report (TSR) - Release 1 Yes Test Lead Complete SharePoint Yes - X U U C - - - - - - Test Summary Report (TSR) - Release 2 Yes Test Lead In progress SharePoint No - - - - - X U na U U Implementation Phase Support Handover Document Yes PM Not Started - - - - X - - - - - Implementation Plan / Deployment Guide - Release 1 Yes Dev Lead Complete TBC Yes - X U U C - - - - - - Implementation Plan / Deployment Guide - Release 2 Yes Dev Lead In progress - X U U X U Quest Change request - Release 1 Yes PM Complete Quest Yes - U U C - - - - - - Quest Change request - Release 2 Yes PM Not Started Quest No - U U C - - - - U U Value Capture Phase Project Close Report Yes PM Not Started - - - - - - - - - - - Deliverable not required in this iteration - Deliverable completed in this iteration C Deliverable updated in this iteration U Deliverable draft published for review in this iteration D Deliverable not updated (slipped) in this iteration X No update required for this deliverable na

The interviewee found that there was ready acceptance of their proposal to produce documents in an iterative manner and track their creation and update with the spreadsheet.

Through the use of the agile methodologies and the Iterative Project Document Review and Approval Matrix this interviewee found that there were no project process gaps. Agile methodologies fitted into a subset of the whole management process. The interviewee’s pragmatic approach behind the use of the matrix was to establish why particular processes were required, understand the process issues and work to a solution.

36

This positive reaction and the pragmatic approach was not universal. Reaction to the minimisation of up-front artefact production has been mixed. There has been scepticism from some quarters that the appropriate information is being captured and reported. Some clients, are more method neutral, showing indifference to the change, provided the project is delivering results. As one interviewee put it: “They’re not there for the methodology, they’re there for the outputs and they would rather anything that does that more effectively.”

The changes to artefact production have meant that the project control boards are undergoing a learning curve. They need to know where a project is up to and need information appropriately packaged in order to be able to understand it. This is an ongoing issue.

4.3.5.5 Plan-driven Artefact Production

Given that project control boards are still thinking in terms of plan-driven projects, the adoption of agile methodologies has not eliminated the requirement to produce up-front plan-driven artefacts. One interviewee, managing a lower risk project, reported that of the artefacts listed Table 9, the business case, opportunity document and project management plan are required up front, with the project management plan stating that agile methodologies will be used for system development and delivery. During the development phase status reporting and benefits tracking were required.

Table 10 takes a list of plan-driven project artefacts, those designated as mandatory in Table 9, as well as those mentioned by interviewees, and lists the number of interviews in which each was mentioned.

Table 10: Project Artefact Interview Reference

Project Artefacts Source Number Interviews Mentioned

Initiation & Assessment Phase

Opportunity document Interviewee 1

Change Proposal Table 9 0

Review and Approval Matrix Table 9 2

Business Case Table 9 4

Benefits Realisation Plan Table 9 2

Project Management Plan Table 9 5

High level delivery schedule - Gantt chart Interviewee 6

Budget Interviewee 3

Inception Phase

Technical Project Risk Checklist Table 9 1

37

Project Artefacts Source Number Interviews Mentioned

Requirements Specification Table 9 7

Development Practices Plan Table 9 0

Solutions Architect Document Table 9 4

Test Strategy / Design Table 9 4

Transition Phase

Test Summary Report Table 9 1

Implementation Phase

Support Handover Document Table 9 1

Implementation Plan / Deployment Guide Table 9 1

Implementation Change request Table 9 1

Value Capture Phase

Project Close Report Table 9 1

The contents of the table should not be taken as a definite measure of exact use of plan-driven type project artefacts; however it can be used as an indication of what plan-driven artefacts were in the interviewee’s minds. Requirements specifications and high-level delivery schedules feature most predominantly, followed by project management plans, business cases, solutions architect documents, and test strategies. All of these are part of project inception and initiation phases, i.e. produced at the start of a project.

In one interviewee’s view the retained plan-driven artefacts were retained to: “enhance the probability of project success.” These artefacts provided information for reporting to management, project control boards and APRA auditors.

Another interviewee reported that their team is almost purely plan-driven at the commencement of new projects in order to generate some initial project artefacts. It holds kickoff meetings. These are used to capture high level requirements, key integration points, time constraints, and generate some rough effort estimates which are all then used to gain an idea of the resourcing required and to create a high-level release plan. Methods of operation are determined and decisions made as to whether such factors as time to market or quality are more important. This is sent to the client so that there is a commonly understood project roadmap. At the kickoff meeting key areas of risk are identified, so that can be tackled up front. Another interviewee holds these meetings at the start of project, phases and releases.

38

A system architecture document was required up-front for a number of reasons. Principally it was retained due to the potential for system interaction and not wanting to create data problems, or replicate existing functionality. The central solution architecture board, which signed off after reviewing the document would also have a sense of any strategic architecture developments and be able to provide appropriate architectural guidance.

A number of interviewees reported that they use more traditional means of reporting on progress and cost to their project control boards. Table 11 lists the tools mentioned during the interviews that are used for this purpose. Please note that reference has already been made to the use of burn charts and earned value charts in section 4.3.5.1 Post-Agile Project Oversight Environment.

Table 11: Plan-driven Reporting Mechanisms

Tool Function

MS Project Reporting to PCB

PFS Cost tracking

Spreadsheets Reporting to PCB

Team Play Collecting of timesheet data

Microsoft project was used by one interviewee to report release schedule progress at a high level. The Gantt chart certainly did not contain a level of details that included every development task. Another interviewee used spreadsheets to generate work and burn-down charts. The Team Play system provides into PFS cost, reporting on project costs; however there are issues with this.

One interviewee noted that change control and delivery control processes remained unchanged. Test results are attached to release or change control documentation and physically signed off. Another interviewee stated that the build cycles on their projects were about six to seven weeks in order to accommodate the change control process, which were deemed to be a delivery constraint.

4.3.5.6 Plan-driven Artefact Production Issues

For some project managers, knowing that they are audited on plan-driven artefacts, the co-use of agile and plan-driven methodologies led to wasted duplication of effort and frustration. There in an increased workload described by a interviewee, who is a project manager, as:

“With only one project manager working 40 hours a week theoretically, I’ve seen project managers stay until 11 o’clock at night just to get the financials done. They have to do their financials, do they really have time to go over and maintain their story tree?”

39

The workload issue is also exacerbated by the linear nature of some plan-driven process requirements. One interviewee saw it this way:

“ … the other reason that Agile was not very well adopted at least across the board, is that as we said, we have this procedural underpinning requirement, everything at the bank is set up to match that. From our release management, change management controls, from the people that you need to get to sign off on anything is particular linear. Because everything is linear in that regard and I have to go to person X in order to get approval before I go to person Y to get approval, it makes it very hard for me to just include them both.”

At times the linear nature of change control processes would require working back from proposed delivery dates in order to determine when a series of interconnected activities needed to be completed: a practice not in accordance with agile methodologies.

One interviewee noted that there are not financial tracking tools available that work easily with agile methodologies. The timesheet tool is currently used to allocate times into release blocks, from six to eight weeks, depending on the length of the current release cycle. Also noted was a lack of project management tools that support mixed development, plan-driven and agile.

4.3.6 Future Methodology Use

Despite the end of the official agile methodologies programme, a number of interviewees indicated that future adoption will continue, although informally. The continuing adoption process was described by one interviewee as: “osmosis, cross-pollination”. As projects finish and the composition of teams change, those people who have used agile methodologies successfully will take their experiences and ideas with them. Development managers are looking out for opportunities to give people the chance to move about within the organisation, and transfer their skills to others.

Word of mouth also spread the news of the successful esults of using agile methodologies. Other teams will possibly want to emulate this success. Finally, development managers when recruiting new staff are on the lookout for people with either agile experience or those with ability to adapt to using agile methodologies. In fact, their stated preference is to bias any recruitment search towards these characteristics rather than specialist knowledge of the financial industry.

Amongst the interviewees there was a common desire expressed for software development projects to become even more agile, and hence less plan-driven. This reflects their positive experiences using agile methodologies. One interview went so far as to suggest that now development was done using agile requirement stories, so-called big up-front design could be done away with, reducing some of the up-front plan-driven burden. Their proposal was to move development towards the use of prototypes, which could be demonstrated to clients for quick confirmation that the appropriate requirements had been captured.

40

However, despite the successes of using agile methodologies within the organisation there is a sense of realism about its use. One interviewee noted that agile methodologies were not the answer for every project. They suggested that plan-driven methodologies were more appropriate in projects with multiple stakeholders with any or a combination of: conflicting requirements, conflicting deadlines or conflicting customers. Another interview was prepared to use plan-driven methodologies at the start and end of projects if it meant that the core parts could be used for software delivery. For yet another interviewee, the pragmatic view was one of “whatever works.”

The Project Management Office has the understanding that plan-driven methodologies though well established are not the “be and end all”. A cultural journey of change is happening. For one interviewee the cultural divide is: “plan-driven projects will be measured against a plan, whereas agile projects will be measured against objectives and benefits.” There is at least one internal agile methodologies coach working to educate teams and clients about the advantages of crossing that divide. Their view is one of quiet optimism that the organisation will become more agile over time, a situation hoped for by all of the interviewees in this case study. This is reflected in one interviewee’s comment, crediting agile methodologies with success but also the people using them when stating that agile methodologies are about people foremost: “… I believe entirely in not just Agile. Agile’s a great process. I actually believe it’s the people that do it that actually give it its extreme.”

41

5 Discussion and Conclusions 5.1 Discussion Agile methodologies were officially introduced to the organisation being studied about eighteen months ago, with at least one team trialling the use of these for about three years. Despite some issues with the official introduction programme, agile methodologies have been successfully introduced into the organisation, although their use is patchy. With the official introduction programme over, further spread in the use of agile methodologies will come from the use of more informal mechanisms: staff redeployment, recruiting practices, internal coaching and its adoption by development teams that have observed the successful use of agile methodologies by other teams.

The new agile methodologies required new mechanisms in order to work. These were a mixture of practices, meetings, and tools. Principal among these was the use of stories: small encapsulated requirements that added business value. In the main, these were written onto story cards, small index cards and placed on a storyboard, enabling anyone to instantly see the story backlog, and what was currently being worked on. Some interviewees, however, reported using electronic tools for this purpose.

New practices introduced as part of using agile methodologies included refactoring, Test-driven Development and continuous integration. The aim of these is to improve quality. Refactoring is the revising of code to make it easier to understand. Test-driven Development sees new automated test cases written before any code change is made. Continuous integration is the practice whereby code written by the various developers in a team is integrated frequently, possibly multiple times per day, in order that any introduced errors can be discovered and removed expeditiously.

The use of agile methodologies introduced new regular meetings. Of these, planning games, showcases and retrospectives were regularly held each interaction, while stand-ups were held daily. At the start of the iteration, planning games reviewed the progress of the previous iteration and using the amount of work completed in that iteration as an indication of how much work can be done in an iteration, prioritised the work for the current iteration. At the end of the iteration, showcases demonstrated the work completed, while retrospectives focussed on how the iteration went, and how the team might improve. Stand-up meetings provided an opportunity to provide daily status updates as to how tasks were progressing.

The introduction of agile methodologies has brought with it a number of benefits to the organisation. The use of iterations and stories enables flexibility and hence increased responsiveness to changed client requirements. It also allows for high risk and high value stories to be tackled and delivered first. An increased frequency of systems production deliveries enables a continual delivery of business benefits. Indeed, use of agile methodologies allows for an increased focus on benefits to the client. Clients are now more engaged in the development process, determining priorities and providing feedback to the development team on newly created functionality. This has led to more delivery success for teams using agile methodologies. The net effect of these benefits has led to an increase in customer satisfaction and an improvement in regard for the teams that have been using agile methodologies.

42

The acceptance of agile methodologies varies within the organisation Some of this variation is laterally across teams and clients. Indeed some clients take a neutral stance on development methodologies as long as project results are positive. Some variation is vertical. Figure 4 illustrates the vertical variation in the acceptance of agile methodologies.

Figure 4: Variation in Support through the Organisation Hierarchy

Acceptance of agile methodologies is universal among the interviewees: indeed some are proponents. All have alluded to agile methodologies being less accepted higher up the management triangle as shown in Figure 4 above. Meanwhile, there are individuals within the organisation who are working to educate / coach people at various levels in the use and benefits of agile methodologies. It would therefore be expected that over time the vertical variation in the acceptance of agile methodologies would diminish.

The adoption of agile methodologies within the organisation has not been problem free and some ongoing issues remain. Some relate to the difficulty of cultural change within the organisation, and some relate to specific stakeholders.

The organisation change was difficult for a number of reasons. The technology group was seen to have had projects run late and over budget, so was not seen by some as credible in suggesting change. Plan-driven mechanisms were in place to minimise risk and upper management was seen as quite conservative. Project Control Boards had oversight of all development projects. The formal agile adoption programme did not include upper management or clients within its scope, leading to change resistance from some quarters, including some project control boards, due to a lack of knowledge about agile methodologies, their mechanisms and benefits.

43

Some issues relate to change in practices, for example the handover of knowledge to the system support group. Others relate to changes in work roles, such as business analysts who no longer need to produce copious amounts of requirement documentation. In discussing the issues with agile methodologies adoption, all the interviewees were positive that they could be overcome and were working towards overcoming them. For the most part, coaching, education and training were seen as a large part of the solution, and some interviewees were actively working in this area.

For those teams who adopted agile methodologies, interviewees reported that project control boards continued an oversight role. While some project boards were reported to have accepted use of agile methodologies and the information they produce, others still require plan-driven information and practices. To accommodate the requirements of project control boards a number of interviewees report that their teams have adopted an Agile - Plan-driven hybrid project model. This gives the project control board the rigour of plan-driven methodologies while allowing the development team to generate the benefits of agile methodologies during project execution and delivery. Interviewees reported successes using this project management model.

The above understanding leads to the development of the Agile Plan-driven Hybrid model as shown in Figure 5. This model eloquently describes the co-existence of both methodologies. It shows projects initiating and closing in a plan-driven manner and the project is executed and delivered using agile methodologies.

Figure 5: Agile - Plan-driven Hybrid Project Model

44

The concentric circular arrows represent the various cycles taking place. The smaller circular arrows represent more frequent and intensive cycles as represented by the darker shading. This can be expected to take place at least once within the timeframe of the next largest cycle. The frequency of these cycles is shown in Table 12.

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

Cycle Frequency

Stand-ups Daily

Development Iteration Usually fortnightly

Progress Review Monthly (2 iterations)

System Production Release 3 – 6 iterations

Funding Review Quarterly

In keeping with the agile – plan-driven model, it was demonstrated how to produce required project management artefacts in an iterative fashion, without there being project management process gaps. In other interviewees’ minds various plan-driven project artefacts feature heavily: requirements specifications, high-level delivery schedules, project management plans and solutions architecture documents among them. The production of all these artefacts fits into the agile – plan-driven hybrid model, although duplication of effort exists in some quarters, and there are some issues around the lack of financial tracking tools supporting mixed development.

Agile methods will continue to be used and promoted with the organisation. Over time the proportion of staff trained and proficient in the use of agile methodologies will grow. Most interviewees would prefer for projects to become more agile and less plan-driven; however there is also a sense of pragmatism to use hybrid projects if this meant agile methodologies could be used for software delivery. Agile – Plan-driven hybrid projects would appear to have at least a short-term future in the organisation. In the longer term agile methodologies may become the development dominant paradigm, which would make this model obsolete.

5.2 Conclusions This research has investigated the introduction and use of agile methodologies within a large financial services organisation. It has established that agile and plan-driven methodologies can work together in the same organisation, on the same project, a situation indicated as possible by Boehm (2002) and Boehm and Turner (2004). In dealing with project control boards who require more rigour than agile methodologies supply, this case study proposes the use of the agile – plan-driven hybrid model, as seen in Figure 5, in which projects are initiated and concluded using plan-driven methodologies, while executed and delivered using agile methodologies.

45

The case study discovered that within the organisation there are obstacles to overcome for both agile and plan-driven methodologies to co-exist. This reflects Boehm and Turner’s (2005) view that implementation of agile brings many challenges. Principally, these are to do with the lack of knowledge regarding the benefits and use of agile methodologies, thus ongoing education about these required, in line with Cohn and Ford’s (2003) indication that a complete paradigm shift is required.

The support for plan-driven and agile methodologies varies across the hierarchy of the organisation, with management less accepting of agile methodologies. Figure 4 in section 5.1 shows this variation diagrammatically. The hierarchical variation is the reverse of that found by McAvoy and Sammon (2005). This difference might be due to McAvoy and Sammon explaining the benefits of agile methodologies prior to judging their study participant’s reactions, and also that the organisations involved were software development companies. In this case study, upper management in the technology group was not necessarily from the information technology industry, but potentially from the financial services industry with a possibly more conservative, risk averse outlook. Also the official agile adoption programme had not targeted upper management, so to some extent the benefits of agile methodologies would have been unknown to them.

The research showed that within the case study organisation clients’ reactions to the use of agile methodologies are mixed. Some clients are methodology neutral, that is, they are indifferent to what development methodologies are used provided the project delivers successful outcomes. Other clients, who have realised the benefits of agile methodologies, have embraced their use and are more engaged with the projects. As a result of it these clients have become more engaged and exhibit an increased level of satisfaction with software development within the organisation.

5.3 Further Research This research leaves a number of questions open for further research. Are the interviewees’ views on the use of agile methodologies in the organisation more widely held in the organisation? Further research within the organisation would determine this.

Is the agile – plan-driven model used more universally or are there other more generic means of using both agile and plan-driven methodologies in an organisation? Are the problems encountered by this organisation while introducing agile methodologies the same as for other organisations? Case studies of other larger organisations in the same or other industries would provide multiple avenues for investigation. Similarly, case studies could be done within smaller organisations to establish if the organisation’s size is a factor in which methodologies are used for software development.

Finally, further research in the organisation studied after some time has elapsed would allow for the opportunity to extend the case study into a longitudinal study, examining any changes in the use of agile and plan methodologies over time.

46

5.4 Reflection

The researcher’s view on agile methodologies and their use has changed during the course of this research. Prior to the commencement of the research the researcher felt that agile methodologies were an excuse to not document and instead run riot and cut code in a cowboy fashion. During the course of the research the researcher has come to the realisation that in the right circumstances the use of agile methodologies can be preferable to using plan-driven methodologies; however in some circumstances plan-driven methodologies are still preferable. Also, that agile methodologies used properly require just as much discipline in their use as plan-driven methodologies used properly. This researcher appreciates from this research that both agile and plan-driven methodologies have the ability to co-exist, providing opportunities for project management synergies and greater benefits for their organisations.

47

References

Abrahamsson, P, Salo, O, Ronkainen, J & Warsta, J 2002, Agile Software Development Methods: Review and Analysis, VTT Publications. Espoo, Finland.

Abrahamsson, P, Warsta, J, Siponen, MT & Ronkainen, J 2003, New Directions on Agile Methods: A Comparative Analysis, International Conference on Software Engineering. Portland, Oregon, USA, IEEE.

Adams, S 2005, Dilbert, 16/11/2005, United Feature Syndicate, viewed 20/05/2009, <www.dilbert.com/strips/comic/2005-11-16/>.

Adams, S 2007, Dilbert, 26/11/2007, United Feature Syndicate, viewed 20/05/2009, <www.dilbert.com/strips/comic/2007-11-26/>.

Alshayeb, M & Li, W 2005, An Empirical Study of System Design Instability Metric and Design Evolution in an Agile Software Process, The Journal of Systems and Software, 74, 269.

Angioni, M, Carboni, D, Pinna, S, Sanna, R, Serra, N & Soro, A 2006, Integrating XP Project Management in Development Environments, Journal of Systems Architecture, 52, 619-626.

Armour, PG 2007, Agile ... and offshore, Association for Computing Machinery. Communications of the ACM, 50, 13.

Augustine, S, Payne, B, Sencindiver, F & Woodcock, S 2005, Agile Project Management: Steering from the Edges, Association for Computing Machinery. Communications of the ACM, 48, 85.

Balasubramaniam, R, Lan, C, Kannan, M & Peng, X 2006, Can distributed software development be agile?, Association for Computing Machinery. Communications of the ACM, 49, 41.

Baskerville, R, Balasubramaniam, R, Levine, L, Pries-Heje, J & Slaughter, S 2003, Is Internet-speed Software Development Different?, IEEE Software, 20, 70.

Beck, K 2000, Extreme Programming Explained: Embrace Change, Addison-Wesley. Boston.

Beck, K 2003, Test-Driven Development by Example, Addison-Wesley. Boston.

Beck, K, Beedle, M, van Bennekum, A, Cockburn, A, Cunningham, W, Fowler, M, Grenning, J, Highsmith, J, Hunt, A, Jeffries, R, Kern, J, Marick, B, Martin, RC, Mellor, S, Schwaber, K, Sutherland, J & Thomas, D 2001, Manifesto for Agile Software Development.

Beck, K, Hannula, J, Hendrickson, C, Wells, D & Mee, R 1999, Embracing Change with Extreme Programming, Computer.

Benediktsson, O & Dalcher, D 2004, New Insights into Effort Estimation for Incremental Software Development Projects, Project Management Journal, 35, 5.

Boehm, B 2002, Get Ready for Agile Methods, With Care, Computer, 35, 64-69.

Boehm, B & Turner, R 2005, Management Challenges to Implementing Agile Processes in Traditional Development Organizations, IEEE Software, 22, 30.

Boehm, DB & Turner, R 2004, Balancing Agility and Discipline: A Guide to the Perplexed, Addison Wesley. Boston.

48

Börjesson, A & Mathiassen, L 2005, Improving Software Organizations: Agility Challenges and Implications, Information Technology & People, 18, 359.

Brooks, F 1986, No Silver Bullet - Essence and Accident in Software Engineering, In Kugler, HJ (Ed.) Information Processing 1986. Dublin, Elsevier.

Brooks, F 1995, No Silver Bullet Refired, The Mythical Man-Month. 2 ed. Addison-Wesley, Reading, Massachusetts, 207-226.

Cao, D-B 2006, An Empirical Investigation of Critical Success Factors in Agile Software Development Projects, School of Business and Technology. United States -- Minnesota, Capella University.

Cohn, M & Ford, D 2003, Introducing an Agile Process to an Organization., Computer, 36, 74-78.

Cowham, R & Stephens, M 2005, To XP or not to XP?, ITNow, 47, 16.

Dalcher, D & Benediktsson, O 2006, Managing Software Development Project Size: Overcoming the Effort-boxing Constraint, Project Management Journal, 37, 51.

Damian, D & Chisan, J 2006, An Empirical Study of the Complex Relationships between Requirements Engineering Processes and Other Processes that Lead to Payoffs in Productivity, Quality, and Risk Management, IEEE Transactions on Software Engineering, 32, 433.

Eclipse 2008, Introduction to OpenUP, 27/10/2008, Eclipse Foundation, viewed 16/09/2009, <http://epf.eclipse.org/wikis/openup/index.htm>.

Erickson, J, Lyytinen, K & Siau, K 2005, Agile Modeling, Agile Software Development, and Extreme Programming: the State of Research, Journal of Database Management, 16, 88-100.

Fitzgerald, B, Hartnett, G & Conboy, K 2006, Customising Agile Methods to Software Practices at Intel Shannon, European Journal of Information Systems, 15, 15.

Fowler, M 1999, Refactoring: Improving the Design of Existing Code Addison-Wesley. Reading, Massachusetts.

Frey, LR, Botan, CH & Kreps, GL 2000, Investigating Communication: an Introduction to Research Methods, Allyn and Bacon. Boston

Germain, E & Robillard, PN 2005, Engineering-based processes and agile methodologies for software development: a comparative case study, The Journal of Systems and Software, 75, 17.

Henderson-Sellers, B & Serour, MK 2005, Creating a Dual-Agility Method: The Value of Method Engineering, Journal of Database Management, 16, 1.

Holmström, H, Fitzgerald, B, J., ÅP & Conchúir, EÓ 2006, Agile Practices Reduce Distance in Global Software Development, Information Systems Management, 23, 7.

Howard, A 2001, Software Engineering Project Management, Association for Computing Machinery. Communications of the ACM, 44, 23.

Jacobson, I, Brooch, G & Rumbaugh, J 1999, The Unified Software Development Process Addidon-Wesley. Reading, Massachusetts.

Janzen, DS 2006, An Empirical Evaluation of the Impact of Test-driven Development on Software Quality, Department of Electrical Engineering and Computer Science. United States - Kansas, The University of Kansas.

49

Johnson, JH 1994, The CHAOS Report, The Standish Group International Inc. Dennis, Massachusetts, USA.

Johnson, JH 2000, CHAOS 2000, The Standish Group International Inc. Dennis, Massachusetts, USA.

Koskela, J & Abrahamsson, P 2004, On-site customer in an XP Project: Empirical Results from a Case Study, EuroSPI 2004. Trondheim, Norway, Springer-Verlag.

Layman, L, Williams, L & Cunningham, L 2004, Exploring Extreme Programming in Context: an Industrial Case Study, Agile Development Conference. Salt Lake City, IEEE Compuiter Society.

Lindstrom, L & Jeffries, R 2004, Extreme Programming and Agile Software Development Methodologies, Information Systems Management, 21, 41.

Little, T 2006, Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty, IEEE Software, 23, 48.

Lycett, M, Macredie, RD, Patel, C & Paul, RJ 2003, Migrating agile methods to standardized development practice, Computer Bulletin, 36, 79-85.

Mann, CR 2005, An Exploratory Longitudinal Case Study of Agile Methods in a Small Software Company, Department of Computer Science. Calgary, Canada, University of Calgary.

McAvoy, J & Sammon, D 2005, Agile Methodology Adoption Decisions: An Innovative Approach to Teaching and Learning, Journal of Information Systems Education, 16, 409.

Nerur, S, Mahapatra, R & Mangalaraj, G 2005, Challenges of Migrating to Agile Methodologies, Association for Computing Machinery. Communications of the ACM, 48, 72.

Nord, RL & Tomayko, JE 2006, Software Architecture-Centric Methods and Agile Development, IEEE Software, 23, 47.

Parnas, D 2006, Agile Methods and GSD: The Wrong Solution to an Old But Real Problem, Communications of the ACM, 49, 29-29.

Perry, C 1998, A structured Approach to Presenting Theses: Notes for Students and their Supervisors, Australasian Marketing Journal, 6, 63 - 86.

Rajlich, V 2006, Changing the Paradigm of Software Engineering, Association for Computing Machinery. Communications of the ACM, 49, 67.

Rasmusson, J 2003, Introducing XP into Greenfield projects: Lessons Learned, IEEE Software, 20, 21.

Raz, T 1993, Introduction of the Project Management Discipline in a Software Development Organization, IBM Systems Journal, 32, 265.

Robson, C 2002, Real World Research, Blackwell Publishing. Oxford.

Royce, WW 1970, Managing the Development of Large Software Systems, IEEE WESCON. Los Angeles, TRW Inc.

Turk, D, France, R & Rumpe, B 2005, Assumptions Underlying Agile Software-Development Processes, Journal of Database Management, 16, 62.

Yin, RK 2003, Case Study Research Design and Methods, Sage Publications Inc. Thousand Oaks, California.

50

Appendix A – Research Interview Questions

The following questions were used as a guide in the interviews conducted.

1. Background

1.1 Organisation Background

What is the primary business of the organisation? (In broad non-confidential terms.)

How large is the system development component of the organisation? (Staff; number of teams / projects.)

1.2 Interviewee background

By how much does your agile experience predate the introduction of agile methodologies into the department / organisation? Delete this question (clumsy and replace with:

When did you join this organisation? Did you have Agile experience prior to joining this organisation?

2. Introduction of Agile Methodologies

2.1 Organisation History

When was Agile introduced? / How long has Agile been in use in this organisation?

Why did the organisation adopt Agile methodologies? What were the reasons for the department / organisation introducing agile methodologies?

From where / whom did the push to introduce agile methodologies come?

Which variety of agile methodology was adopted?

How has it been adapted to suit the local working environment?

What were the formal success factors for measuring that the introduction of agile methodologies was successful?

How have the introduction of agile methodologies been deemed successful?

How do you define success?

What sorts of resistance have there been to changing to agile methodologies?

2.2 Organisation Current Situation

Currently which agile methodologies are being used? (By department / organisation; by you?)

51

What business / project function do they perform?

How would you describe the measure of acceptance of agile methodologies within the organisation?

What sorts of resistance are there to the use of agile methodologies?

Are there plans to introduce agile methodologies into other teams / departments within the organisation?

3. Retention / Reintroduction of Plan-driven Methodologies

What plan-driven project management methodologies are being used in conjunction with agile methodologies?

Were these plan-driven methodologies reintroduced after the introduction of agile methodologies, or were they never eliminated?

Why were they retained / reintroduced?

What business / project function do they perform?

What plan-driven methodologies were dropped with the introduction of agile methodologies?

What was the general reaction to these being dropped?

4. Co-use of both methodology types

What do the plan-driven methodologies give to the business / project that agile methodologies do not? In terms of:

• Information

• Certainty

• Level of comfort

What does agile methodology give to the business / project that plan-driven methodologies do not? In terms of:

• Information

• Certainty

• Level of comfort

What kinds of clashes / problems have using agile methodologies / practices alongside plan-driven methodologies created?

How does the department deal with the differing demands / requirements of agile and plan-driven methodologies?

What project management gaps still need filling?

What will / should be used to fill them?

What is your level of satisfaction with agile methodologies?

52

What is your level of satisfaction with the mixture of agile and plan-driven methodologies?

5. Client Experience

What level of client involvement has there been in the projects that use agile methodologies?

Has this level of involvement changed with the introduction of agile methodologies?

Has this level of involvement changed with the reintroduction introduction of pre-driven methodologies?

How do you perceive their level of satisfaction with agile methodologies?

How do you perceive their level of satisfaction with the mixture of agile and plan-driven methodologies?

53

Appendix B – Master Theme Map

Interviews Categories and Themes 1 2 3 4 5 6 7 8 9 10 11 Organisation

Organisation primary business Organisation Technical Size Organisation Length of Agile Experience Reason for introducing Agile People promoting adoption of agile

Practice capability Project excluded from agile adoption programme

Organisation historically "fixated" with PCBs , control boards, stage gates

Adoption program stopped after 6 months Cultural Issues, result = mixed bag Funding disappeared Lacked follow through commitment Management restructure with CIO departure

More teams are using agile New CIO focussing on management of people rather than project delivery

Interviewee Interviewee Agile Experience Interviewee Prior Experience Reactions / thoughts

"It's not rocket science." Agile is foremost about people and relationships / interactions

Learn for each project Most of agile is common sense No Going Back Pragmatic use of methods

Agile Method Communication face to face rather than reports

Processes facilitate commonsense activities Adoption

Adoption programme used to drive up quality

Being prescriptive will lose benefits of learning values

Continued adoption will be organic, through osmosis, cross-pollination

One team's adoption predates the organisation

Other teams did not have the opportunity to use coaches and take it up

People are "buying" agile Pilot program successful - allowed for expanded use

54

Interviews Categories and Themes 1 2 3 4 5 6 7 8 9 10 11

Recruiting agile experience or agile capable people

Some teams embraced wholeheartedly temporary productivity decline; recruited also

Who sought business buy-in Business was told of agile adoption but not why or benefits

Big bang introduction was / is a bad idea

Organisation has too much inertia Variety of Agile used Agile Localisation

Traceability Audit Compliance

Degree of agile maturity Development maturity assessments being undertaken

Adoption Assistance Provision of External Coaches

assisted adoption worked with software competency group

worked with teams on agile activities in projects

brought the agile method they were used to

weren't able to answer some hard questions

Some internal coaching is now being done

Benefits Funding may be extended as project is being delivered

If happy with what's delivered, will release another chunk of funding

But can stop at any point and still have value

Able to shift priorities when plan-driven dependencies are late

Acceptance testing done in iteration Achieved outcomes teams twice the size could not

Acquire / refine requirements as project proceeds

Allows focus on high quality delivery Breaks requirements into small chunks which can have value defined

Changes are being expressed in business and not technical terms

Development team is pushing for benefits to be defined

Development teams working regular hours - no heroics required

55

Interviews Categories and Themes 1 2 3 4 5 6 7 8 9 10 11

Different (improved) approach to customer engagement

Different (improved) approach to quality

Don't develop things that are not needed

Flatter team structure Focus on benefits Good attendances at retrospectives High performing team High quality - low production error rate

High value and risk delivered first Increased flexibility Increased frequency of rollouts Made job easier Managing benefits throughout project, not just at end

More productive More realistic than plan-driven On time, on budget Project went from being considered outsourced to successful

Reducing risk Respond to client needs quickly - more responsive

Software production introduction happening earlier

Successes tend to be on smaller projects Team concentrates on small chunks of real business value

Timely deliveries Whole group problem / change ownership

Any missed deliveries have lower impacts

Clients - benefits At call subject matter expertise Buy-in happening Can quickly change priorities Customer sees showcase

Helps settle priority disputes Provides regular - increased - feedback

Delivering 'nice to haves'. determining priorities Exceeding customer’s expectations. Giving client what they want If business value being delivered, client will find more project funding

If trained became most willing participants

Improved customer satisfaction Increased immediacy with client

56

Interviews Categories and Themes 1 2 3 4 5 6 7 8 9 10 11

Involvement with project Increased / customer engagement

Receptive to technology finding alternate solutions

Working well for engaged customers

Vast improvement Project Managers - benefits

Allows PM to concentrate on higher order tasks

Best PMs kept distractions away from teams

Increased estimate confidence Iron Triangle understanding Not progress tracking Now facilitators Scope and cost prediction better Understand actual position PM community starting to be more open about agile

Testers - benefits Waterfall - testing at end squeezed for time

Testers were blamed for missed bugs

Swamped with documentation might not be up to date Some part required interpretation

Some documentation self-contradicted

Seen as honest brokers who tell the truth

Agile Defect rate has dropped dramatically

Have another developer verify dev test status

Testers made integral to team Testers drive requirements Testers became BAs Testers look to "why" of requirements - objective

Paradigm shift to business value of change not technical use case

Stories easier to establish test criteria for

Less documentation to wade through

Now subject matter experts Have power of veto on delivery

Test cases linked to stories Issues

57

Interviews Categories and Themes 1 2 3 4 5 6 7 8 9 10 11

BAs don't know where they fit - now need to be customer proxies

BAs not fully engaged Concern about level of reporting Conservative organisation Dichotomy - certainty and agile Differing stakeholders' different priorities - clash

Geographical separation - physical barriers

Get sponsor to fight governance wars Handover to support Many teams are suspicious of agile No buy-in from upper management

Introduction - not via CFO, CIO Introduction - small pilots first then work up

Not all projects have customer representatives

Not all teams had the opportunity to take up agile

Perception of others as 'rogue' Relationship breakdown - no trust built up

Requires good team Some teams make multiple attempts but agile doesn't take

need training Some teams only paying lip-service to agile

Stakeholder differing priorities: client and management

Translation of requirements from business speak to technical

Unwillingness of some to change Younger teams more amenable to agile Adoption Resistance

Not from technical teams Governance groups Waterfall has been embedded for quite some time

governance bodies shielded from agile

Clients Battle to get customers into an agile customer role

May ease as tertiary courses start to recognise agile

Need those who own customer relationship to drive agile more

Buy-in is not universal Varying degrees of customer engagement

Increased demands on clients

58

Interviews Categories and Themes 1 2 3 4 5 6 7 8 9 10 11

took a while to understand and commit to agile

Some don't want to engage in thinking about business value

Not prepared to drop parts of system that are not used.

Hand over requirements Assume developers understand their part of the business

Some want quick delivery and also plan-driven controls

Project Managers Other PMs not coping with cultural shift

Used to more hierarchical approach

Used to sign-offs, responsibilities, due process, etc.

May be due to lack of training PMs now facilitator rather than a boss

Introduced from bottom up Some PMs not attending meetings - team disconnect

Not understanding what other teams are doing

Comfort in known processes Some PMs don’t want but teams do = disconnect

Agile Future No further adoption plans PM tool that allows agile workflow being

developed

Training for agile still available Internal coaching is taking place.

Agile Project Mechanisms Acceptance criteria – word templates

Word Templates Built into stories

Build Light Collaboration tools for remote

stakeholders

Continuous Integration Downtime - refactoring iterations Estimation poker Flatter team structure Instant messaging Kick start meeting for project, phase,

release

Lean software development Mingle – starting to replace story wall MS Project - used for PCB reporting pair programming - not

Formal code reviewing done instead Only done for complex sections of code

59

Interviews Categories and Themes 1 2 3 4 5 6 7 8 9 10 11

PFS - funding system. Take data from timesheet system

Planning meetings Quality Centre – test repository Quick Test Pro Refactoring code Retrospectives Show case meetings / demonstrations

Restricted to fit for purpose, visible on screen changes for clients

Share Point repository Spreadsheets - used for tracking and PCB reporting

Stand-up meetings Story telling meetings / story walkthrough

Story board Team Play - time sheet system Test cases as functional requirements Test Driven Development Video conferencing Visio wikis

Stakeholders Business Analysts

Come up with system vision, jointly scope with client

Dealing with requirement risk, guiding requirements

Does preliminary large block prioritisation with business

Don't need for systems that stay within business boundaries

Ensures that there is a backlog of stories Has deeper knowledge of systems than clients

Manage iterations Now facilitators Potentially knows where data comes from which client may not

run workshops Use as customer proxies works Used as operational managers Used when there is more than one stakeholder

Clients Sometimes do not care or know if agile used

Don’t necessarily 'see' agile Don't see 'project' but a series of conversations about their system

Not there for the methodology - there for the outputs

Try not to involve them in technology speak - stick to business value

60

Interviews Categories and Themes 1 2 3 4 5 6 7 8 9 10 11 Method co-use

Methods used in conjunction with Agile Some clients still expect plan-driven type status reporting: budget, progress

Many plan-driven mechanisms are still in place

Retention What

Change Control Always done Auditors see that it is always done

System architecture avoid duplication system consistency system interaction

Why Enhance probability of success Regulation

Dropped What – up front tasks minimised Project Approval Matrix Able to negotiate documentation required

Reaction Negative

Scepticism Indifference

Positive Development team below PCB horizon - can use agile

Can choose project methodology consistent with progress reporting / burn-down + delivering

PM plan-driven at high level; team agile in details

Mingle can be used as a reporting tool Governance / audit body - PCB

Undergoing a learning curve Need information appropriately packaged

Need to know where project is up to Some - rare - have adapted their mechanisms to allow for agile

Process use understanding One major project has had agile accepted by PCB

One project went agile, did analysis, found funding was out 50% and closed

BA and group create vision scope document - 20 pages to get ballpark funding.

PCB often wants more detail before committing

61

Interviews Categories and Themes 1 2 3 4 5 6 7 8 9 10 11

One major project has had agile accepted by PCB

Majority of PCBs require translation of agile artefacts to plan-driven

Earned value Slow burn rate brings focus onto what's not needed now / not urgent

Some buy into agile Use vision scope for initial funding Firm up / adjust funding as project progresses

Need to be happy that business and technology have agreed body of work

APRA requires plan-driven

APRA - not concerned with method; wants consistence

Agile projects "book ended" with plan-driven

Fixed release cycle with agile inside Gets things started High-level Gantt charts for PCB

Perception may lead to certain methods being prescribed for larger projects

Release acts as a break / stop fund. Can continue or not

Reporting on spending and progress Some friction from people used to the old way of doing things

can be worked around PCB

Monthly status reporting Quarterly funding stage gate Don’t want to see tests; instead know that all is okay

Want to know testing policy is in place and used

Sold on agile on basis large risk is dealt with early

Sold on Agile being an internal delivery mechanism

Testing Manual regression testing still done at end of cycle

Will always be some manual regression testing

Test results always attached to change control documents

Method Gaps No process gaps

Successful large hybrid project early production iterations dealing with risk aversion delivery / governance tightrope

62

Interviews Categories and Themes 1 2 3 4 5 6 7 8 9 10 11

Constant stream of internal and external reviews

Question of balance Agile not for:

Infrastructure Shared services Where there is more than one customer

Project working on customer data, i.e. have dozens of clients

Method Co-use Issues Dichotomy - certainty and agile Stakeholder differing priorities: client and management

Get sponsor to fight governance wars governance bodies shielded from agile

Financial tracking tool - doesn't really exist

No PM tools supporting mixed development

Project Managers High PM workload due to linear procedure aspects

work duplication Possible Future Activities for Improvement

Project manager training Making PM as discipline in organisation Establish a PM community Further agile adoption funding Internal agile coaching Use previous success to continue future methodology change

More funds for training PMs Use of Mingle needs socialising Standard Mingle templates Change culture through mass retrenchments and rebuilding

Mix of methods - pick and choose BA spends more time with business Feedback mechanism - keep track of how business uses system

Prototyping rather than Big Up-front Design

BA to test prior to software being handed over to testing team

Coaching required to educate business into agile benefits

63

Appendix C – Notes from Interview 1

Interview Date: 22nd June 2009

Interviewee

Interviewee Agile Experience – 3 years Interviewee Prior Experience

History in plan-driven development Agile Method

Project Previously documentation covered in PAM matrix – project methodology matrix – defined what needed to be done for PM document production. Test strategies, test summary reports, test plan documentation Formal but iterative – “under the covers” Using Quality Centre Acceptance testing only becoming automated in last 12 months Will soon have a full regression suite – to run after every build. Working on it. Currently developers do unit testing and formally hand over to test team. Converting across more stable parts of the system at the moment. Previous with Waterfall

development tends to run late squeezes testing time which was at the end and subsequently short on time. Made for long hours, ridiculous times, trying to deal with the most risky issues first.

If something was missed, testers were blamed Testers were swamped in documentation – hoped the documentation was up to date, or not renumbered.

Now Agile

Testers still get blamed for missing bugs, despite not putting them there Defects rates dropped – due to closer collaboration Put in place ‘verified statuses’ – another developer confirming correctness before code is passed to test group In 2007 had use cases –

Half agile – wholesale, half plan-driven – retail Agile team scheduled so ready 2 weeks before retail (waterfall) needed it or earlier if deemed high risk. Waterfall were always late. Testers were swamped in documentation – use cases, functional design, etc. – made understanding the functionality an effort. Found that documentation self contradicted. Developers were making assumptions which were invalid. After this testers became an integral part of the team and became the BAs – fixing a communication breakdown

Testers now drive requirements in order to get answers so that they can test properly

Look for the Why in the function request – establish objective / business value of change, rather than low level technical use case

64

Paradigm shift Story – who wants, what do they want, why do they want it, top level design, acceptance tests Team does story walkthrough

add new acceptance tests, ensures common understanding. Done one iteration ahead, so as to minimise unnecessary effort due to priority / requirements change. BA updates and distributes information based on meeting’s outcomes. Less documentation that use cases. (Some use cases are 140 pages – unreviewable!)

Planning meetings Attended by BA, development, test, PM Development points and test points How much done last iteration? Where are we at? How many days of resources available? What are priorities?

Testing works in same iteration as developers Testers can demand something be fixed ASAP if it’s blocking testing High degree of collaboration between developers and testers Testers

have become subject matter experts Know how system works because they’re busy trying to break it. field calls from users, and support staff (BAU) testers have overall knowledge whereas developers have in-depth knowledge of particular pieces become de facto system manual get to say “yes” or “no” on delivery of pieces of work role has evolved link test cases to stories

Need to talk to clients to get a full understanding Requires communication skills Days of “backroom boffin” are long gone – need to talk to clients.

Project Manager Works out schedule Talk to business about decisions that are required

Change requests Measures velocity Velocity charting and reporting With BA conducts showcases Outward facing activities Run PCB meetings Funding meetings – keeping money coming in Not running iteration planning – attends to keep on no things, and ensure no gaps

Any missed deliveries tend to be low impact high risk done early break story or move to next iteration

Tools

SharePoint

65

Method co-use Regressions still done at the end of a cycle – due to automated regression not being set up. Will always have some manual regression testing Test strategies PCB doesn’t want to see tests, but instead know that its going okay, and have a testing policy Business trusts as the team has a history of delivering, and testers tell the truth. PMs might stretch things a little. Sold agile to PCB on the basis that large risk is eliminated early on. Agile is internal delivery mechanism Change control is always done – auditors can see that. Test result attached to release document or change controls – physical sign-off

In future:

BA needs to spend more time with business. Currently doesn’t have time. Need to actively discuss more Tester asked to conduct training. Took BA and BA ended up gathering more requirements Need them to be the experts, not Bas

Feedback group – mechanism for confirming business process will be continuing as is. Ensures mechanism used for testing is as business would do things. Get rid of big up front design – even some functional specification

Use prototypes instead. Enables quick understanding Get BA to do some testing prior to testing group receiving batch of work? Otherwise as is.

66

Appendix D – Notes from Interview 2

Interview Date: 11th June 2009

Organisation

People promoting adoption of agile New CIO focussing on management of people rather than how projects are delivered Practice capability that covers BAs, testers and developers – champions of agile. Does not cover project managers.

Interviewee

Interviewee Agile Experience – 3 years Works for program manager

Agile Method

Variety of Agile used – NUP Actual project more “Lean” software development – focussed on making processes as “smooth and frictionless as possible” – removing blockages

Agile Localisation – used external coach 2 week iterations Focussing on regular face to face communication rather than stated reports. Talk functionality that needs delivering to clients. Clients see not as project but as series of conversations about the application and the value it gives them. Don’t necessarily see agile. Current project

Introducing a new project to the business – 9 months to do everything Most requirements known up front – 80% Don’t change over time. Backlog is stable Extra 20% are details not well understood Release cycle once a quarter A number of interfaces = dependencies High focus on quality Acceptance tests are in the stories Developers use TDD 8000 unit tests – high level of code coverage – helping ensure high quality System testing is largely manual. Regression cycle is two weeks – part of the release cycle, rather than the iteration Testers are two weeks behind developers. Testers have task cards split into – planning and execution Testers do their own testing estimation Developers and testers know their own velocity Combined planning Need to do more customer education in future to lift engagement

Benefits

Reducing risk by focussing on high risk early Focussing on valuable benefits to business early Delivering software to meet customer requirements High quality – low number of this project. Don’t want to be spending time fighting production fires.

67

Client is happy with software and delivery. Can be a bit invisible to the client – back end Managing system benefits on the way through. Not just looking at them at the end.

Adoption Assistance Adoption Resistance

External coach Tools

Story cards TDD Refactoring Quick Test Pro – for tests. Not much automated testing yet. Development done from 2005 – 2008 without automated testing. Iteration planning Story wall – magnetic whiteboard in this case – some resistance from building management Mingle – tried it.

Not a good document repository Formatting of stories and management of stories not great PM tool – very difficult to extract information that allows scheduling and tracking of tasks. A bit primitive. ThoughtWorks (supplier) sees it as a scheduling tool, not PM tool Need to see how long stories are taking, backlog, how many points was it worth, project standing, … Has no financial reporting capability

Uses an Excel spreadsheet list of stories, statuses, calendar of availability Can work out expected number of points that can be worked in an iteration Can show to program manager chart of costs, expected progress against stories and actual Create an “earned value” chart from completed work and cost Gives program manager enough information to determine if they need to spend more time on project. With conversations gives level of comfort.

Plan-driven

Retention What

opportunity document, business case, initial costing, high level requirements. Funding gate then happens to within a certain level of variance – gives budget, benefits defined status reports, PMO, stage gate funding, high level Gantt chart – show dependencies in and out

Method co-use

<Name removed> is overarching management methodology – plan-driven, waterfall focussed Business case PCB status reports - every month Stage / Funding Gates – every 3 months

Determines if benefits sold to business are still valid, costs, going to deliver what’s expected within a certain level of variance.

PMs are bridging the agile - plan-driven divide.

68

PM can choose which to use – look at what team is capable of. Case by case basis: people and requirements of project. In past projects measured against a plan. Agile measured against objectives and benefits. PMO has understanding that plan-driven though well established are not the “be and end all”. Cultural change journey happening Clash – financial tracking tools. Use timesheet system and put times into 6 week periods No PM tools supporting mixed development – plan-driven and agile.

69

Appendix E – Notes from Interview 3

Interview Date: 2nd June 2009

Interviewee

Interviewee Agile Experience – 2 years Interviewee Prior Experience – plan-driven consulting background

Agile Method

“Most of agile is common sense” Adoption settled – been in place 2.5 years. Variety of Agile used Hard to go back to working any other way. Agile Localisation Benefits

Focus - High quality delivery Quick deliveries Pilot and one other project were successes – removed from changes in CIO

New practice manager willing to expand use Led to case for further adoption

Good relationship with business & good management support Business was happy Reducing risk High risk done early Management buffers team from external distractions Roles within project team are well defined. Enable high performing team.

Adoption Assistance

Coaches – no answers to hard questions. Adoption Issues

Agile would struggle with a mixed or average team. Need good people. Agile is people and their relationships / interactions with each other.

Concern as to level of reporting Initially no product owner on the business side

Project Manager and Bas acted as business proxies, product champions Development team is driving product development to some extent. Business have been unable to translate idea of what’s wanted into requirements, due to product bringing together several discrete areas of business.

Each is not really interested in / know of other party’s requirements. Development team acted as bridge between.

Agile assumes development team always own system. Handover to support group is problematic.

Support has no background. Support are not technically savvy. Agile documentation – stories, acceptance tests - not amenable to handover. Support trying to maintain system on a day-to-day basis – can’t figure out. Support can’t see overarching story. Version 1 of handover document might be complete, 2 only have changes. If someone only reads 2, they don’t have the full picture.

70

Issue of handover from construction to transition Still haven’t worked out answer

Having support involved more with the development team is helping. No silver bullet yet. Support seeing showcases where appropriate – early days. Support staff changeover complicates things. Had to produce more documentation than pure agile requires Not one template – varies per product Plan-driven has handover phase. Agile not so clear cut.

Assimilation issues when testing team became agile. How do we estimate points? Testers: “what’s a point?” Changes of priorities can become political among projects with multiple major stakeholders. Still working out automated UI testing. Distributed stakeholders. One in NZ – talk to a lot on the phone

Mechanics

Did use mingle but have gone back to storyboards, although interviewee prefers mingle.

Mingle not good for capturing details for stories. User Interface applications - does not allow for input of lots of details very easily. UI is a very tiny part of the administration system – rules, calculations also

PM uses spreadsheet as source of proof. Demonstration held using collaboration tool as required. Demonstration not held so often due to nature of product – interest calculations, etc. A bit dry. Batch applications doing things. Retrospectives involve NZ BA Story telling meetings – held throughout the iteration to flesh out stories for the next iteration. Don’t do stand-ups – getting enough interchange without them Not pair programming generally. Used for complex or painful sections. Then used for knowledge sharing. Using TDD Build light – automated builds. Can be 30 minutes from check-in to deploy to test.

Client

Interaction with client is funnelled through BA. Plan-driven

Retention What

Kickoff meeting capture high level requirements Then generate some rough estimates and put into a high level release plan. Goes to business. Commonly understood roadmap. Key areas of risk identified up front. Resourcing, other PM stuff. Delay business decision to most appropriate moment.

System architecture where needed Change control

71

Why

Internal auditing – not as heavily scrutinised as other areas. Method co-use

Appear to have plan-driven – agile balance worked out. Worked out the fit. Some teams may break down one big release at end of project into two or three smaller ones – plan-driven like with some agility. Balance between methodologies can depend on which stakeholder involved and which PM is running the project.

Issues:

Equating points achieved into something useful for PCB and other stakeholders. How to translate into plan for PCB and other stakeholders Organisation – risk averse, always black and white. Agile is shades of gray.

72

Appendix F – Notes from Interview 4

Interview Date: 4th June 2009

Interviewee

Interviewee Agile Experience – 3 years Worked on project pre-dating official program

Interviewee Prior Experience

Plan-driven with first tier consulting firm – no going back Perception: “… it’s not rocket science”

Agile Method

Variety of Agile used OUP XP, test driven Scrum

Agile Localisation Expecting number of teams using agile to grow through osmosis, informally

Taking up familiar when methods aren’t being prescribed. At least using some aspects of agile. Overly prescriptive and lose benefits of people learning values that make agile successful – using what’s written down rather than thinking about context.

Osmosis happening when people see agile successful and want to emulate Composition of teams changing and agile people taking their experiences and ideas with them. Development manager looking out for opportunities to give people opportunity to move about and skill up others. Looking for cross-pollination. Much of agile adoption has been grassroots – will remain so. Change will be organic, word of mouth by seeing successes: higher quality low costs Actively looking for agile experience or agile capable (adaptable) people when hiring – will over time contribute to more agile organisation. Softer characteristics over specialist knowledge Benefits

People are buying agile Team which have adopted have a different approach to customer engagement and software quality Easier to change priorities than plan-driven Good attendances at retrospectives Software introduction happening earlier Funding may be extended as software is being delivered. Happy with what’s delivered so far so will release another chunk of funding. But could stop at any point. Development teams working regular, not extended hours – not working into ground PM community starting to be more open to agile. Inside conversions Larger projects waterfall – still missing dates, missing budget, scope quality in long hours Agile successes have tended to be on smaller projects

73

Adoption Issues Cross of cultures – problem area Some people are not willing to change

Method of getting people to change has not included enough consideration about change process. Some teams not sufficiently skilled to take agile on board. Can’t do agile estimation, agile planning due to not tight enough feedback loop

Constant battle to get clients into a role that can drive the customer side of agile, so use proxies to get information Situation with clients is not ideal but it works Customer reticence may ease as tertiary courses (MBA, etc) start mentioning agile as a valid methodology – having to deal with reticence in the meanwhile. Mentions of agile / Toyota lean manufacturing as side rather than acknowledging is now mainstream. Dealing with customers has been hit or miss. Ideal world: people who own customer relationship need to more advocates of agile – drive it more.

Tools

Team Play – timesheets, project charging PFS – funding – take data from Team Play

Mingle – not Tried it Not an improvement on Excel

storyboard and index cards – tactile. Easy to scribble and draw on. Easily visible Planning meeting

Take story, break it down in terms of engineering tasks estimate points and ideal time for doing points – use previous velocity to determine future velocity

BA sets priority but team can give feedback -prerequisites, higher risk, etc.

Method co-use

Projects “book-ended” with plan-driven methodology. Agile during delivery. Delivery mechanism strictly not prescribed in plan-driven approach. Front end: business case. Funding, benefits, how the project will be governed Back end: benefits realisation Project governance does not define how the delivery is done.

High-level Gantt charts for PCB or equivalent – 8 to 12 week duration level. Agile

will juggle priorities within that. Sufficient level for detail for PCB PM convenes and runs PCB meetings. Frequency could be fortnightly; could be

monthly Reports on spending, progress Plan-driven: earned value, versus agile stories delivered or velocity – can be a graph or worm chart of value delivered, stories delivered. (plan versus actual) Report says X done in last period Earned value is fuzzy – burn down is black and white

APRA Not agile savvy Not so much concerned about method of governance but is interested that the governance is consistent and predictable for a project and makes sense

PCB perceptions made lead to certain method being prescribed. (For larger)

74

Some friction from people used to the old way of dong things – information that be obtained from a project. Can be worked around – more an issue with individuals rather than systemic Would like to change the slowness with which funding approval happened and funds released – not necessarily an agile issue.

75

Appendix G – Notes from Interview 5

Interview Date: 1st June 2009

Organisation

30 different primary data repository systems. Middleware message buffering Interviewee

Interviewee Agile Experience – 1 year Interviewee Prior Experience – not agile No Going Back Made job easier – know where you are. Consistent delivery.

Agile Method

Islands of agile commitment in a sea of waterfall

Benefits Outstanding success No formal measure but Teams that have taken up agile are on time and on budget – seen as rare Giving business what they want Waterfall previously problematic, with formal requirement sign-off. Change in requirements during development. Client thinking has changed – moved on. Sense that technology is not delivering. More responsive – clients really like this PM loves agile – sold on it. Allows them to do reporting, budget management. Agile give transparent progress tracking. Means don’t need to dedicate time to managing team tasks as would be the case in waterfall. Team doesn’t get in PM’s way Cultural shift for PMs from boss to coach / facilitator More horizontal team structure BAs as customer proxies works, representing business. Does preliminary large block prioritisation with business. Dealing with requirement risk. Guiding requirements. Dealing with system interactions which a client might not understand. Not so much needed for tight system that stays within business boundaries.

Adoption Assistance Coaches

assisted adoption worked with software development competency group worked with projects with team on agile activities brought agile method they were used to

Way forward is internal coaching? Use previous agile successes to push for future methods

Adoption Resistance

Conservative organisation Used to sign-offs, responsibilities, due process, specific stage gates Waterfall has been embedded for some time, led to conservatism about agile Governance bodies shielded from agile.

76

Resistance more from some PMs and BAs – may be due to only some teams getting training, so agile unknown. Seeing other teams being agile and not understanding. Comfort in known processes – waterfall and sign-offs = know what’s expected Other PMs less taken – used to more hierarchical thinking and project management. Making sure everyone did their tasks on time. Some teams PM does not want agile but developers do = disconnect Some teams make multiple attempts to adopt agile but it doesn’t take – no trainer? More funds needed for training PMs Mingle use needs to be socialised. Standard Mingle templates. BAs don’t know where they fit. Used to writing detailed requirements documents. Now need to be customer proxies

No further adoption plans Implementation funding ran out 6 months later. Management restructure? Some teams embraced wholeheartedly Other teams didn’t get chance to use coaches and take it up

Mechanics Planning meeting Storyboard – no issues from building management Stand-ups held at storyboard Mingle

mirrors what’s on wall. Now being used to house test cases. Reporting tools PMs love. (Plan driven) Gives them visibility on progress, budget. Allows them to talk to peers, PCBs, while still relating to story board. Good crossover tool Gives visibility to all

SharePoint Wikis MS project at a very high level Estimation poker – uses cards, involves entire team Retrospectives Not pair programming

Formal code review – walkthrough – prior to going into test More traditional approach; more planned approach

Central repositories for tests cases, test runs – Quality Centre

Client

Now used to direct involvement, so expect it. Extra involvement puts pressure on client- don’t mind Regular interaction activities load Really like being able to change / add requirements and have implemented quickly, rather than wait while project is reshuffled. New priorities can go in next iteration SME’s available – wouldn’t have worked otherwise. Still expecting some plan driven reporting: budget, progress Card prioritisation Took a while to understand and commit to new methodologies Doesn’t necessarily know best place to get data Love showcases – helps settle priority disputes between multiple clients - makes team’s life a lot easier. Feedback opportunity.

77

Plan-driven Retention

What System architecture – retained due to potential for system interaction. System architects. Central architecture board reviews, gives sign-off. Plan driven - done up front. Provide guidance to teams.

Why – system interactions. Not muck up data. Not replicating existing functionality. Knows strategic directions

Dropped What – up front tasks minimised Reaction

Negative Positive

Method co-use

Projects run independently Development lead can influence process and methodologies used in a project. Has

developers comfortable with agile. Still a layer of formal sign-off above. Sign-offs: solution architecture, project planning documentation, budget, high level

features delivery schedule Teams left to use chosen methodology provided they’re providing burn-up details

and delivering Dev lead too down the food chain for PCB to worry about Mingle providing plan-driven like reporting functions for PCB review / auditing.

78

Appendix H – Notes from Interview 6

Interview Date: 27th May 2009

Organisation

People promoting agile – previous CIO Project excluded from agile programme Organisation Now:

Pockets of agile Distrust from others Some have no understanding. Need to be wary of any single agile failure being seen as systemic

Agile method

No further adoption plans.

Full requirements up front Agile success – failing project turned around

Requirements up front 6 – 7 week build cycles

Problems:

Dichotomy – want agile delivery but also time and cost certainty Stakeholder differing priorities: sponsor and senior management / governance. Upper management no buy-in Senior stakeholders require education on agile.

Stakeholder:

Relationship breakdown Increases in trust level allow for more agile. High PM turnover works against this Some teams gain trust with success, but are then restructured / redeployed. Get sponsor on side and use them to fight the governance wars.

Agile success:

vast improvement Business area head: “most successful delivery”

Adoption Method:

Piloting with smaller projects first = path to least resistance. Then build up Via CIO and CFO is far riskier.

Method Co-use

Actual project: Management require evidence of requirements Used test cases

done first used as functional requirements. Superior to written documentation

Introduced some production iterations to get credit / trust Risk aversion Delivery / governance tightrope/ Constant stream of external / internal reviews

79

Need balance on agile / plan-driven:

Changes with project size Communication Planning

80

Appendix I – Notes from Interview 7

Interview Date: 27th June 2009

Organisation

Organisation primary business – wholesale banking Organisation Technical Size - 500+ Organisation Length of Agile Experience Reason for introducing Agile - core team who had used previously People promoting adoption of agile – CIO

Interviewee

Interviewee Agile Experience – 18 months No Going Back Pragmatic use of methods Learn for each project

Agile Method

Variety of Agile used - OUP Agile Localisation

Traceability Audit Compliance

Benefits

High and risk delivered first Iron Triangle understanding Increased estimate confidence Understand actual position Scope and cost prediction better Customer sees showcase Increased immediacy with client Improved customer satisfaction Increased frequency of rollouts

Adoption Assistance

Provision of Coach Adoption Resistance

Not from technical teams Governance groups Increased demands on clients

Introduced from bottom up No further adoption plans Tools

Story wall Share Point repository Acceptance criteria – word templates Quality Centre – test repository Mingle – starting to replace story wall

Downtime

81

Client Customer sees showcase Increased immediacy with client Improved customer satisfaction Exceeding customer’s expectations. Also delivering ‘nice to haves’ Increased demands on clients Buy-in happening Involvement Increased

Plan-driven

Methods used in conjunction with Agile – based on PMBOK Retention

What - all Why – enhance probability of success

Dropped

What – up front tasks minimised Reaction

Negative • Scepticism • Indifference

Positive Exceeding customer’s expectations. Delivering ‘nice to haves’

Governance / audit body undergoing a learning curve need information appropriately packaged Need to know where project is up to

Method co-use

Process use understanding No process gaps

Waterfall less productive

82

Appendix J – Notes from Interview 8

Interview Date: 15th May 2009

Organisation

Organisation primary business – wholesale banking Organisation Technical Size – 500 - 1000 Organisation Length of Agile Experience – 18 months People promoting adoption of agile – previous CIO

Interviewee

Interviewee Agile Experience – 1 year Agile Program still alive – teams being given the option to do agile training Developing a project management tool that works with either agile or plan-driven workflow. Agile Method

Variety of Agile used – SCRUM like Agile Localisation – some Broad spectrum of Maturity with Agile. Development maturity assessments being done. Stand-ups, top-down versus lateral structure – some only paying lip service. Team self –assessment at 40% - 60%, working on improving. Using star pattern diagram Not all projects have customer representative Mixed success:

Varying degrees of customer engagement Younger team more amenable Some teams going agile then assessing benefits afterwards

Benefits

(Historical divide between business and technology. Has led to some bad blood.) Adoption of agile – to respond to business needs quickly. Plan-driven too slow Looking for customer satisfaction – in general higher, although some hiccups. Customer sees showcase – satisfaction dropped one iteration when showcase forgotten Increased immediacy with client Reflects reality, conversations people are having, rather than plan-driven artificial Keeps stakeholders engaged Gathering requirements as project proceeds. Regular feedback.

Adoption Issues Physical barriers Introduced from bottom up, not to project managers

created friction and resistance PM not going to retrospectives or team meetings – 3 separate PMs Seen as rogue Hierarchical structure creating issues for those up the hierarchy

83

Linear procedural requirements underpinning everything – release management, change management controls, sign-offs. Keeping PMs too busy Duplication of work

Mechanics

Visio – used as storyboard tool. Posted to whiteboard in team space. Stand-ups Retrospectives Mingle not used, by a lot of people. Acceptance testing done in iterations – continuous makes acceptance stage gate easier, but not all do this Flat team structure

Plan-driven

Dropped Project Approval Matrix = forms, not done consistently Can negotiate what’s not done , although some get around document requirements

Retention

What – business case, opportunity document, project management plan done in background

Project review Why – regulatory reasons - APRA Documentation rigour Business case -> requirements. In fact do not have all requirements at project

inception Method co-use

Tool being developed to support either workflow Do bare minimum for plan-driven then use agile for the actual development Work back from delivery dates Issues: Gaps:

Train project managers Making project management a discipline Establish Project management community

Client

Sometimes does not know or care agile is happening.

84

Appendix K – Notes from Interview 9

Interview Date: 19th June 2009

Interviewee

Interviewee Agile Experience – 7 years Interviewee Prior Experience – waterfall, rapid application development Came into the organisation to apply agile experience on “skunk works” project Organisation was fixated with PCBs, control boards, stage gates

Agile Method

Adoption assistance – external coaches used. Interviewee is in an internal coach Business analysts are being used as operation managers – facilitating day-to agile mechanics. Showcases – restrict to what’s fully functionally complete, visible on a screen, fit for purpose. Otherwise too contrived for business. They would focus on the contrived data, which needs to look as much as possible like production. Sometimes need to use an embryonic UI; otherwise too plan-driven like. Kick start workshop up front for project, phase, release, develops framework for what needs to be achieved, how everyone is going to operate, expected behaviours, what’s to be done. Set tone for release – time to market or quality? Set out up front. Something will have to give. Benefits

Don’t develop things that aren’t needed. Dev team pushes very hard to get the business to define business value for changes. Asks: “what’s the value in doing this piece of work?” “Why spend 5 weeks working on something that will take 10 years to recover value?” Previously nobody was looking at benefits. Agile breaks things into small chunks, of which people can readily assess the value. Enables business to effectively determine priorities. Also changes are now expressed in business terms, not technical terms. (Use example.) In actuality a hybrid, a compromise/ Works to a certain extent. Bulk of agile works. Some bits don’t. Worked out some compromises and can work rather than being stuck on principle. Where engaged like the common language, seen good results, understand what it’s about. Working but not ‘proven’ in their minds. If business benefits are not realised then figure out why not and fix. Whole group ownership – technology once spotted a business process problem.

Not good enough to just tick off that requirement delivered. Technology are part of the value delivery stream. Attitude not widely held in technology organisation. Would not be happy with a technology member who delivers software that does not add value.

85

“Software business is not about producing software; it’s about adding business value.” Okay to say, we don’t want to waste your money. We can see an easy alternate. Businesses are receptive to this.

Adoption Process

Who sought business buy-in? Business had been told what was happening but not why, or benefits. Coaching by development teams required to train up business in the why. Big bang is bad idea. Too much inertia in a large organisation. Win people over slowly with education. Business is not there for methodology. They’re there for outputs. Agile working well with engaged customers. BA’s come up with vision, jointly scope. Become facilitators; manage iterations, run workshops, ensure stories are lined up, get extra details if necessary. Try and keep Bas out of technical discussion. Engage when someone is needed to go back to the business, more than one stakeholder.

Adoption Issues

Some resistance from parts of business who don’t want to engage in thinking about business value for changes. Not prepared to drop some parts of the system that aren’t used. Hand over requirements and expect developers to understand know their part of the business. Business buy-in is not universal, despite knowing agile is a legitimate methodology. Hardest thing is getting key business people in. Use delegates where possible. Business people then realise amount of responsibility required for delegates, then empower or get engaged. Some just say: “here are our requirements”. Some want quick delivery and waterfall process controls – can’t do. Some groups tried with agile, but didn’t work

Wrong people pushing Ill equipped people pushing without explaining fundamentals Associated business feeling battered Doing stand-ups, iterations, but not really agile. Every time there is a crisis, everything is replanned. Area is suffering from fatigue change Business head in that misses the opportunity to walk over to technology and talk directly – wants more engagement. But need proper controls in place. Appropriate structure being put in place by interviewee acting as a coach

Many teams still waterfall, suspicious of agile. Processes about to become visible – scary. Working without sign-offs

Client

Try not to involve business in technology speak / issues; stick to business value. Otherwise, the perception is that the business is being made to do some of technology’s work.

Plan-driven

Organisation still has a lot of waterfall mechanisms / processes in place.

Method co-use Some PCBs have adapted their methods to allow for agile processes. “Few and far between.”

86

One major project has had agile accepted by PCB. Otherwise, agile artefacts are translated to plan-driven: burn chart -> earned value. Actually the same thing, but PCB prefer to see things in terms of what they know. Earned value gives a value of cost at end – gives PCB some choices. With agile can stop now and still get value. If burn is not as good as hoped form focuses PCB on what is no longer urgent, so that delivery date remains unchanged. YAGNI kicks in. One project went agile, did analysis, found funding was out by 50%. Determined not worth doing. BA and group put vision scope document out – 20 pages – and drive ball-park funding from that. PCB often want more detail. Some buy into agile. In which case use vision scope document, then firm up as project progresses. Certain fund will be bookmarked. Or get initial funding to do early agile stages and review further along. Get funding for initial workshop, and release plan. Determine x iterations, y people, so have a rough cost. Get funding for project initiation to get release plan which gives long term, big picture view of project. PCB needs to be happy with business and technology have agreed to bodies of work. Don’t need a hard plan. It will change. Bracketing agile with a more traditional control structure gets things going, started. Enable score use of agile. Fixed release cycle with agile inside. 4 to 6 iterations. With guaranteed funding. Release is a stop point, so project can stop there, or continue with more funding.

87

Appendix L – Notes from Interview 10

Interview Date: 2nd June 2009

Organisation

Organisation Length of Agile Experience – 18 months Reason for introducing Agile

Development process was broken Rumour of outsourcing all of IT – prevented by government regulatory issue “We’re going to pick the place clean” Use of agile to drive up quality, reduce risk of production failure

People promoting adoption of agile - CIO Interviewee

Interviewee Agile Experience – 4.5 years Interviewee Prior Experience – Ph D, another company before current

Agile Method

Project team – 7, mostly senior developers Variety of Agile used Agile Localisation

Process changes would lead to productivity decline during change period, so recruited as well. Philosophy, more bodies – more work done. Agile is about people foremost. Needs good people; good people skills, not back room introverts. Self selecting. Agile – processes facilitate commonsense activities

Benefits

Reacting to changing circumstances Clients – if trained, are most willing participants, watching their system develop. = “Just Magnificent” Clients determined priorities. Argue with themselves about stories in next iteration. PM kept programme manager away from team Coordinating players - facilitator Responsive to rapidly changed circumstances PM worrying about the big picture – dev team doing small chunks with real benefit Best PM kept distractions away from developers If business value is being continually delivered, business will find funds for more work. Requires transparency Flatter structure works better.

Adoption Assistance Agile coaches

Issues

Had a real read-hot go, but lacked commitment to follow through. Cultural issues.

Structure of organisation is nearly a cancer. Upper echelons of IT organisation are not IT people. Don’t communicate the concepts about agile to upper echelons

88

Some hard work to get clients to the point where they understood how agile worked. Particularly given not on time not on budget history Result = mixed bag

Top down adoption – no expectation setting for upper management From clients usually at start of projects – gets broken down

Tools Build lights installed Mingle

Method co-use

Invisible to developers, particularly when project is working well Long term direction being managed by PM

Future:

Mass sackings and rebuild to achieve cultural change rather the change what’s already there re-jig the organisation Analogy: demolish house and rebuild rather than do extensive renovation.

89

Appendix M – Notes from Interview 11

Interview Date: 3rd June 2009

Organisation

Organisation Length of Agile Experience – 18 months Interviewee

Interviewee Agile Experience – 18 months Transferred from informal to formal agile processes

good experience brings discipline

Agile Method

Variety of Agile used Agile Localisation Current project plan-driven small pieces of work.

Systems interfaces to accounting system Informally iterative from project outset to assist client with learning what they wanted Became formally agile after visited by an agile mentor (internal) – project had already been going for a year.

Part of stabilising and continuation of project – outsourcing had been considered

Project considered successful – agile contributed to this. 5 stakeholders; 1 primary 2 BA are proxies – collates requirements and prioritises Primary BA demonstrates new functionality to clients in Sydney Team demonstrates to local stakeholders Agile driven by developers and development practice. Remote BA is business focussed rather than project focussed. Able to succeed as department nurtures agile – not true across the board

Team has been agile to shift its agile plans when some plan-driven teams have not delivered dependencies. Benefits

More realistic then plan-driven: allows for changed plans, changed ideas, changed understanding and makes that it’s focus Enabled new products in a timely manner Needed to be adaptive, flexible to change understanding and direction as business matured and took off. Good business engagement – 5 key stakeholders, collaborative Achieved outcomes that teams twice the size haven’t in the amount of time PM is hands off with the deliverables – focuses on funding, project management, big picture, financials

Adoption Assistance

internal Adoption Issues

Main sponsor in Sydney Directions, priorities have changed dramatically and quickly

90

BA there is focussed on business rather than the project – business process and requirements. Could be more fully engaged with team Not present in retrospectives Some disconnect between BA and development team

Recently become more engaged. As a result of team taking on challenging business changes and requirements

Requirements gathering can be a challenge: translating from business speak to technical speak

Some areas not appropriate Infrastructure Shared services Where not one customer Project working on customer data – dozens of clients, need to schedule and view of workloads – linear timeframe

Tools

Video conferencing Instant messaging Storyboard Formal showcases – no; informal yes Continuous integration tools Testing tools Ms Project

Plan-driven

PM presents plan-driven approach to PCB while team does agile. Hand back funding for pieces not done, get funding transferred PCB seems happy – shielded from agile mechanisms – getting the information they want PM is interface Started plan-driven, and gradually bought into agile nature of business and technology Some angst in transition but saw what agile gave the team

Method co-use

Mix of methods in the future – one size does not fit all Conflicting requirements, conflicting deadlines, conflicting customers = plan-driven, so everyone knows what to expect Isolated projects – dedicated and directed - agile