Author: Adi Kalkan
Supervisor: prof. dr. T.M. van Engers
Master Thesis
Studentnr.: 5947243
Information Studies: Business Information Systems
Faculteit der Natuurwetenschappen, Wiskunde & Informatica
Universiteit van Amsterdam
Oktober, 2014
Amsterdam
OUTSOURCING AND AGILITY
New perspectives on the agile relationship between
1
AbstractEver since the agile manifesto was issued, agile development methods have gained a lot of attention. Despite the popularity, the combination of agile development and outsourcing has been not been given much attention in the literature. In society more and more projects are a combination of these two new phenomena. However, many projects still do not meet their objectives. Therefore, this study investigated how principals can manage their vendors that work in an agile matter. In order to be able to distinguish the literature and place the provided solutions into perspective, new categorizations were needed. This thesis made a distinction between output-based agile outsourcing deals and the non-output-based agile outsourcing deals. With this new categorization, the literature could be placed into perspective. The current literature was placed into two newly created frameworks. These frameworks indicated the current state of research. After identifying the grey areas in the field of agile outsourcing projects, a field study was conducted. Seven employees of prominent organizations were interviewed. Using a combination of grounded theory and case studies, new insights on how principals can manage such complex environments better, were found. The field study revealed new and promising methods for principals to manage their vendor better. These solutions can be taken in the pre-project phasing and during the project to increase the chances of success of the project. This thesis has contributed new insights to the literature, such as a new categorization in the literature, new frameworks and new insights and solutions to manage projects in an agile outsourcing setting.
2
Voorwoord
Het schrijven van een scriptie, of master thesis, is een leerzaam, leuk, maar ook lang en lastig traject.
Zonder hulp van anderen zou het schrijven van dit werk nog lastiger zijn geweest. Ik wil daarom graag
mijn dank uitspreken aan een aantal personen.
Allereerst wil ik mijn scriptiebegeleider, Tom van Engers, bedanken voor zijn wijze raad, hulp en
advies. Zonder de hulp van Tom zou ik niet in staat geweest om dit werk af te leveren. De discussies
over agile ontwikkelen, onderzoek doen en tal van andere onderwerpen (soms ook buiten het
onderzoeksonderwerp) waren niet alleen leuk, maar ook leerzaam. Ze gaven mij de stimulans om
verdere diepgang aan te kunnen in het stuk. Ondanks Toms drukke schema wist hij altijd tijd te
vinden om naar mijn stukken te kijken en feedback te geven. Toms hulp bij de scriptie en het vinden
van respondenten stel ik daarom erg op prijs.
Tom, heel erg bedankt voor je begeleiding en hulp bij de scriptie!
Ook wil ik Foppe Vogd van CIO platform Nederland hartelijk bedanken. Zonder de hulp van Foppe en
het CIO platform zou het een stuk lastiger zijn geweest om respondenten te vinden voor mijn
veldonderzoek. Het vinden van respondenten is voor elke studenten een lastige opgave, zeker als je
beslissingsmakers moet vinden. Met de hulp van Foppe en de leden van het platform heb ik
voldoende respondenten kunnen vinden om het onderzoek te kunnen verrichten. Het enthousiasme
van Foppe, het platform en de leden van het platform, hebben mij niet alleen verder geholpen, maar
ook geïnspireerd om het onderzoek te verrichten. Mijn dank hiervoor wil ik nogmaals uitspreken.
Mijn dank gaat ook uit naar de zeven respondenten, die ondanks hun drukke schema met mij in
gesprek wilden over hun ervaringen. Ook stel ik het op prijs dat zij niet alleen hun eigen ervaringen
hebben gedeeld met mij, maar ook hebben durven spreken over projectresultaten die soms goed en
soms iets minder goed zijn verlopen. Mijn dank hiervoor is groot en graag zou ik ieder van jullie hier
willen benoemen. Omdat ik jullie anonimiteit heb beloofd en de informatie op vertrouwelijk basis is
gedeeld, kan en mag ik jullie namen hier helaas niet noemen. Maar ik ben ieder van jullie zeer
dankbaar voor jullie hulp en openhartigheid. Heel erg bedankt!
Tot slot, wil ik ook mijn vrienden en familie bedanken. Hoewel dat teveel namen zijn om hier op te
noemen, wil ik jullie wel laten weten dat het zonder jullie steun (bijna) een onmogelijke opgave zou
zijn geweest om deze scriptie af te ronden. In het bijzonder wil ik mijn ouders en mijn zussen
bedanken voor zowel hun praktische als morele steun. Ik wil verder jullie allemaal hartelijk
bedanken! Thanks!
Allen, hartelijk dank voor jullie hulp, raad, advies en steun!
Adi Kalkan
3
Content
Cover………Front page
Abstract………..1
Preface……….2
1. Introduction………..4
2. Literature study………..5
2.1. What is agile development?...5
2.2. Differences between Agile and Waterfall software development………6
2.3. Overview of the literature………8
3. Conceptual model……….17
4. Methodology……….21
5. Field study results……….……….23
6. Discussion……….33
7. Conclusion………36
References and Bibliography……….38
Appendix A: Figures and tables………..42
Appendix B: Examples of the coding process………44
4
Introduction
“Why Agile can work for complex systems like HeathCare.gov” (Morelli, 2013). This article is just one of the articles many in the heated debate on the portal that was supposed to support the Affordable Health care act, also known as ObamaCare. The portal that should have allowed millions of Americans to buy an affordable health care insurance package failed to perform properly. This failure was not only expensive (Radnofsky, 2014), but the responsible minister also had to step down as a result (Davidsen, 2014). After this failure, the main stream media (e.g. Depillis (2013) in the Washington Post) pointed out that the government had given the tender to a company that used a traditional approach for their system design, and that the contract was set up in a traditional way. However, although the contractor used some iterative approaches during the development time, it failed to be agile and the project was categorized as an old fashion waterfall project (e.g. see Depillis, 2013).
Although it is not certain that using an agile approach would have led to a successful outcome, there are some indications that an agile approach could have prevented some problems (Depillis, 2013). Depillis (2013) reported that the front-end of healthcare.gov was successfully created and she suggested that this was because of the agile procedure. The Standish Group, that annually investigates the successes and failures of IT projects, has found that smaller and more agile projects are much more likely to succeed (Standish Group, 2013). With this in mind, it might be argued that agile development can help organizations to successfully create and implement software.
Agile development methods have gained a lot of attention since the Agile manifesto was issued in 2001. This manifest, created by the practitioners of some mainstream development approaches, has a different
approach than more traditional development project management methods. There are a number of often used agile methods. These approaches share the same principles and believes (see e.g. Abrahamsson, Warsta, Siponen & Ronkainen, 2003). It states (among others) that the interest of the customer is preferred over the interest of the pure contractual compliance (Highsmith & Cockburn, 2001; Berger, 2007). However, unlike the classical waterfall method (where the requirements are set in advance), within the agile approach the requirements are more flexible and less rigid. These approaches rather have an iterative focus in which feedback and testing plays an important role. This might mean that the requirements could (slightly) change over time (e.g. Highsmith & Cockburn, 2001; Jamieson, Vinsen & Callender, 2006; Berger, 2007).
Although many practitioners and scholars recommend using an agile approach within software programming, the focus of the researchers varied, from financial outcomes to code quality. Dyba & Dingsoyr (2008) found that most studies on agile approaches suggest that there are benefits for all parties (the principal and agent). Vijayasarathy & Turk (2008) for instance found that many software developers have reported benefits from using agile approaches, such as an improvement in code quality. Reported benefits, are among others, a quicker time to market and financial benefits (Dyba & Dingsoyr, 2008). Dyba & Dingsoyr reported that several studies suggest that the customer can become more involved if agile approaches are used. Although there are benefits if a principal selects an agile development method, many principals, who try to hire a firm that can develop their software, find it hard to select a vendor. Using a clear procurement procedure, when the
requirements are not clear and when there are less rigid cost indications, can be very hard. This tension has also received some attention in the literature. Jamieson et al. (2005; 2006) have also investigated the use of agile approaches by both the agent and the principal (customer) and agile procurement more specifically. However, once this procurement is finished, it is still unclear how these relationships should be managed. In 2007 Berger conducted a (very limited) case study on this issue. Although the project she investigated was a success when compared to the cases where both parties would have used a traditional approach, the project was still a failure in financial and timeliness terms (Berger, 2007). Other experts have testified, in front the Dutch parliamentary commission on failing governmental IT projects, that the relationship between the vendor and the principal was not properly managed and that even agile projects failed (transcript Interview day 3 with mr. Mathijssen, parliamentary inquiry, Elias et al., 2014, p.24). Although it can be argued that more agile procedures will also be beneficial for the principal, there is lack of consistent categorizing and the number of researched solutions is limited. The literature mainly discusses the use of agile methods within teams or internal software development. Agile projects contrast with the more rigid waterfall method, which leads to differences in the expectations between the vendor and the principal (e.g. who will pay for changes in requirements, who carries the risk, when does the principal need to intervene, financial risks, market risks and etc.). In the past, researchers have
investigated to some degree how agile methods can be combined with outsourcing. Batra (2009) for instance adapted some of the agile principals to make them suitable in outsourcing situations. However, Batra's article was only theoretical and was not tested (i.e. no case studies, surveys or document studies were deployed). Although there are some researchers that have studied the perception of agile methods by customers and have investigated the collaboration with customers (e.g. Hoda, Noble & Marschall, 2010), most of these authors have studied the application of agile methods mainly from the perspective of the vendor. Sutherland, Viktorov, Blount & Puntikov (2007) have described some best practices on how to deal with offshore and outsourced teams. However, their research implied that the customer and the vendor will create the software together, and in which the principal has a lot of knowledge to lead such a project in detail. There is little research on the actions of the
5
customers or clients1 (principals), certainly in the cases where the core competency of the customer is not ITrelated. A number of other authors have investigated similar issues as well, but the literature lacks consistency in general, and often categorizations, (empirical) evidence, and definitions. Furthermore, although there are many articles that present case studies, theory is often lacking (which is a general critique in the information systems literature, see e.g. Gregor, 2006; Levy & Ellis, 2006). Therefore, there is a gap in the literature on the way the principal can deal with a vendor that uses an agile approach when developing software commissioned by the principal. This thesis will try to investigate the following question in order to solve these issues and contribute to the literature on information systems:
“How can organizations (the customer/principal) manage vendors that use an agile approach within their software development?”
The outline of this document is as the following. First, a literature review (chapter 2) will define the concepts ‘agile’ and ‘agility’. After that, the differences between the traditional and agile approaches will be discussed. Furthermore, the current relevant literature will be discussed in this chapter. The third chapter will conceptualize the relevant literature into a conceptual framework. The fourth chapter will describe the
methodology that was used in the field study. The fifth chapter will describe the outcomes of the field research. Next, a discussion section will discuss the outcomes, the implications, and limitations of the research. Finally, the conclusion will answer the answer the research question and provide an overview of the thesis.
2. Literature review
This chapter will discuss the most important, currently available literature on agile outsourcing and management of such projects. However, before discussing the current literature, the terms agile and agility will be defined. After that, the differences between agile approaches and traditional approaches will be discussed and the current state of the literature will be reviewed.
2.1. What is agile (software) development?
The terms agile and agility have been used in different contexts, in both general industrial literature as well as in the software industry. In the early ’90s the Iaccoca Institute published a book in which the authors advocated a new way of manufacturing, which they called “agility”. This new manufacturing concept was driven by the change and the ability to react to changing market circumstances (Yusuf, Sarhadi & Gunasekaran, 1999). In later literature, the term agility was extended to include other business settings. For instance, Overby, Bharaswaj & Sambamurthy (2005) extended this term to enterprise agility, which they define as “the ability of firms [to, red.]
sense environmental change and respond appropriately” (Overby et al., 2005, p. 296). Firms should be able to
notice any changes in their environment (e.g. market circumstances) and respond appropriately depending on the change (see also Overby et al., 2006). However, the terms agility and agile are more broad and are therefore separately defined by Overby et al. Based on other literature2, Overby et al. (2006) state that “the term ‘agile’ is
commonly used to describe firms that are able to adapt to and perform well in rapidly changing environments”
(Overby et al., 2006, p.120).
In the software development industry, the term was introduced in the agile manifesto (Beck et al., 2001). The manifesto was a response to the customer expectations and the failing traditional waterfall approaches (Highsmith & Cockburn, 2001). The manifesto states that agile methods are methods that place “individuals and interactions over processes and tools, working software over comprehensive documentation,
customer collaboration over contract negotiation, responding to change over following a plan” (Highsmith &
Cockburn, 2001, p. 121; Beck et al., 2001). Several software development methods that can be used to manage software development within teams meet these criteria. Abrahamson et al. (2003) for instance consider SCRUM, eXtreme Programming (XP), Adaptive Software Development (ASD), Crystal family of
methodologies, Pragmatic Programming, Internet Speed Development (ISD), Feature Driven Development (FDD), Dynamic System Development method (DSDM) and Agile Modeling (AM) as agile methods. Although there are many agile software development methods, not all methods are equally popular in practice. Recent research has showed that the literature does not always represent the actual practices. For instance, commercial surveys (e.g. VersionOne, 2013) suggest that SCRUM is by far the most used approached, followed by XP. A recent article by Hummel (2014) showed that XP is the most researched agile method, while SCRUM is in practice the most applied agile method. The underrepresentation of SCRUM in the literature is due
1 This thesis uses the terms principal, client or customer, to refer to the party that gives an assignment to the vendor. These terms are used as
synonyms in this thesis. Since the word customer is used both in the agile manifesto (see Beck et al.) and articles such as that of Hoda et al. (2010), the term customer is used more often.
6
to the fact that it is much easier to investigate some of the XP related principals (e.g. pair programming), than classic SCRUM related issues (Hummel, 2014).Although the use and definition of the terms agile and agility varies per industry and setting (business or
enterprise agility vs. software development agility), the general outline is that agility is the ability to respond
appropriately to changes in the circumstances under which the organization operates. These changes can vary from changing market circumstances, to changing legal circumstances and other changes that require a rapid and adequate response. This thesis focuses on how principals can find and manage vendors that use an agile method during the development and the phases before and after the project (if applicable). Since the timeframe in which this thesis was written is too short to fully investigate all the aspects of both enterprise agility and software agility, this thesis will look at agility from the perspective of software (component) development, while keeping in mind the general purpose of agility, which is to respond to changes in the market. This means that, although software development will be investigated, the thesis will also focus on what managerial aspects the principal has to take in order to manage the vendor and to turn software projects into a success in a outsourced agile setting. Therefore, in this thesis, when referring to agile approaches, agile methods are meant. More concrete,
agility in this thesis is defined as software development methods and corresponding management methods that allow the firm to be able to better adapt (before, during and after the development) and perform in rapidly changing environments, inspired by the principals and values of the agile manifesto (based on Overby et al.,
2006, p. 121, and Beck et al., (2001)).
2.2.1 Differences between the waterfall, intermediary and agile methods
As mentioned in the previous subsection and the introduction, the agile development methods, such as SCRUM of XP are a clear breach with the traditional way of software development. The waterfall approach emerged in the sixties, when most information systems were long-term projects with stable and predictable requirements (Cusumano & Smith, 1995). Cusumano & Smith (1995) state that the waterfall approach requires first input from the designers. They have to write the requirements and specifications as detailed possible, these specifications are split afterwards in parts and assigned to individuals or teams. These developers code the parts in parallel and only test it locally. After the coding is done, everything is put together and integrated. This usually requires a certain degree of rework, since there is not much communication during the building and changes might have sneaked into the design in meantime (Cusumano & Smith, 1995). The pitfalls and disadvantages of the waterfall approachwere soon very clear. Cusumano & Smith (1995) suggest that the waterfall approach should only be used if the projects requirements can be controlled in every detail and rework does not affect the customer in any way. Furthermore they recommend not using a waterfall approach if there is any uncertainty in the market, since this might lead to changes in the requirements. In the ‘80s more flexible approaches emerged (Kataja &
Tuunanen, 2006). These models, called general iterative approaches by Kataja & Tuunanen (2006), are a combination of the waterfall approach and the iterative processes. They for example create mini waterfall projects (in some cases even for just one feature or issue) during a larger project. In these cases the requirements are only frozen for one aspect (that is dealt in the mini waterfall project) (Paetsch, Eberlein & Maurer, 2003; Kataja & Tuunanen, 2006). However, as one can image this is still not perfect, since again a lot of things are done in parallel, while the feedback is still quite late. In the ‘90s the agile (see section 2.1) methods, such as XP and SCRUM were introduced (Kataja & Tuunanen, 2006), in response to the problems found with the previously used methods (see e.g. Highsmith & Cockburn, 2001).
2.2.2 Core differences in the principle – vendor relationship within the methods
Some of these principles and values of the agile manifesto create a different approach in project management by nature, in comparison with the waterfall approach. For instance, delivering working software every few weeks and using working software as a key performance indicator to measure the progress is directly in contrast with the waterfall approach. Other values and principles, such as combing business people and technical people in one team, are not necessarily in contrast with the waterfall approaches. As described above, the waterfall approach consists of about six (Cusumano & Smith, 1996) or seven (see Wikipedia waterfall model page, n.d.) phases, while agile approaches are less rigid and consist of repeated shorter cycles (and not in a sequence, but more repeated tasks every cycle). These six or seven phases will be compared to an agile approach to highlight the differences.
The first step is the detailed design phase. This phase aims to design (Cusumano & Smith, 1995) the whole system in detail (Cusumano & Smith, 1995) and it therefore also enables principals to find vendors that are able to deliver these requirements. The second phase is the detailed design phase. In an agile approach, such
7
as SCRUM, the design phase occurs also at the start (or actually before the start), but continues and repeats itself during the every sprint (Wikipedia page on SCRUM, n.d.). As described previously, these steps in the waterfall approach are plan-driven and long term orientated (see e.g. Cusumano & Smith, 1995; Kataja & Tuunanen, 2005), while an agile approach is more short term and cycle orientated. In a waterfall approach, the management of when things have to be developed and how software is designed, occurs at the beginning of the project, while in an agile approach, such as SCRUM, features and priorities might differ from week to week. Therefore it may be easier to keep the architecture and the teams efforts close to the chosen IT architecture in a waterfallapproach, than in an agile approach. It also reflects on the pre-project, phase since the principal has to negotiate a good deal with the vendor. However, to fully work agile, some flexibility should be built in.
The other four3 steps described by Cusumano & Smith (1995), module construction and debug,
Integration and system test, module rework and finally, re-integration and system test, are completely different
in an agile approach. Agile approaches are iterative, and all these issues are dealt at once in an agile approach. Due to the setup of approaches such as SCRUM, the changes of miscommunication are less likely. One team works on the project and the team members discuss the progress and issues on a regular base. However, if bugs or incompatibilities still exist, they are dealt with much more rapidly (i.e. during the current or next sprint). The feedback from the customers is provided constantly, and priorities are reorganized every sprint. In contrast to the waterfall approach, in which priorities are only set at the beginning of the project and feedback is only provided at the end. Since the feedback procedure starts much earlier, rework is often not necessary, but the principal has to make sure that the feedback is delivered in a proper and timely matter. Furthermore, the measuring of KPIs is different, and therefore also the principal’s actions. In an agile approach, every sprint needs to end with working software. This means that the principals should provide feedback and direct the vendor if the development goes in a wrong direction. In a waterfall setting, there is no obligation for the principal to direct and control the vendor. A benefit of this is that the principal holds no responsibility and does not need to intervene, the obvious disadvantage is that principals might figure out too late that the vendor has not build a proper product and it might increase the costs in the long run.
2.2.2.1. Risks and goals differences among the approaches
Beside the more obvious differences that can be derived from the agile manifesto, there are some other more subtle differences. One interesting paper, that describes the differences in the relationship between the vendor and the principal in both a waterfall and an agile approach, is the paper by Kataja & Tuunanen (2006). The authors refer to work of Eisenhardt to discuss the agency theory. Although explaining this theory falls out the scope of the thesis, it is interesting to discuss a few key elements of Eisenhardts4 paper, since those elements are
relevant for the relationship between the principal and the vendor. One interesting notion of the theory is, that the agency theory discusses the tension between the two parties when it comes to risks and goals. This theory5 states
that the agency problem entails that the agent has much more information than the principal, to the degree that the principal cannot find out whether the agent has used his power properly or abused his power, and where both parties have conflicting goals (Eisenhardt, 1989a; Eisenhardt, 1989 as interpreted in: Kataja & Tuunanen, 2006). However, Eisenhardt also states that there is a specific division of risks and outcomes. One of the assumptions of the agency theory is that the principal is risk neutral, while the agent is more risk averse. In behavior based contracts (similar to the non-output-based agile outsourcing, see section 2.3) the risk is for the principal, while in outcome based contracting (similar to output-based agile outsourcing, see section 2.3) the risks shifts to the agent (i.e. vendor; Eisenhardt, 1989a). The implications of the risk division are interesting, because it might predict the behavior of the vendor in an agile setting. Eisenhardt suggests that if the uncertainty is low “the costs of shifting
risk to the agent are low and outcome based contracts are attractive” (Eisenhardt, 1989a, p.61). This indeed
applies to the vendor in an agile setting. However, in an agile setting, requirements and the outcomes are often more loosely defined (see e.g. Paetsch et al., 2003), which leads to a higher uncertainty for the vendor in an outcome based setting, or to a higher uncertainty for the principal in a non-output-based setting. If the uncertainty is still low, than the risks are also quite low for the principal in a non-output-based setting.
3 Other sources (e.g. Royce, Wikipedia page on waterfall model, n.d.) describe five other phases, but these phases are highly comparable to
the ones described by Cusumano & Smith. It should be noted that some of these have a different focus (i.e. they assume no rework is needed), and often include other phases such as the ‘use’ or ‘production’ phase (see e.g. Wikipedia on waterfall model, n.d). However, these five phases will both be compared together with the four phases of Cusumano & Smith, in order to compare it to the agile approaches
4 Eisenhardts research focusses also on the use of information systems as a way to reduce information asymmetry. However, Eisenhardts
interpretation of the term information system is broader, and does not necessarily refer to technical aspects, but more general to control mechanism such as reports and people/management (see e.g. Eisenhardt, 1989a, p. 61).
5 There are many interpretations of the agency theory. It should be noted that the focus of Kataja & Tuunanens article (Kataja & Tuunanen,
8
Kataja & Tuunanen (2006) have investigated the information asymmetry in waterfall, iterative and agile settings. They have compared the Finnish standard IT outsourcing/development contract, IT2000 standard, with the principal-agent theory in all settings. They suggest that in a waterfall setting the information asymmetry is the largest, and the lowest in agile settings due to the presence of the a principals representative in the
development (as Kataja & Tuunanen, 2006, interpreter agile outsourcing)6. They also noticed that most contracts
(and therefore most organizations) focus on a waterfall approach and found that the Finnish standard c
contractsontradicts with the principal-agent solution and still leaves too much space for conflicting goals (Kataja & Tuunanen, 2006).
One specific unaddressed issue in the work by Eisenhardt (1989a) is the case of knowledge or technical
capabilities asymmetry, rather than information asymmetry. Although the principal can be informed about things
such as the development progress, or the results of the development, the principal might not have the required knowledge to assess the information or to lead the development in an non-output-based setting, while in an outcome based setting, the principal might not have knowledge to fully interpreter the information (acquiring that knowledge might be expensive). Kataja & Tuunanen (2005) mention as a condition to prevent this
asymmetry is to have a principle who is able to understand the issues and has the proper capabilities. However, if the principal is unable to do that, it can still invoke both moral hazards (i.e. vendor abuses his knowledge advantage, see Eisenhardt, 1989a) and adverse selection (principal is unable to assess the capabilities of the vendor, see Eisenhardt, 1989a).
In a waterfall setting, moral hazards might be more likely to occur, since there is there more information asymmetry, while the adverse selection can be dealt with pure contractile (complain at the end if the delivered work is inadequate and hold the vendor liable since, unlike within the agile approaches, the principal is not involved and therefore has no obligation to step in). In an agile setting, adverse selection is likely to be spotted much earlier, since the principal is “present” during the development (see Kataja & Tuunanen, 2006), in comparison with the waterfall approach, where the principal might not see it. However, adverse selection is not fully excluded since the principal might not be able to estimate the capabilities of the vendor in the
(pre)contractual phase. The article does not discuss solutions for this specific issue. Furthermore, although the article by Eisenhardt (1989a) provide interesting insights about outsourcing settings (behavior/non-output-based or output/outcome based), from a “risk” and “conflict of interest” point of view, and might provide interesting comparison with the waterfall approach, field studies in the agile world are not presented.
2.3. Current state of research
The relationship between the wishes of a(n) (internal) customer and the developers have been investigated in many articles. Most of these articles focused on the use of agile methods within the own organization, meaning that all stakeholders are in the same organization. However, the research on the use of agile methods between several firms (i.e. when the customer/product owner is outside the development form) is less extensive. For instance, Hossain, Babar & Paik (2009) identified 366 papers on the usage of SCRUM in global software development in 2009. However, since there are more agile methods, the number of actual articles on agile methods (if for instance XP is included) is even much higher. In contrast, the number of articles that focused on globally outsourced software development, in combination with agile development was (in the literature published between 1999 and 2009) only seven (Jalali & Wohlin, 2010). In the years after that, there were some articles written about the cases in which the development is outsourced. Basically, in the literature, roughly two types of agile outsourcing can be identified. However, before discussing those two main types, the general agile outsourcing issues will be discussed first.
2.3.1 General issue with agile outsourcing
The previous section defined what agility and agile are. This subsection will discuss general issues with agility and outsourcing before discussing the more specific types of agile outsourcing. In the literature, the relationship between vendor and principal attracted some attention. Batra (2009) for instance has outlined a theoretical solution for the use of agile method when the development is being outsourced. Although the article leans more towards output-based outsourcing (see below), it will be discussed separately in this subsection because some aspects of the principals developed by Batra (2009) are relevant for both categories. Batra's article focused on outsourcing significant components to agile vendors. Therefore, this article can be a part of both categories. The first notable distinction made by Batra (2009) is to identify that the customer can be more than one customer.
9
According to Batra (2009), there is often an intermediary between the customer and the vendor. In many cases, when a business unit wants to have a certain information system, they will request it from their IT department. The IT department will deal with the vendor and potentially also the development of the software. However, according to Batra the intermediary can also be a consulting company that helps the client to manage the development outsourcing. Unlike other articles on agile development, Batra makes the distinction that there are not two main stakeholders, but three. This might have interesting implications on how the principal deals with a project that is being developed (depicted in figure I, appendix A).Besides identifying the stakeholders, Batra also identified the potential problems that agile development has when it is applied to outsourced projects. An overview is depicted in table 1, in appendix 1. Some issues are less relevant for the second category (when the customer is not involved with any technical productions), while others are more relevant. Some issues, like the strict contractual negotiation, the unwanted change/cost issues and strict contract compliance, are directly in contrast with the agile principles. Batra (2009) has compared the agile principles to the potential advantages and disadvantages of the agile principles, as depicted in table 1 (appendix 1). It should be noted that Batra does not identify any potential benefits for either the customer or the vendor when it comes to the principal of collaboration above contractual negotiation. Batra (2009) is also quite negative about the ability and willingness of changing requirements. According to him it will not go without (much) higher costs. This would imply that the usual benefits of agile developments such as the welcoming of late changes in the requirements is not easily possible, or only at a high cost. The next section will discuss the literature on both categories of agile development (mixed teams (non-output) agile development, and full (output) agile outsourcing) in more detail.
2.3.2. Output-based development vs non-output-based development
As mentioned above, there are two main extremes in agile outsourcing settings. Although no earlier categorization of these two extremes was made, it is made here to place the current literature better into a context.
First, there is the case where the labor is contracted, but where the client is part of the development team (e.g. by providing the product owner, or scrummaster and actively involved in directing the team and team individuals). Those teams are often quite mixed with personnel from both the customer and the vendor. The research on such situations focused mainly on scaling the agile principals for those teams, certainly if the teams are geographically separated (e.g. Sutherland (2007) see also Sauer (2006) for a brief literature overview of this type of outsourcing). An examination of the article by Sauer (2006) shows that the main concern of these articles is how to deal with practical issues, such as how to communicate. The solutions provided in these articles are often obvious, for instance many authors suggest to use telecommunication (e.g. calling or videoconferencing) when physical meetings are not possible (see Sauer, 2006 for a list of solutions). Many of these articles
considered the staff of the vendor as regular employees. Therefore they were de facto only hiring manpower, but not actually outsourcing the development itself. The Forrest research report by Moore & Barnett (2004)
explicitly suggests to create one team, mixing it up in such a matter that de facto (not explicitly mentioned by Moore & Barnett) all employees feel like they are working for the same company. However, a limited number of articles (e.g. Sutherland, 2007) actually look at how customers can manage the vendor and provide actual solutions to issues like contracting, financial control, planning, acceptance and so on, whereas the other articles mainly focused on scaling agile principals to offshore locations. In this thesis, this category of agile outsourcing will be defined as 'mixed teams agile outsourcing' or ‘non-output-based development’, to distinguish it from the second category. Furthermore, it should be noted that the non-output-based agile outsourcing, focuses a lot on directing the actions of the vendors staff, making this type of outsourcing and the underlying agreement similar to a behavioral contract as described by Eisenhardt (1989a). However, there are some differences since the control of the principal is much tighter on the vendor than it is in the general principal-agency theory. The other line of agile related outsourcing literature takes the perspective where the development is solely done by the vendor and a certain outcome is negotiated in the contract. The customer has a limited role in the development itself. The customer of course directs the development in terms of requirements, acceptance and cost control, but the projects are not managed as-if the vendor employees are their own employees (which might be a hidden assumption in some cases in the first category). Therefore, the management of the type of
outsourcing is per definition different than in the cases where the teams are mixed up. This category will in contrast to the mixed teams agile outsourcing, be defined as 'full agile outsourcing' or ‘output (or outcome) based outsourcing’. The words “output-based” and “outcome based” refer to the fact that the agreement between the
10
vendor and customers requires some output or a certain outcome7, i.e. working software or a product at an agreedtime (thought the contractual dates may be variable). These type of outsourcing deals have some similarities with the general idea of the outcome based contracts described by Eisenhardt (1989a). The word full in this name, refers to the fact that the developers are employees from the vendor. This does not imply that the customer has no role in the development at all. The role of the customer can vary.
Two extremes can be distinguished in this second category. Hoda et al. (2010) identified situations where the vendor hides the fact that he is using agile development methods, where the customer does not know that the software is not being developed in the waterfall methods as agreed and the customer does not know the feedback is being used for sprints and etc. This is the undercover agile method. In these cases studying the perspective of the customer is almost impossible, if the customer does not know the software is being developed agile, he does not direct the software development. Therefore, this extreme in this category is left out of this thesis. The other extreme is the situation where the customer knows that an agile procedure is being used and even adds an employee to the team (e.g. a business analyst who can serve as a product owner; in Hoda et al., 2010, more situations are described). However, in between these extremes there are many subcategories, such as where customers are supporting agile methods, but the contacts are mainly made through the customer proxies (as described by Hoda et al., 2010). The second extreme situation in the second, output-based, category, is quite similar to the first category of agile (non-output) outsourcing. The line between the two categories of agile outsourcing can sometimes be hard to distinguish. In cases where it is hard to distinguish the two, the factual situation will be taken into consideration. If employees of the customer are involved with the technical aspects (e.g. checking or writing the code) and no output agreement is made (e.g. the vendor is paid by the hour only or a output determined by the amount of code) than it will be placed in the first category, mixed teams agile
outsourcing/non-output-based agile outsourcing. If employees of the customer are only or almost only involved with the functional aspects, but not with the technical aspects (they do not do any coding or review of the code quality), the situation will be considered as part of the second category and a certain outcome is negotiated (full agile outsourcing/output-based agile outsourcing). This distinction is not based on the literature (the literature on agile outsourcing is relatively new and currently no distinction is made between the two types of categories, since most articles only studied one form of outsourcing). However it is necessary to distinguish them since the control mechanism are different. The distinction is related to the contracts described by Eisenhardts (i.e. behavior vs. outcome based contracting).
It is logical to assume that the methods to manage vendors are different for the two categories because of several reasons. Therefore, the literature on both categories will be review separately in the next section. As mentioned previously there is a lot of literature for the cases in which the customer fully directs every detail (e.g. Moore & Barnett, 2004), and there is a lot of literature on IT outsourcing where the customer is not involved in the development at all (the more classical literature on outsourcing, e.g. Earl, 1996; McIvor, 2000). However, there is a gray area where the customer and vendor are both involved, which is basically an assumption of many agile methods (e.g. SCRUM, XP). Figure 1 depicts this issue. On the left the non-output-based outsourcing is depicted. In those cases the customer is also responsible for the staff of the vendor (e.g. hiring developers from the vendor). At the other end of the spectrum is the fully output-based outsourcing, in which the vendor a specific product at a certain date and there is no customer involvement. However, since many agile approach (e.g. SCRUM, see e.g. Paetsch et al., 2003) insist on a frequent interaction between the involved stakeholder, there is a gray area. Although some research is performed on this gray area, not many took the point of view of the principal. However, before discussing the literature on the two categories of agile outsourcing, first the article by Batra (2009) will be discussed because this article outlines a theoretical view on agile outsourcing. After discussing the literature on agility and outsourcing, a conceptualization will be made, which could serve for test purposes.
Figure 1:
7 One of the respondents (P1) suggested that it better to speak of outcome or output (as translated into English by Platform Outsourcing
Nederland) based outsourcing, rather than full agile outsourcing. In his view that is more clear. The organization “Platform Outsourcing Nederland” (website PON, n.d.) uses output-based contract to describe a similar phenomenon. However, in their definition, they also speak about agreements on pricing (which can be more flexible in agile situations, as described later in this thesis).
Non output-based outsourcing Output-based outsourcing
Customer fully involved in development Customer not involved in development
Green indicates the level of amount of literature on the topics. The literature on non-output agile based outsourcing is slightly more available in comparison with the output-based agile outsourcing.
11
2.2.3. Management of non-output or non-outcome based projects, principals perspective
As mentioned in the previous section, the first category of agile development outsourcing is the one in which the employees of the vendors are often merged with staff from the customer(s) or where the final responsibility for the actions of the vendors is placed upon the principal. There is a lot more research on this type of outsourcing, than the plain (full) output-based agile outsourcing. For instance, Moore & Barnett (2004) already investigated the combination of outsourcing, offshoring and agile development. It should be noted that most of the articles on these mixed team approaches focused on the combination of these three elements. However, the offshoring related issues can be distinguished from the specific outsourcing and agile related issues. With regards to outsourcing and agility Moore & Barnett (2004) recommend several strategies. First, one integrated team should be made. It should be noted that later research (e.g. Hoda et al., 2010) showed that customers do not always can or want to commit to that (i.e. those companies fall therefore in the second category). Therefore, this advice by Moore & Barnett (2004) should mainly be applied to the mixed team agile outsourcing or the non-output-based types of outsourcing. Another advice is to treat the staff from the vendor as-if they are employees of the customer. Moore & Barnett (2004) provide many more advices, but those are mainly aimed at the offshoring component and therefore fall out of the scope of this thesis. Although these two authors see a lot of benefits in agile offshored outsourcing, they see also many issues. According to this research of Forrester by Moore & Barnett it is not possible to immediately start using agile methods when you are offshoring the development of for instance important systems or applications, because the risks are unclear. They recommend onshoring and using agile development before considering offshoring or outsourcing.
Sauers literature review from 2006 also focused on the existing literature that mainly covered these issues. Many of the solutions provided in the literature studied focused on the aspects of general agile
development, such as a proper communication between the two of three parties that are involved. Other articles have made similar suggestion. Kussmaul, Jack & Sponsler (2004) have also suggested variations on existing agile principles. However, in 2007 one of the creators of the agile manifesto, Sutherland and a number of fellow practitioners issued a paper, describing the types of distributed agile development based on experience and case studies.
Sutherland et al. (2007) investigated, just like Moore & Barnett (2004), the combination of offshoring, outsourcing and agile development. Sutherland et al. (2007) identified three types of team settings. The isolated SCRUM teams, which basically leans more to the second type of outsourcing ('full agile development
outsourcing'), where the developers are completely isolated from the principal. The second type they distinguish is the 'distributed SCRUM of SCRUMs'. This type of outsourcing, is where SCRUM masters hold their own SCRUMs and hold separate sessions together. The third type Sutherland et al. (2007) distinguish is the 'Totally Integrated SCRUM', where virtual SCRUM teams are formed and work together. The collaboration in the totally integrated SCRUM team is fully according to the general SCRUM principals, as-if it would be a small local SCRUM team. Though the development is often left solely to the vendor, the customer supplies the SCRUM master and the product owner. Therefore, the line between the totally integrated SCRUM and the full agile outsourcing is often thin. However, since the customer in the examples of Sutherland et al. (2007) are coordinating the communication fully (e.g. the meetings and so on), this type of agile outsourcing will be considered as the mixed teams agile outsourcing.
Later research on this type of outsourcing is highly related to the articles summarized by Sauer (2006) and the articles of Moore & Barnett (2004) and Sutherland et al. (2007). For instance, a case study by Cottmeyer (2008) also suggested some best practices such as creating one integrated SCRUM team. Just like Sutherland et al. (2007), Cottmeyer (2008) also discussed the use of tools to track the performance of the vendor, in order to see the contractual agreements. Other research papers also focused on contractual issues (and the practical solutions such as how to solve communication issues). For example, besides Cottmeyer (2008), also Sachdev & Iyengar (2007), Hoda et al. (2010), Batra (2009), McGinnes (2013) discussed contractual and cost issues. These issues are often also present in the second category of agile outsourcing, the full, output-based, agile outsourcing and will therefore be discussed separately.
The next section will outline the output-based agile outsourcing in order to investigate the literature on the other, harder to manage, style of outsourcing.
12
The previous chapter discussed the situation in which the contact between the customer and vendor is very intense. Since the employees of the customer and the vendor work together in one team, the control and management is totally different than in the situation where all the development is done by the vendor. As previously explained, the degree of outsourcing in this category may vary. In some cases, the customer does not even know that the development is done with the agile principles in mind, while in other cases the customer sometimes for instance takes part in the SCRUM (tough not always for instance; see Hoda et al. (2010) for an overview of experiences with customer commitment and agile development). The degree of interaction between the customer and vendor that is situated in between these two extremes, is depicted by Batra (2009) in figure 2, appendix A.The situation described in figure 2 (appendix A) is quite explanatory (but not the only option) for the second type of agile outsourcing, the full agile outsourcing. The development is done fully by the vendor, and the customer (being either the end-user or the intermediair) does direct the development, but is not technically involved. This also implies that the customer does not necessarily take part in the SCRUMs (but it does not exclude the client either from the SCRUM meeting), as for instance Sutherland et al. (2007) have suggested as best practices. Although there are many benefits of creating one team between the customer staff and the vendor employees, it might not always be feasible. For instance, Hoda et al. (2010) have researched why the customer commitment is sometimes inadequate in terms of the agile principles. They have noted that the customer representative often does not have the time to be a part of the development team. Furthermore, the insights from that study showed that customers often do not have the required knowledge to be able to develop something in an agile matter. Also, it might not be the core competency of the customer. The case study by Sutherland et al. (2007) was conducted in a situation where the customer was an IT company and the core competency of the researched firms was software creating and selling. Moore & Barnett (2004), as well as Batra (2009) have suggested to direct the development in an agile manner. However, in all those cases the customer took the initiative to work in an agile manner, skipping the fact that not all customers might be able to do that, or the vendor might want to suggest the use of agile process because the customer for instance cannot properly identify all the requirements in a proper manner. The articles by Moore & Barnett (2004), Sauer (2006), Sutherland et al. (2007) and Batra (2009) expect a high degree of customer interaction, because they are all focused on customers that already have enough knowledge about agile development and that want to offshore because they want to save costs. However, there are also other reasons to outsource the development of software to a vendor. For instance the reasons for outsourcing can be found in cost reduction, but also in the fact that a company might want to outsource everything that is not a core competency (see e.g. Saunder, Gebelt & Hu, 1997; McIvor, 2000; Quelin & Duhamel, 2003 Slack, Chambers & Johnston, 2010; see Prahalad & Hamel (1990) for a general discussion on core competencies).
Hoda et al. (2010) found (a number of) customers that do not want or are not able to be (very) committed. However, those customers can still benefit from agile processes by the vendor, since changes in requirements in a later stage should be possible and the software is being delivered more timely. Furthermore, the software is often better tested and better designed to meet the needs of the customer. Even though one integrated team might not be feasible, that does not exclude the customer from selecting an agile vendor or the vendor might even suggest such an approach.
This second type of outsourcing is better suited in those situations. However, the literature on that type of outsourcing is relatively scarce. One of the first articles on the issue of full agile (or outcome based) outsourcing is the article by Martin, Biddle & Noble from 2004. Martin et al. (2004) have examined the role of the agile method, XP, and looked at the situation with outsourcing. Unlike other articles, the article by Martin et al. (2004) takes the full agile outsourcing view, meaning, that unlike the articles by Moore & Barnett (2004) or Sutherland et al. (2007), the customers employees are not necessarily part of the development team. In many XP set-ups the customer is usually somehow part of the team (see e.g. Wikipedia page on extreme programming, n.d.), however, the exact role may vary. The research by Martin et al. (2004) found two cases, one in which the agile development contributed to the success and another one, in which two of the three involved parties complained about the agile methods.
The difference between the two cases, the one that succeeded and the one that failed, was quite remarkable. The one that succeeded had less customer interaction than the one that failed, which is contrary to the agile principles. However, it should be noted that there were quite some issues with the project that failed. The first case, that was a success, had some issues, but those are mainly related to contractual issues. According to the participants, it was a success because there was no fixed price contract. That created issues because of the fact that there was a lot of uncertainty with the customer when something was considered to be done (Martin et
13
al., 2004).The other project was a failure, due to several issues in the process. Although the participants appeared to be much more intense involved (the customer and/or it’s representing consultancy firms were permanently on site), it failed because of several reasons. One of the most prominent reasons why it failed, is because the onsite access to the customer was not used at all. The vendor did not want to show failures and the vendor and the customer did not trust each other at all. The customers representatives that were onsite were not involved in the process at all. They only saw demo’s but did not do any testing (Martin et al., 2004).
In the years after, research has also been conducted on how customers can manage their vendors. Many articles again concentrated on the combination of agile methods (mainly XP, however sometimes also SCRUM), outsourcing and offshoring. In 2007 Sachdev & Iyengar investigated the psychological contract between customers and vendors, and the trust between the two parties. Though their solutions where leaning more towards the first category of outsourcing, some contractual aspects (as well as those from McGinnes (2013) are also relevant for the full outsourcing aspects. In 2009 Hoda et al. started a (new) line of research towards the management of agile outsourced software projects.
Hoda et al. were not the only ones to noticed the gaps in the agile related literature. Svenson, Birgisson, Hedin & Regnell (2008) also found the need to see how requirement engineering is performed in the situation where the customer is not a part of the development team, yet where the vendor is using agile approach (more specific SCRUM) to create the software. Although the paper by Svenson et al. was written from the perspective of the vendor, it has some interesting findings. Svenson et al. suggest that the customer should first be informed about the two possible paths, the traditional requirement based setting and the agile approach. If the customer does not want to choose the agile approach and does not contribute closely to the development, Svenson et al. (2008) suggest that a staff member of the vendor should take over their role (de facto they suggest the use of a customer proxy (see Hoda et al., 2010), though they do not mention that). They however do suggest traditional contracting in those situations, while suggesting different and more dynamic solutions when the customer agrees on the use of agile methods. An interesting aspect of the Svenson et al. is the tender price issue, which is not always mentioned in the agile related literature. If the customer accepts the agile approach, the customer should state what the business value should be and what the high level requirements are. If the customer is not closely involved8, the vendor should fall back on an internal employer to act as a customer proxy (though not using that
term). After this is set-up, the customer and the vendor sign a contract with a variable scope with a target-cost agreement (see the next subsection for the discussion on costing and contracting). Svenson et al. (2008) present the Agile Requirements Abstraction Model, to implement the traditional customer requirements into the an agile environment. The first step in the model is to identify the high level goals, next these requirements should be place on a certain level (e.g. product level, feature level, functional level, component level). Third, the
requirements should be matched with the original ones or new ones should be created in collaboration with the customer. According to Svenson et al. (2008) the fourth step of documenting the requirements doesn't apply for customers that agree with an agile approach. However, one could argue that documenting could clarify a lot. Svenson et al. argue that since the customer is familiar with what is entered in the productlog, that
documentation about that is not needed.
The next notable article in the field of customer-vendor interaction, was the article by Hoda et al. (2010). This article reviewed the reasons why customers are not committed as described in the SCRUM approach. It should be noted that in the cases wherein the customer lacked participation at all, these projects all fall under the category of full agile outsourcing, since the client was mostly not onsite. This article in particular found several reasons why customer are not involved enough. The reasons they found included skepticism, time limitations (at the customer), distance factors, bureaucracy and incompetent representatives of the customer (Hoda et al., 2010).
Another article in the field on full agile outsourcing is the article by Hong, Thong, Lewis, Chasalow & Dhillion (2011). This article investigated the reasons why customer would want to agree with an agile approach from a psychological point of view. In this research they found that the willingness to accept change, is a good predictor whether the user (i.e. customer) wants to accept agile methods from the vendor. In the previously discussed articles (e.g. by Moore & Benett (2004), Sutherland et al. (2007) Batra (2009)) many authors took the point of view wherein the customer requests the vendor to use an agile approach. That immediately suggests that these customers are anticipating on requirement changes. However, in other cases (see e.g. Hoda et al., 2010)
8 Some authors (e.g. Beardwood & Shour, 2011) have suggested that the customer is onsite at the vendor. However, as found in the
interviews and literature, there are more options. In some non-output-based settings the vendor was on the location of the principal (not the other way around), while in some cases they were not in the same location, but had daily or bi-daily contact.
14
vendors suggest the use of an agile approach. The article by Hong et al. (2011) suggests therefore that customers that are not fully sure about the detailed requirements or anticipate at important changes in the future (e.g. in the case that they foresee that they are leaving their current status quo)9, are willing to accept agile practices. Sinceagile approaches are more beneficial in those situations, it is interesting to note that even when the customer fully wants to outsource the software development, they should perhaps aim to select a vendor that uses an agile approach. Although not mentioned in the literature, one could suggest that in cases where the customer is more open to frequent changes, the company can control outsourced projects better if the development is done in an agile manner. Other issues identified by Hong et al. look at the use of agile approaches for further release(s). It was found that among others a better experience, and supporting facilities are predictors of a preference towards agile approaches.
As noted earlier, there are almost no articles that deal with the every practical aspect of outsourcing and agility. However, as mentioned earlier, some parts (besides the principal-vendor interaction) have been
mentioned in the literature, such as the (pre)contracting issues (e.g. Jamieson et al, 2005, 2006; Hoda et al., 2009, 2010; Svenson et al., 2008; Batra, 2009), financial specific issues (e.g. Eckfeldt, Madden & Horowitz, 2005; Hoda et al., 2010; Batra, 2009), requirements engineering (e.g. Svenson et al., 2008). These aspects will be discussed separately in the upcoming sections.
2.3. (Pre)Contractual issues
This section will discuss all the precontracutal, contractual and financial issues that have been noted in the literature. Since precontractual and financial issues can be distinguish from the interaction based literature (output vs non-output-based management) these aspects will be discussed separately. Jamieson et al. (2005, 2006), Svenson et al. (2008) and others have noticed that how request for quote (RFQ) is issued can be important for the further management of the projects. Therefore, the precontractual part will also take some aspects of the vendor selection into consideration, before discussing the other parts. After the precontractual issues have been discussed, the contractual and financial issues will be discussed.
2.3.1. Precontractual issues
Selecting outsourcing partners is not always easy. Although many articles have been written on vendor selection, the literature on agile vendor selecting is scarce. One of the reasons why the literature on this aspect is rather thin, is the fact that most studies on agile outsourcing were conducted in commercial companies. Most literature also concentrated on offshoring, which requires a different approach than selecting onshore partners. Certainly if governmental organizations are trying to find an outsourcing partner it can become difficult if it is combined with an agile project. In many parts of the world, such as the United States, the European Union (see Wikipedia page on Governmental procurement, n.d.) and Australian governmental organizations (see e.g. Jamieson et al., 2006) are required to issue open tenders, where every interested vendor can make an offer. However, to be able to judge the offers, the requirements need to be clear in advance. This can lead to a tension with the agile way of working. If requirements are set up in a tight matter, many prescribed agile methods are perhaps hard to
accomplish. Legal requirements might lead to tight technical requirements. The article by Jamieson et al. (2006) recognizes that current tender procedures in governmental environments often fail, and therefore investigated the use of adjusted procedures to get value for money (VfM). They assessed several variations on the current procurement methods, for instance a variation on the concept enhancement activity method. In that case, it is de facto an internal tender activity wherein vendors are asked about their capabilities to build the final system. After a short list is created, some suppliers will be selected to create for instance a prototype. The customer pays the vendors to do some development work. That way hesitations, that vendors usually have, about opening up their intellectual property will be reduced since they are paid for their development work (Jamieson et al., 2006). However, the ultimate solution would be a situation with a dynamic VfM model. This model consist of several gates (inception, several go moments). The first phase will be a fixed price contract and an agreement on how to define the costs at the other stages (Jamieson et al., 2006). It should be noted that the intellectual property should go to the customer according to the authors, which, although not explicitly mentioned by Jamieson et al., that would allow the customer to switch from vendor. Therefore, such an approach would reduce the vendor dependability.
In the years after the research by Jamieson et al. (2006) not many articles have been issued on the vendor selection in procurement procedures in combination with agile development methods. However, some
9 Abcouwer & Parsson (2011) have discussed how companies can for instance deal with change and also gave an interesting literature
15
authors have discussed precontractual issues. Although many previous articles have made some suggestions in terms of agile operating vendors in earlier stages (e.g. Moore & Benett, 2004), most of the research focused on commercial companies. Since these companies are not required to use public tender, research on those aspects is less relevant. However, some authors have still looked at those situations. For instance, as mentioned in Svenson et al. (2008) the request for quote can either be from a commercial or governmental organization. The way a tender is issued, is of importance on how requirements are created according to Svenson et al. (2008). However, the research by Svenson et al. (2008) was from the perspective of the vendor and not the customer. Jamieson et al. (2006) show the situation from the customer perspective and therefore suggest some options for customers to issue a tender. Besides the articles by Jamieson et al. (in 2005 and 2006), there is almost no related literature on this issue. However, whether the tender or selection is done in a traditional or agile way, the contractual and financial issues in the content of the contract are important for both corporate as well as governmental organizations.There is some literature on the way the negotiations take place in the pre-contractual phase. Hoda et al. (2010) found that many customer might be skeptical towards agile practices. They found that agile operating vendors have found creative solutions, such as selling a certain a number of iterations. Furthermore, they might convince customers of approving agile methods by giving them ways out (swap features, exit clauses). However, these aspects focus more on cost and agreements and will therefore be discussed in the next section.
Financial and contractual issues
As mentioned previously, there are several ways to control the project from the customers perspective. The way the project is managed depends on the type of customer collaboration there is. As mentioned, in the cases where the customers employees are very involved in the development teams (for instance in the Sutherland et al. example), it is much easier to see what the vendor has done and how it was dealt with. For instance, Sutherland et al. (2007) suggest methods to measure the performance of the vendors' employees by tracking the number of hours that were made. In cases where the costumer and vendor are less tied together, it is much harder to properly estimate the costs of a project.
One of the previous sections discussed the article by Batra (2009). Batra argued that vendors might not be willing to accept changes in requirements in a later stage, at least not without charging something for it. This implies that a fixed price is not preferred by vendors. Some vendors have also stated that. For instance, Eckfeldt et al. (2005) stated they prefer not working with fixed prices. This is a logical assumption in an agile
environment. A fixed contract might not be ideal for the client either. For instance, the client and vendor might argue about the actual scope (see Eckfeldt et al., 2005) or in cases of a tender there might be an incentive for the vendor to do as little as possible (and always choose the cheapest options; see Svenson et al., 2008).
If, after every sprint (in SCRUM), the customer can request changes or new functionality, that might be a risk for the vendor. On the opposite side, a fully variable contract (time and material contract) might also be problematic. In agile approaches requirements might be set in a less tight manner (see e.g. Praetsch et al., 2003), leading to perhaps even vague agreements. The customer might be afraid being ripped off by the vendor (Hoda et al. (2010) found such behavioral with some customers), since the customer might think (s)he is giving a blanc cheque to the vendor. However, there are several solutions mentioned for this issue. Although one might try to convince the customer of the benefits of agile development and pitfalls of traditional contracts (Hoda et al., 2010), there are also some practical solutions found. For instance, Hoda et al. (2010) found that some vendors give certain right to customers. For example, the customer and vendor might sign a contract with a tight set of requirements. However, the customer perceives the right to swap features, if during the project they find out that another feature is more of importance for them. Another options is to convince the customer to buy a limited number of iterations. If the customer is not convinced by the efforts of the vendor, the risks are limited to a small portion of the initial estimated amount of money. A different option that was used, was the use of termination clauses, which allow the customer to quit the project at any time. However, besides adding such clauses to standard contracts there are also other types of contracts that might offer a solution. In the literature, some authors (e.g. Eckfeldt, 2005; Svenson et al., 2008; Chan, Chan, Lam & Chan, 2011) have mentioned the potential use of target-cost contracts.
Target-costs contracts have been proposed by some academics and practitioners. For instance, Eckfeldt et al. (2005), as practitioners, have stated that vendors generally prefer time and material contracts, since the risk for the vendor is reduced to zero. However, customers do not want that. They have managed to convince their clients to use target-cost contracts. Target-cost contracts are contracts wherein the pain and the gain are shared (Chan et al., 2011). Eckfeldtet al. (2005) reported a case wherein such a gain/pain share was applied. In their case description they described that they first estimated the number of hours that was needed to complete the
