State of agile contracting in the software industry and the public sector, results of a systematic mapping of the literature

Context: Agile approaches are the answer to the rigid framework for traditional software development. These focus on creating products based on communication and continuous collaboration between the client and supplier, which are detailed characteristics in documents; it is also true that the contractual agreements for such approaches continue to be structured according to the restrictions of the traditional development of software products. Meticulous specifications and restrictions such as time, cost and scope are just some of the fixed conditions of the contractual agreement. In this sense, traditional contracts do not respond adequately to agile software development and, for this reason, agile contracts emerge as a framework of agreement that stipulates the conditions that are clearly necessary to allow development under these approaches. Methodology: a systematic mapping of the literature is presented that aims to show a current panorama of agile contracting for software development and its application in different sectors of the economy with an emphasis on the public sector. Results: The results obtained show few examples of the application of agile contracts, especially in the public sector; suggesting research opportunities and the generation of proposals in this context. Conclusions: It has been concluded that the contracting methods used by public institutions can be an obstacle to agile approaches. In addition, this document presents recommendations for adjusting contracts that seek to facilitate developments approached from the perspective of agile approaches in the public sector.


Introduction
Agile approaches emerge as a response to the rigid planning that was carried out in traditional software development projects [1], where aspects such as the scope, the specification of artifacts in the processes used for the construction of the product and / or service; It had to be precise, detailed and complete [2], unusual characteristics for the vast majority of IT projects where the contractual requirements and conditions were constantly changing. In this sense, the contracts were structured as an agreement mechanism in which rigid requirements were defined. In addition, complex protocols were stipulated for processes such as change management, updating and other improvement actions [3].
Derived from other strict sequential and inflexible engineering processes, traditional software development approaches are characterized by defining a series of phases that must be completed in a linear order; for example: Cascade, Incremental or Spiral models respond to that order. In this sense, the contractual agreement for this type of development method is structured with conditions to respond to this order [3]. In addition, the contract is not very flexible and open to change and is characterized mainly by establishing fixed restrictions on time, cost and scope [4].
These types of contracts were inspired by the models used mainly in classical engineering; models responsible for the construction of civil works [5], where human factors do not represent elements of high variability. However, its adaptation was not optimal for software development; on the contrary, it has brought some challenges and problems such as: exponential increases in costs during maintenance [6], low flexibility and adaptation to changing requirements; [2 ] although the client is important, the contracts for traditional development approaches stipulate minimum conditions for participation and only some activities are agreed upon which occurs mainly at the early stage of requirements elicitation and at the end of the project; this process is facilitated through the verification and validation of the product [2]. Unlike traditional approaches, agile contracts conceive uncertainty as an intrinsic characteristic of the software development process [3,7,8] which is closely related to risk management; its nature depends on factors such as the subject area, the technology used and the number of developers involved [14] who stipulate conditions of participation, value management and people [15] who are flexible in terms of scope, time and also have considerations such as the possible increase in the cost of the projects; therefore, these factors are not defined as fixed [9].
On the other hand, agile contracts for the development of software solutions do not encounter major obstacles for their implementation in private companies [6] or other business formats [16] and other industries that involve software [17]; this is due to the fact that they are not regulated by principles such as the selection of suppliers through extensive bidding processes, efficiency in spending, and transparency in contracting among other factors are substantial issues that regulate contracting in the public sector [6]. These principles oblige public institutions to apply rigorous planning processes and to structure contracts with a wide level of detail and inflexibility, which is typical of traditional contractual agreements.
Taking into account the aforementioned, a systematic literature mapping is carried out; its main objective is to identify related jobs and, based on its analysis, establish what is known as agile contracting; what has been investigated; what aspects remain unknown and how has the adoption of this concept been in both the public and private sector. Additionally, this work seeks to generate proposals based on the analysis of cases of the application and the use of agile contracts in different sectors of the economy, and help to implement agile contracting practices in contexts with stricter regulations such as government institutions.
In addition to this introduction, this study is organized as follows: Section 2 describes the established research protocol and defined research questions to carry out systematic mapping. Section 3 contains the results and answers to the research questions posed. In Section 4 the discussion is carried out, where the limitations and challenges in the implementation of agile contracts in the state are also analyzed. Section 5 presents a preliminary framework, where aspects are recommended to consider and to support the execution of agile contracts with the state. Finally, Section 6 presents the conclusion and recommendations for future works.

Research protocol
The activities carried out in the Planning stage are described in detail below.

Research questions
The main objective of this mapping was to establish the state of the art on the application of agile contracting for software development in different sectors of the economy and in the public sector. For this, we established research questions ( Table 1). The questions sought to obtain a definition for agile contracting and inquired about possible contractual models and the application in the software industry and in the public sector. Finally, we generated possible recommendations on its usefulness based on the findings. Inquire about the application that agile contracting has had in the industry and the possible results and contracting methods that have resulted in this field, in order to verify its applicability in the public sector. Q5. What has been the application of agile contracting in the public sector?
Inquire if there are documented cases of agile contracting for the public sector in order to give possible recommendations for the application of agile contracting to the State.

Search strategy
To carry out the search, the logical connectors "AND" and / or "OR" were used in the different keywords: agile contract design, contracting agile, software development, agile software development, agile contracts, software engineering, government and public sector. Initially, the search string created was (("software development" OR "software engineering" OR "agile software development") AND ("Agile contract design" OR "Contracting agile" OR "Agile Contracts")), which was adapted for each of the selected databases: ACM Digital Library, Google Scholar, IEEE Digital Library, ISI Web of Science, Microsoft Academic, Science@Direct y Scopus (ver Tabla 2).
The search was carried out for the English and Spanish languages; although the information found in a different language was also taken into account. In addition, we considered the information that had been published during the period of January 2003 and June 2021. This time period was determined since it is considered that the agile contracting concept was born almost at the same time as the agile manifesto in 2001 [1].
The agile manifesto is considered a good starting point since guidelines to improve project management emerge from its values; as well as a balance between customer satisfaction, early and continuous deliveries with adaptation to change. Values such as collaboration with the client on contract negotiation, software running on extensive documentation and response to change on following a plan are synchronized with the purposes of agile recruiting [1]. All of which we validated with the execution of the systematic mapping where the first reference found was in 2003 and the focus of most of the information found was between the years 2016 and 2019.

Selection criteria for primary studies
The information collected in the search for each of the different databases was evaluated considering the title, abstract and keywords, in order to determine whether or not the study was going to be included among the relevant studies. Following, the studies were analyzed in detail to select those that met at least one of the criteria defined in Table 3. On the other hand, the articles that met any of the exclusion criteria defined in Table 4 were not taken into account. Table 3. Inclusion criteria

I1
Articles, book chapters, dissertations and conferences whose domain is software engineering.

I2
Articles, book chapters, dissertations and conferences whose titles are related to agile contracts for software development.

I3
Articles, book chapters, dissertations, and conferences that present agile contract methods, models, or frameworks applied to industry or the public sector. I4 Articles, book chapters, dissertations and conferences published since 2003.

I5
Articles, book chapters, dissertations and conferences whose title, abstract and conclusions contain one or more keywords. Articles, book chapters, dissertations, and conferences whose domain is a topic different than engineering or software development. E2 Articles, book chapters, dissertations and conferences published before 2003. E3 Duplicate articles, book chapters, dissertations and conferences.

E4
Articles, book chapters, dissertations and conferences whose domain is a different topic than agile contracting in software development

E5
Articles, book chapters, dissertations and conferences whose texts are not available or there is no access to them.

Quality evaluation criteria
To measure the quality of the selected studies, a questionnaire has been developed with a scoring system of three values (1, 0.5 and 0) that correspond to the answers "Yes", "Partially" and "No" respectively. This assessment was determined relevant to the research in order not to rule out studies that, due to a negative score, could not be taken into account for future research. Table 5 presents the quality criteria considered.
The addition of the score for each question will make up the final quality score on the field of study (obtaining a value between 0 and 6). This information is available at the link https://n9.cl/0305, where the result of the evaluation of the studies is presented according to the quality evaluation questions.

Synthesis methods
The information of the selected primary studies was extracted and structured according to the following parameters: identification (title, author, year), abstract and aspects that were relevant to answer the research questions such as: definitions, characteristics, types, methods, models, frameworks and application both in industry and in the public sector. Table 6 presents the synthesis method associated with each question.

Execution stage
An initial context search was carried out and information obtained by other means, which is different from the databases mentioned in section 2 of the research protocol. Subsequently, 4 iterations were necessary to reach the refinement of the search chains for each of the databases. Table 7 shows the results obtained after executing the query chain in each of the databases and the number of studies from other sources.

Results
In this session the selected studies are analyzed; a total of 49 papers contributed to answering the questions was established. The contributions of the studies can be consulted at https://n9.cl/k6f70. Likewise, the complete information of the selected studies is available at the link: https://n9.cl/lc4ys. Also, the primary studies will be referenced in the following sections with the letter S for Study and a number assigned in the process to differentiate from the base studies presented in this work.

Question 1: What is agile contracting?
In the studies analyzed, the concept of agile contracting is not clear; therefore, some characteristics found in the different studies were collected to propose a definition. According to [S9], an agile contract is an agreement between one or more clients and one or more suppliers, adapted to the requirement of a development process based on agile approaches. Likewise, it is characterized by loyalty and a need for continuous collaboration between interested parties, where the final product is seen as a corporate interest [S19]. On the other hand, the scope and budget necessary to carry out this interest is rarely clear from the beginning of the negotiation and both parties are aware of this particularity [6]. Therefore, an agile development contract must address all the requirements specifications necessary to arrive at the final product only as a planning framework and not as a frozen definition [S17]. Furthermore, the fact that all contracts are incomplete is recognized and, therefore, such a framework must explicitly address contingency management [S28]. In this sense, agile contracts need flexibility to handle uncertainties [S3] and are adapted to adjust the scope, budget and requirements for frequent delivery cycle [S32] of a functional product, whose design, construction and tests occur throughout the iteration [S17]. It is then understood that the software project has an adaptive and changing nature and, therefore, it is not necessary to specify any special protocol for change in the agile contract, since this is already inherent to the agile approach [S17].
Considering the aforementioned, the contract must establish the agile approach procedure, the duration of the delivery iteration, the projected duration, the estimated costs of the project, payment methods, participation rules to ensure cooperation between the client, the provider, the prioritization procedure in each cycle and other aspects resulting from the negotiation between the parties [S9]. In addition, it must be adapted for change after every delivery iteration; an agile contract must include the possibility of completely stopping the development project [S17]. In this sense, early termination is considered as a positive event; even desirable since it indicates that the objective was reached quickly or that it was perceived early.
In accordance with the aforementioned, the following definition is proposed: an agile contract is a framework of agreement, which in addition to the legal aspects of the contractual documents, regulates the relationship between client-supplier around an agile approach to software development, which takes into account aspects of creation and collaboration, that establishes scope, requirements and flexible budget, which can also be considered, prioritized and adjusted in each delivery cycle. In that contract, values are presented for estimates in time and cost of the project and the relevant aspects that are the result of negotiation and continuous collaboration between the parties are described.

Question 2: What methods or types of agile contracts exist?
Agile contracts do not differ significantly from the so-called traditional contracts; their main purpose is to formally adjust the flexibility required to evolve the software requirements [S19]. In this sense, it is not the contract that makes a software project agile, it is the relationship between the client and the supplier that enables agility [19]. However, of the total of primary studies, 43% present contract models based on price that can facilitate the application of agile approaches in software development; a summary of the types of contracts and their respective characteristics based on the analyzed works. This compendium can be consulted at https://n9.cl/2tyaw. Fifty-five percent of the studies mention Time and Materials (T&M) contracts; in addition, there are variations of the time and material type with fixed scope and price ceiling and variable scope and price ceiling [S42]. On the other hand, 33% of the studies present the Target cost type contract as an option that facilitates agility. Despite the apparent contradiction between the concept of agility and fixed-price contracts because the latter is more related to cascade development [6], agile fixed-price contracts are mentioned in 28% of the studies. Other types of price-based contracts are presented less frequently: Advantage contract [S15, S25], Progressive contract [S15] and Two-phase contract [S42]. Also, the type of Collaborative agile contract [S1, S27] is presented, the PS2000 contract used in large public IT projects in Norway is mentioned in 19% of the studies, Target  Regarding contracting based on criteria other than price, the Contract based on the role was found, which focuses not on the product, but on the role of each party and the responsibility linked to this role [S19].

Question 3: What are the significant differences between traditional contracting methods and agile contracting?
As mentioned in the previous section, agile project contracts and traditional project contracts are similar, both in structure and legal aspects; the main difference being that agile contracts are created with elements of collaboration, learning and evolution [S12, S17], and despite the existence of price-related contract models, payments in agile development services do not differ in essence from traditional projects [S17]. However, 19% [S3-S6, S12, S15, S32, S29, S42] of the studies analyzed mention the fixed price as a distinctive characteristic of traditional contracts.
The project management triangle (time-cost-scope) is also mentioned as a restriction inherent to traditional contracts [39,42]. In addition to the fact that the product specifications are delivered in advance as part of the traditional contractual document [S2, S12, S17, S22], which is a characteristic of the cascade development [S6, S12, S15, S25, S39] and marks a significant difference with respect to agile contracts; ultimately, it has more elements of collaboration, communication, learning and trust with the client [S12, S17, S22, S27].

Question 4: What has been the application of agile contracting in different sectors of the economy?
According to [S16, S22, S32], between 40% and 70% of the contracts for software development are of the fixed price type and between 15% and 50% [S16, S22] are T&M contracts or other types of contracts. The analyzed studies did not show significant experience with a particular type of contract, but they did reveal the motivations of some companies and software projects to transition from traditional contracting to other contract models to facilitate agile approaches.
In [S13] the experience of the German company Adesso AG is narrated, where the agreement with the client allowed the adoption of the Advantage contract model, because the estimation of a reliable fixed price was very complex given the magnitude of the system to be developed. Similarly, [S3] presents considerations to take into account when contracting with suppliers in industrial companies that acquire complex embedded systems when seeking collaboration with possible candidates for an environment that allows innovation. In [S43] the case of the company FitCo is presented, in which the construction of trust with the client is based on transparency through an exercise to open its finances, which helps to justify its rates for a target cost contract. Likewise, in [S35] the experience of Valtech is presented, in which despite having exceeded the budget and the delivery time, it built a relationship of trust based on the effort to be transparent and receptive with the client, with which it managed to change the fixed price contract to a T&M contract. Equipment  Manufacturer) is presented, where they sought to adopt Continuous Integration and Deployment (CI&CD) systems. In this study, it is reported that those involved concluded that traditional contracts are an impediment to interorganizational CI&CD and suggest using more flexible contracts. In [S12] the findings of interviews between developers in the Norwegian market are presented. The results revealed that the respondents from the supplier side prefer T&M contracts, followed by PS2000 contracts and incremental delivery contracts, while fixed price contracts are in fourth place; in addition, it is defined that the motivation of the the preference for T&M contracts is: "T&M contracts are the most flexible to use agile development and have the least risk for suppliers" [S12], which is in line with what the literature mentions in the study [S7] .

Question 5: What has been the application of agile contracting in the public sector?
Similar to the results found in the application of agile contracting for the industry, the use of a particular type of agile contract for the public sector cannot be established; however, some cases were collected among the studies analyzed. For example, the PS2000 contract is used in Norwegian public projects and is characterized by sharing the risk between the parties managing an objective cost with an upper and lower limit [15]. In addition, it is important to clarify that countries such as Norway and Sweden have modified their legislation to facilitate the terms and conditions for agile software development [S2]. Likewise, flaws in programs such as HealthCare.gov in the United States forced policies to be modified to allow agencies to use agile approaches when writing requests for provider proposals [S40].
Other cases, such as the Bonus-Malus reward framework applied to the development of mission-critical systems in Italy, is similar to the fixed price contract model and is characterized by estimates based on function points that are made for the payment to the provider that it is calculated according to the user stories implemented added to the bonus obtained according to criteria such as technical debt [S6].
The policy of contracting and acquiring military technology initially adopted by the United States and later by the United Kingdom and Australia, emphasizes the definition: development, production and / or acquisition of hardware or software in increments according to the urgency of the need, the evolution of the threat and availability of technology. This shows that it is possible to base acquisitions not on product specifications, but on the value to be acquired, which creates the conditions for the adaptability and flexibility of the projects and systems that are built [S17 ].
Despite the previous cases, the literature mentions that governments work under the cascade method for software development, which means that the contracts generated from the public sector have a traditional approach, with defined scope, cost and time up front. This is compounded by detailed and in many cases inflexible product specifications, which is a major obstacle to a proper implementation of agile approaches to development [S12, S18, S40].

Discussion
The legal framework is not a differential factor between agile and traditional contracting methods; its difference lies in the terms to respond to agile approaches and the criteria of relationship between the parties.
Despite the existence of different types of contracts and even a model called Agile with a fixed price, the studies are clear in pointing out the contradiction between fixed price and agility; it is therefore that projects according to the context or size of the project must reduce use of this type of contract to the maximum. However, the public sector is characterized by multiple limitations, regulations and legal requirements; therefore, contracts are created with an approach to cascade development and respond to a traditional framework that provides detailed and inflexible specifications. In addition, the terms of collaboration between the parties are not clear or are simply not taken into account in the contractual process. At the same time, the supplier's choice criterion is a low price. In this sense, the premise "public contracts are not negotiated, they are fulfilled" [S39] is reaffirmed, an environment not very favorable to agile development.
Agile approaches cannot rely solely on the clauses stipulated in a contract. Although it cannot be concluded that the law prevents agile development for software projects in the public sector, it is also true that the peculiarities of the traditional contracting process prevent making the most of the early generation of value, the main characteristic of agility for software development. In that sense, the use of only some separate aspects of approaches such as iteration delivery, partial collaboration with the client or the prioritization of user stories, is not something that makes an institution agile. At best, it can be called cascade-agile-traditional, which is seen as a first step in the learning required to adopt agile approaches. In addition, it is important to highlight that a total and not partial transformation is necessary to be an agile organization; likewise, continuous improvement programs must be maintained that help to detect early strengthening strategies in terms of operational agility.
Agile approaches changed the concept of success in software projects from traditional development, where it was believed that a series of consecutive and orderly steps led to a good result. Even with the rethinking brought by agile approaches, contracting has not changed much and the premise of early and detailed product specification in extensive contract documents continues. Although there are cases of modification of the contracting policy in the public sector that has led to changes towards agile contracting, it is also important to highlight that these cases are limited and even strange in the studies analyzed. The few that can be found do not document in detail the characteristics and modifications in the regulations for the success of the projects.
Agile development goes beyond contracting. It includes a whole culture of the organization and requires a change not only in the contractual factors, the forms of payment, the delivery or acceptance criteria, the termination, among others. There is also a need to replan the role of the final user in development, the ability of governments to adapt to the needs of the agile approach, governance models and the willingness to renegotiate and be part of the team. These are, among others, some of the aspects that must be considered and that are outside the scope of a contract.

Recommendation for agile contracting in the State
The public sector has a lot to learn from private industry. It is possible to find clear examples of the benefits of projects that integrated agile aspects such as negotiation and collaboration. In this sense, as a result of the findings found in this systematic mapping, some recommendations for the agile contracting process in the public sector are presented below with some considerations that should be considered in accordance with the restrictions of a traditional contracting process.
First, it is suggested that governments carry out an assessment of the capacities of public institutions, identify opportunities for improvement and, with the results obtained, make the necessary adjustments to establish training plans for public workers. Likewise, that the necessary adaptations in infrastructure can be made, for example: practices such as DevOps [S22, S47], applied together with frameworks for agile organization such as SAFe (Scaled Agile Framework) [S37, S47], could support the early gain of value. In this sense, it is important that governments evaluate, adjust and validate their capacity to respond to the requirements of agile approaches.
It is necessary to replan the role that public workers play with development teams. The former should not be limited to monitoring or requesting reports; they should work in synergy and collaboratively in such a way as to facilitate decision-making during development. Likewise, users must be willing to respond and be constant actors in the process. This aspect is especially difficult in organizations with a high hierarchy such as the public sector, where decisions that are made rarely reach the public workers who interact with development teams.
The government must begin to think carefully about the software solution that is wanted and based on models that help decision-making such as Cynefin [12], determine the complexity of the system and consider dividing the functionalities in several projects with different processes bidding for each set of functionalities. This would make it possible to reduce the typical uncertainty in traditional projects, in which, with the application of fixed price contracts, suppliers run the risk of being involved in projects, where the complexity of the development is not measured; since preliminary requirements are usually established in advance and it is easier to correct the course with the realization of partitioned projects that can be reconsidered for other functionalities and continuous changes [S15].
It is understood that each project should be stipulated with scope and functionalities at a general level and would be executed in accordance with the procedure of the chosen agile approach. Likewise, the duration and the prioritization procedure for each delivery cycle and participation rules must be taken into account to ensure cooperation between the provider and the institution [S9].
Additionally, it is recommended that the cost estimates for each partitioned software project be based on metrics (such as function points [S6]) and make price comparisons with equivalent market studies and related to public tenders. In addition, it is suggested that the project time be defined as a maximum projected, and that payments to the supplier be made by iteration of development after verification of the acceptance criteria previously defined in the contract.
Finally, the result of each project would be the basis for the formulation of a new contractual process for the development of the next group of functionalities. In addition, it is recommended that the institution or company undertake a comprehensive management of all partitioned projects, and that traceability and monitoring be carried out on aspects such as non-functional requirements and technical debt, which, if necessary, will be included in the new development.

Menaces to the validity and limitations of the study
The systematic mapping of the literature focused on gathering information on agile contracting. The study was planned and conducted following the protocols proposed in [10,11]. In this context, and given the nature of the study, it is important to relate the threats to the validity and limitations of this mapping. (i) The search strings proposed for the process may include inappropriate search terms related to the research topic, (ii) only automatic search was applied, and (iii) only articles that included information on agile contracting were selected between 2003 and 2003. 2021. All of this can lead to bias in the identification of primary studies [13]. It was identified that the concept of agile contracting emerged around the same time as the agile manifesto [1]. This does not guarantee that all related primary studies have been selected nor does it guarantee that all information related to the adoption of agile contracting in the public and private sectors has been presented. Articles that could contribute to these topics may have been discarded. These threats to validity can affect the generalizability of the literature mapping results. However, to minimize these threats and avoid data extraction biases, the entire process was executed by cross-checking between the authors.

Conclusion and future work
In this study, a systematic mapping of the literature was carried out. This has allowed us to have a first impression of the state of agile contracting. A definition was proposed and the differences with traditional contracting methods and their relationship with the cascade development method were established. Likewise, the application of agile contracts in both the private and public sectors was investigated. In addition, the findings were discussed and recommendations were given to adapt the agile contracting approach in the public sector.
Agile contracts have great barriers originated by the regulations of states. Countries like Norway, Sweden and the United States are reforming their contracting policies to facilitate software development from an agile approach. After analyzing the studies found, no evidence of reforms to procurement policies was found, nor agile contracting exercises from the public sector in Latin American countries.
With the findings identified and the benefits documented, the need for a reform of the contracting methods by which countries manage software development is evident. This implies not only a change in the legal frameworks for contracts, but also a vision of the institution that must adjust its processes and organizational culture in order to recognize, adapt and work towards the adoption of agile approaches and the value demonstrated of its implementation.
As future work, it is considered important to continue carrying out studies on the results of the application of agile contracts in the countries that have reformed their contracting policies. Similarly, the effectiveness of applying agile approaches to software development in traditional contracting environments such as government entities must be analyzed.
Also, as a result of this study, agile contractual frameworks are proposed for the public sector, specifically for a country with an approach compatible with the criteria that by law can be immovable, such as the fixed cost for a project and evaluating the effectiveness of the implementation of these types of contracts. The respective results will be presented. This proposal will be submitted for consideration and validation with experts in software contracting in the State and the respective results will be presented.