agile methods in it-based business projects
TRANSCRIPT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
<
Agile metoder i it-baserede forretningsprojekter
Vejledning om agil udvikling i den offentlige sektor
IT- og Telestyrelsen har på opdrag fra K02-arbejdsgruppen udarbejdet en vejledning om anven-delse af agile metoder i udvikling af it-projekter.
Formålet med vejledningen er at understøtte den offentlige sektors anvendelse af agile udvik-lingsmetoder i it-baserede forretningsprojekter.
Håbet er, at vejledningen kan være med til at kvalificere beslutningsgrundlaget, når man står over for at skulle igangsætte et nyt it-udviklingsprojekt og ønsker at prøve kræfter med en alternativ projektstyringsmetode. Samtidig skulle vejledningen kunne understøtte indgåelse af kontrak-ter, som har en anden karakter end de traditionelle it-leverancekontrakter med fast pris, tid og ydelse.
Baggrunden for udgivelsen af denne vejledning er, at der i de senere år har været talt og skrevet en hel del om styringen af offentlige it-udviklingsprojekter. Senest har rapporten fra Rigsrevisio-nen fra 2008 løftet sløret for nogle af de udfordringer, som styring af offentlige it-projekter møder. Der er således sat øget fokus på effekten af de it-investeringer, der gennemføres, og det har med-ført stigende krav til den måde, den offentlige sektor gennemfører it-udviklingsprojekter på.
Anvendelse af agile udviklingsmetoder er et ledelsesmæssigt strategisk skifte, der kræver fokus, vilje, modenhed og indsats af den offentlige myndighed. Samtidigt skal man også have for øje, at leverandøren skal være i stand til at kunne levere et produkt uden at modtage en fuldstændig kravspecifikation fra starten af projektet.
Agile Methods in IT-Based Business ProjectsGuide to Agile Development in the Public Sector
Agile Methods in IT-Based Business Projects - Guide to Agile Development in the Public Sector Published by: The National IT and Telecom Agency Holsteinsgade 63 DK-2100 Copenhagen Ø Telephone: +45 3545 0000 Faximile: +45 3545 0010
The publication can be downloaded from: http://www.itst.dk ISBN (internet): 978-87-92572-12-7
>
Agile Methods in IT-Based Business Projects Guide to Agile Development in the Public Sector
National IT and Telecom Agency February 2010
>
Contents >
1 Introduction 7
2 Introduction to Agile Development Methods 9 2.1 Development in Iterations 9 2.2 Ongoing Prioritisation of the Tasks 9 2.3 Close Dialogue with the Supplier 9 2.4 From the Waterfall Method to the Agile Development Method 10
3 The Authority’s Needs and Maturity 11 3.1 Identifying Needs 11 3.2 Maturity, Skills, and Structure 11 3.3 Basic Prerequisites 11
4 Choosing a Development Method 13 4.1 Using Agile Development Methods 13 4.2 Basis for Decision 13 4.3 The Nature and Boundaries of the Project 13 4.4 Flexibility and Responsibility 15 4.5 Risk and Security 16 4.6 The Challenges of Agile Development Methods 17
5 Preparation and Planning of Tendering 19 5.1 Regulatory Reform on Tendering 19 5.2 The Tendering Material 20 5.3 The Needs Statement 21 5.4 Requirements for the Eligibility of the Supplier 22 5.5 Comparing Bids 22
6 Contract Formation 24 6.1 Introduction 24 6.2 Choosing a Model 24 6.3 Precedents and Existing Standard Contracts 24 6.4 Brief Account of the Agile Collaboration 25 6.5 Risk 26 6.6 Description of the Service (The Subject of the Contract) 26
6.6.1 The traditional Waterfall Method and the Service Description 26 6.6.2 Agile Development and the Service Description 26
6.7 Price/Financial Limit 28 6.8 Schedule 30 6.9 Organisation of Collaboration 31 6.10 Responsibility for Delivery 31 6.11 Guaranties 32 6.12 Breach of Contract on the Part of the Supplier 32 6.13 Compensation 33 6.14 Change Management 34
6.14.1 The Authority’s Change Requirements 34 6.14.2 The Supplier’s Change Requirements 35
6.15 Termination of Collaboration on the Part of the Authority 35
6.16 Rights 36
6.17 Testing 37 6.18 Summary 37
7 The Agile Development Process 38 7.1 Project Start-Up 40
7.1.1 Internal Organisation 40 7.1.2 Collaboration with the Supplier 41 7.1.3 Role - Product Owner 42 7.1.4 Roles - Scrum Master and Scrum Team 43 7.1.5 Start-up Activities 43
7.2 During the Project 44 7.2.1 Activities during the Project 44 7.2.2 Test Management 45 7.2.3 Completion of an Iteration 45
7.3 Completion of the Project 46
8 Appendix 1: The National Survey and Cadastre (Case Study) 47
8.1 An iterative Project is First Contemplated 47 8.2 Problems Arise 48 8.3 Building Trust between Client and Supplier 49 8.4 Schedule must Allow Time for Reflection 50 8.5 Communication is Important 50
9 Appendix 2: ADF and ALO (Case Study) 51 9.1 System Restructuring 51 9.2 Communication, Communication, … 53 9.3 Handling a Dynamic Requirement Specification 54
>
1 Introduction
The purpose of this guide is to support the public sector’s application of agile development methods in IT-based business projects.
Agile development has been applied increasingly as a project management method in the private sector over the past decade. Public authorities both in Denmark and internationally (for example, Norway, Sweden, the UK, and the USA) are now gaining experience in the application of these methods, as well.
The guide will hopefully help qualify the basis for decision when it comes to commencing a new IT-development project in which one may want to apply an alternative project management method. The guide should also help authorities enter into contracts that differ from the traditional IT supplier contracts, with fixed prices, deadlines, and services.
This guide does not promote agile development methods over other development methods. Agile development methods are merely one among several methods of handling IT-based business projects.
The guide is structured in accordance with the planning and development phases that IT-based business projects typically go through from start to finish. We recommend that the guide be read in its entirety by persons who are practically involved in the development of the project. Chapters 5 and 6, related to the entering into of contracts, are moreover particularly relevant for those who are involved with this on a daily basis. Finally, we recommend that the management and other decision makers draw attention to Chapters 2, 3, and 4 as well as Appendices 1 and 2.
The release of this publication is as a result of the recent increase in interest concerning the management of public sector IT-development projects. Especially the Bonnerup report set the stage in 2001 for the development which has happened in the high profile IT projects of the public sector. More recently, the 2008 National Audit Office of Denmark report, for example, revealed some of the challenges facing public authorities working with IT projects. This has placed additional focus on efficiency in IT investments and has led to stricter methodological requirements on how public sector bodies go about IT-development projects. In the past decade, there have been more public IT projects that have either been completed too late or that have overrun their budgets. In many instances, the effect of the implemented solution has been insufficiently documented.
However, the application of agile development methods requires significant changes to the way public authorities have traditionally carried out IT projects. This involves changes in attitude and behaviour when it comes to jurisprudence, the day-to-day collaborative regime, one’s own skills, and the speed and structure of decision making. Opting for agile development processes represents a strategic managerial shift that requires focus, will, maturity, and effort on the part of the public authority. In addition, one must ensure that the supplier is capable of delivering the required product without possessing complete requirement specifications at the start of the project.
Appendices 1 and 2 contain illustrative interviews with public authorities and offer practical experiences from the field of agile project development.
7
>
Please note that the rules of tendering and the rules for creating contracts have not been described in exhaustive detail. The same is true for the ways of managing agile development projects. Rather, we recommended that one turn to the literature and websites in which these subjects are described.
8
>
2 Introduction to Agile Development Methods
2.1 Development in Iterations Generally speaking, IT development business projects that apply the agile method are conducted in relatively short developmental stages called iterations. Development in iterations is not exclusive to the agile method; the traditional waterfall method also at times incorporates iterative development as part of the process.
In the agile development method, an iteration is conceived of as a small-scale project cycle. During an iteration (typically 2–4 weeks), the supplier uses a list of prioritised needs and demands to design and develop elements that have been tested and are ready to be included as part of the overall solution.
The list of prioritised needs and demands is “owned” by the authority, and the supplier develops the elements with the highest priority so that what is in the highest demand is developed first. When the iteration is complete, the authority will reprioritise the list of needs and demands so that the supplier can again seek to fulfil the most important needs and demands in the next iteration.
2.2 Ongoing Prioritisation of the Tasks
An agile development project is defined by the authority’s entering into dialogue with the supplier regarding the ongoing prioritisation of tasks. The list of prioritisations will change along the way as the project progresses. This flexibility represents the core of the agile development method. The intention is to attain greater business value in the final product than one would in traditional projects, and this is achieved by incorporating flexibility into the IT projects. This is primarily a result of the increased dialogue regarding the contents of the product throughout its duration.
As such, the authority must constantly prioritise its business requirements and be aware of the guidelines and principles used in such prioritisation. An authority must also always give pride of place to the overall business goals that the development is intended to achieve, yet it needs to be aware that such goals can – and typically do – change over the course of development.
2.3 Close Dialogue with the Supplier
Authorities must be willing to enter into a very close dialogue with the supplier. Given that the authority “owns” the list of prioritised needs and demands, one must constantly adjust the prioritisation both with the supplier and one’s own organisation. Every single product which the supplier creates must, in principle, be able to function as an independent constituent part and must in itself bring value to the authority.
Upon completion of an iteration, go through and check with the supplier the functionality of the product created by the supplier in the course of the iteration. The information learned by both the authority and the supplier over the course of the iteration are integral to the continued dialogue that must occur. This learning often helps increase the business value of end product: The authority’s knowledge of the delivery from the completed iteration allows it to provide the supplier with excellent feedback regarding the functionality of future iterations.
9
>
Depending on the extent to which an authority is involved in the development of an agile project, use of this method allows ongoing control over the progress of the project and the end product that is eventually achieved. This ongoing control helps reduce the risk and future costs related to required changes.
2.4 From the Waterfall Method to the Agile Development Method Since its introduction in the 1970s, the so-called waterfall method has been frequently applied to IT projects in the public sector. The waterfall method involves developing an IT solution in sequential phases. The development is seen as a constant flow downwards throughout the phases. The phases of the model will typically be specification requirements, design, implementation, testing and error detection, integration, and maintenance. As such, it is a prerequisite that the authority has described what demands the given IT solution must fulfil. This means determining one’s needs and converting them into demands in a complete specification requirement. The agile development methods challenge the perception that it is necessary to know all demands for the end product in advance. On the contrary, the agile development methods revolve around the flexibility achieved by demands changing underway: An agile project is guided by the determined business scope and goals rather than in detailed demands.
In some IT projects, it would be relatively easy to describe the exact demands for a product, while in other more complex IT projects, “inventions” would be required throughout the course of the project. The latter situations favour a development model that takes into account the ongoing knowledge building and changes underway and that ensures close dialogue between the authority and the supplier. An agile project takes it as a given that the agile development method provides just this.
A general project management method, whether waterfall oriented or agile, that can completely fulfil public sector project management needs has not yet been developed. Experience indicates that a combination of PRINCE2 and an agile development method offers a good foundation for successful management of the processes. After all, PRINCE2 focuses on the overall business case and the management of the processes and less on the management of the actual development task. This is where the agile method can act as a supplement. As a public authority, however, one should continue following the advice and guidance provided by the range of digitalisation tools made available by the National IT and Telecom Agency and the Ministry of Finance. See Appendix 3.
10
>
3 The Authority’s Needs and Maturity
3.1 Identifying Needs Before deciding to start the development of an IT project, it is advantageous to conduct a needs analysis to reveal the significant problems related to the project. A needs analysis can play a great role in identifying the exact purpose of the project and clarifying issues related to the contents and extent of the project. It is particularly important that agile projects focus on the following in the needs analysis:
Describe an overall vision for the solution as well as identify needs rather than possible solutions
Describe the business goals and demands
Determine a suitable level for the description.
The needs analysis should result in a combined needs statement that is sufficiently extensive to contribute to the foundation of the supplier’s bid.
In this phase of the considerations related to commencing the development of an IT project, it would be natural for the authority to develop a business case. In short, a business case is a specific tool to assess whether a given IT investment is a good and profitable idea. In addition, it can help create a clear goal for the fulfilment of the business vision and is a method by which one can follow up on whether the short-term and long-term goals of the IT investment are actually reached. It is also worth remembering that the business case is a dynamic document used from the start to the finish of the development of an IT project. When creating a business case, the authority should appoint a PRINCE2-type steering committee to own the business case. The supplier should also be part of the steering committee and know the details of the business case.
3.2 Maturity, Skills, and Structure Before making the strategic decision to implement the development of an agile development project, most organisations should consider these three aspects:
The maturity level of the organisation
The presence of the necessary skills
The decision-making structure of the organisation The decision-making structure of the organisation.
3.3 Basic Prerequisites The following section will set out the basic prerequisites for the traditional waterfall method and the agile development method. This is, of course, a simplified account that accentuates and highlights the differences between the waterfall method and the agile development method to a greater extent than may be true in practice. The traditional waterfall method is based on the following basic prerequisites:
11
>
The ability to assess the project in its entirety in advance
The ability to specify in detail what the system must be able to do and the solution the project should result in
That the entire solution is developed based on predetermined specification requirements and the solution description and that the project is controlled to ensure that all items are delivered
Project management is about controlling whether the schedule, the budgets, and the specification requirements are met
Every change leads to a formal change in the contract, often resulting in additional payments to the supplier
The project possesses a fixed price and schedule.
The basis for the agile development method is that the supplier must strive to deliver functionality and business value to the authority. If one were to attempt to “translate” the principles of agile development into a number of basic prerequisites comparable to those listed above, these would be:
It is not assumed that the authority can specify the solution in detail but rather that one can fairly precisely define the business goals and needs. The authority must focus on what would lead to the greatest value and that one can reprioritise what the supplier is to create on an ongoing basis.
Changes in what the authority desires are a prerequisite and a part of the agile work process, meaning that this will not necessarily be seen as a cost overrun as it often would in a traditional waterfall project where the price is determined in advance. Agile projects are not necessarily cheaper to carry out, but their increased flexibility permits the creation of functionalities during the project that could subsequently provide the authority with additional value within the confines of the budget.
The authority’s project management is primarily conducted through ongoing dialogue with the supplier relating to needs and demands and their prioritisation. The prioritisation itself is driven by continual involvement in the project via planning and review meetings at the start and finish of each iteration.
Learning is often a central and integrated aspect of the agile work method. Although learning and improvement are not excluded from traditional development methods, the agile development method typically supports the learning process in itself.
12
>
4 Choosing a Development Method
4.1 Using Agile Development Methods
The decision to move from the waterfall project model to a more agile development method often entail for an organisation a strategic decision with implications in many areas. Thus, the decision to carry out a specific project based on the agile development method is not just choosing one method over another. This is because the choice of a method presupposes a variety of other choices. For instance, basic prerequisites may include the consideration of how best to motivate people, to build trust and fruitful relationships between two parties that do not share the same goals “on paper”, etc. Knowledge of prerequisites is necessary for one to succeed with any particular method.
4.2 Basis for Decision There is no general and unequivocal answer to whether an authority should choose an agile development method over the waterfall method. The authority should consider the following partly overlapping factors:
The need and maturity of the authority (Chapter 3)
The nature and boundaries of the project (Section 4.3)
Flexibility and responsibility (Section 4.4).
Risk and Security (Section 4.5).
The challenges in using agile development methods (Section 4.6).
The issue of an organisation’s maturity is discussed in Chapter 3 above.
When it comes to choosing a project management method, it is clearly not a matter of “either/or” since most organisations will need to carry out projects in accordance with both types of methods and maybe even use them both for one and the same project. When all is said and done though, this is a strategic decision that must be made by the organisation’s management. Moving from one project method to another necessitates changes in the ways that the authority and the supplier work together, in the type of internal reporting, in the delegation of responsibility, in the involvement of the organisation, etc. The organisation must be prepared to handle these changes in order for the project to be carried out successfully.
The decision will of course depend on the organisation’s experience in dealing with agile development methods. The more experience within the organisation, the less risk is involved in the decision.
4.3 The Nature and Boundaries of the Project When the decision is made to commence an agile development project, it is important to define the boundaries and limitations that will be imposed on the project from
13
>
outside sources. This concerns boundaries that will be central to the management of the project.
Here are a number of examples of typical boundaries within which a project must work:
Functionality is a fixed and invariable boundary. For instance, if an authority is to replace an old IT system with a new one, the old IT system cannot be switched off before a new IT system is able to solve the same tasks as the old one.
Time is also a fixed and invariable boundary. For instance, if the legislature has placed a deadline for an IT system to be put into use in order to resolve a given task, the IT system must be in place by that time.
Resources/budget is a fixed and invariable boundary. For instance, a given task may need to be resolved within a particular budget.
In a typical waterfall project, one would usually “lock in” all three factors in the table above. One would then enter into an agreement on price with a clear schedule divided into phases. The specification requirements would detail what the supplier was delivering.
FUNCTIO-NALITY PRICE
TIME
There are also boundaries for agile development projects: These include a combination of the factors in the table above as well as any possible limitations set by external forces. Unlike in the waterfall project method though, these factors are not all “locked in” in advance. To the contrary, a prioritisation or scaling is made of these factors in terms of their meaning and the extent of the flexibility extended by the authority towards any changes in each individual factor.
For instance, the authority could set a budgetary framework that is fixed in the first instance. Often, there will also be a deadline for completion, one that is set at the outset of the project. When developing agile projects, business requirements will also typically be fixed from the start. Although the demand for functionality will not be specified from the outset, it is not necessarily harmful for an agile project to possess predetermined time and price factors.
14
>
Physical and organisational boundaries are also important for the positive progress of the agile project. One should replace project participants – both within the authority and at the supplier -- as little as possible. Additionally, the authority must ensure that it has easy and unhindered physical access to the supplier’s development team since increased communication is at the heart of agile projects. An advantageous method of obtaining this is to arrange for the development team to “live” with the authority for a period of time. This way, the management gets closer to the actual project, allowing for stronger anchorage in the organisation. If such a move is not possible, then the authority should go to the development team as often as possible or, alternatively, use video conferencing as a method of last resort.
Finally, the nature of the project obviously influences the choice of development method. If one has a project where not all needs and demands can be specified in advance and where the development horizon is so long that needs and demands can be expected to change underway, then the agile development method is particularly suitable.
4.4 Flexibility and Responsibility
Waterfall projects require detailed descriptions of the specification requirements and the price and time of delivery. The supplier develops a solution description, and from this point on, it is the supplier’s responsibility to ensure that the agreed-upon solution is delivered at the agreed-upon price by the agreed-upon time.
Agile development projects have predetermined fixed boundaries for the development process. However, the required IT business solution is not described in detail, and the price and time of delivery are not necessarily determined from the outset. The responsibility of creating a usable business solution and for delivering the solution at a possibly predetermined price and time is shared by the supplier and the authority.
Often, the two development methods are combined so that one manages neither in accordance with a pure waterfall method nor with a pure agile development method. Thus, when moving from waterfall to agile development, the authority’s flexibility in the development progress increases accordingly as the authority takes on a greater responsibility for the delivery of a useable solution at the right price and at the right time.
For instance, in traditional waterfall projects, one can create greater flexibility by using more “open” and need-oriented requirement specifications. The question of how to formulate such need-oriented requirement specifications has been processed several times. See, among others, the recommendations of Søren Lausen, IT-Universitetet, in the publication Guide to Requirements SL-07 – Template with Examples.
Flexibility in the waterfall method can also be increased by developing phases/iterations. Thus, the standard K02 contract has the built-in option of phasing.
15
>
4.5 Risk and Security
In relation to the question of flexibility versus responsibility, the authority should, when choosing a development method, consider the question of risk, which is an inherently complex area.
In the case of isolated, low-risk projects (with flexible schedules, limited budgetary constraints, etc.), it is usually easier to test the agile development methods.
When using the waterfall method, there is some security in knowing that you can hold the supplier responsible for defects and delays and that the authority can, in principle, revoke the contract as a last resort as well as demand damages and fines in relation to the contract. In reality, this security can be illusory and problematic given the fact that, as an authority, pulling out of an IT-development project is not always possible without financial and practical consequences for the organisation. Furthermore, the underlying risk concerning that fact that, when using the waterfall method in its purest form, the authority in principle will not know until the date of delivery if the delivered IT solution works and provides the desired and required business value.
Agile development projects require normal active customer involvement, which ideally provides the authority with a clear indication of the progress of the project. This also means that there must be a focus on each iteration resulting in a partial delivery that is useable to some extent and that brings value to the authority. As the project progresses, the authority has the ongoing security of knowing that an IT solution that meets its business requirements is being delivered. One thus reduces the risk of the authority finding out at the conclusion of the last iteration that the developed solution does not work as intended.
The risk of receiving an IT solution that does not work at the conclusion of the project can be illustrated in simplified form by the chart below. The vertical axis demonstrates the risk of receiving a solution that does not work, and the horizontal axis marks the timeframe for delivery. The authority’s risk is ideally lessened relatively quickly at the beginning of the agile development project as the progress of the development focuses on developing those constituent elements that bring the most value to the authority.
16
>
The chart solely serves an illustrative purpose to show how the development of risk in two very stylised development processes differ from one other. The risk in the individual processes will thus be handled differently in practice.
In relation to the above-mentioned risk consideration, one should also be aware that the agile development process implies a significant risk of the project failing if the authority fails to dedicate the necessary time and resources for the process to succeed and if the above-mentioned organisational aspects are not addressed.
4.6 The Challenges of Agile Development Methods
Even though agile development methods promise to reach the goal of the IT project in a better and more flexible way, there is a number of challenges to which one must relate.
The following challenges should be made part of the assessment as to whether an agile development method should be used in a project or within an organisation:
The basic idea of the agile development method is that close collaboration between the authority and the supplier ensures the ongoing adjustments of expectations and that the end product meets the business requirements. The authority must dedicate the necessary time and resources throughout the entire development process.
Throughout the entire process, the authority must communicate to the supplier the business requirements and their prioritisations. The business requirements include all the stakeholders’ needs. Stakeholders include the management, external stakeholders, and actual end users. The ongoing identification and reprioritisation are critical for the success of the project and should be managed with fixed boundaries if necessary.
Tests are integral to the development process and are meant to ensure that the desired quality is maintained throughout the project. Testers – typically representatives of the end user – are involved in the project throughout the progress in the development. If conceived of as an isolated factor, this could be seen as increasing resource costs. However, it helps lower the risk of finding errors and needs at the completion of the project. Such errors and needs would result in unexpected costs for error correction.
Focus must be on documentation. Since many demands are determined along the way and since there is an ongoing and close dialogue between the authority and the supplier, it may be tempting to omit sufficient documentation of the progress and changes of the project. Comprehensive and ongoing documentation ensures that there is no doubt regarding the approval of the delivery, prioritisation of tasks, and other agreements between the authority and the supplier. Documentation also ensures that new members of the project can easily be brought up to speed.
17
>
The actual (daily) project management also involves a number of challenges, both for the authority and for the supplier. These must be resolved throughout the project, and include:
The authorities must describe the project based on a number of boundaries and not based on detailed demands. When the supplier is to be held accountable for agreements and expectations, this is done on the basis of a description of the business requirements and goals.
At the outset of the project, demands and needs must be sufficiently described and prioritised for the supplier’s development team to commence the development process.
The supplier’s development team must be able to break down the task into smaller and more specific tasks based on the description from the authorities.
Needs and demands must be reprioritised on an ongoing basis based on business value, and the supplier’s development team must estimate costs for the task on an ongoing basis.
The supplier must be able to conclude an iteration (development process) in five weeks or less.
The supplier’s development team must at all times be able to demonstrate visual progress on the tasks.
One or more dedicated employees must be made available from the authority so that they can enter into daily discussion with the supplier regarding the prioritisation and preferences of the business requirements as well as how to meet the boundaries of the projects. Further to this, the employees should be knowledgeable about the domain of the project. The authority’s employees could, for instance, participate in the supplier’s development team.
The authority must be able to gather a cross-vocational team that can contribute to the business dialogue with the supplier.
18
>
5 Preparation and Planning of Tendering
As mentioned in the introduction, the rules for tendering are not described in detail in this guide. Reference is made to the website of the Danish Competition Authority, and public authorities should ensure that, when completing a tender, an expert on tendering jurisprudence is included in the project. The regulations which have special significance for tendering IT business projects are introduced in the following section. When tendering an IT development project, there are many considerations to be made by the authority, as is the case with tendering all other types of IT projects.
5.1 Regulatory Reform on Tendering
In accordance the regulatory reform on tendering, public authorities generally have a duty to make their purchases subject to competition.
If the costs for the development of IT projects are over the so-called threshold value set forth by an EU directive (Directive no. 2004/18/EF)1, and the project is covered by the field of application of the directive, the tendering must be carried out in accordance with the rules of the directive. The limits for the threshold values for services, in effect as of January 1, 2010 until December 31, 2011, is DKK 931,638 for central government contracts and DKK 1,438,448 for county and municipal contracts.
If the costs are below the threshold value or the project is not covered by the field of application of the directive, the public authority must, in accordance with the basic legal principles of the EU, ensure a sufficient degree of publicity regarding the purchase if the acquisition has a clear transcendent interest.
If the cost is more than DKK 500,000, and the project is covered by the Tender Law2, the purchase must then be publicised by advertisement as set forth more specifically in the law.
Thus, in principle, a public authority can take various directions, depending on what the acquisition entails and the size of its estimated value.
This guide is targeted towards acquisitions achieved by the conducting a tender covered by the directive of the EU (EU tendering).
In the course of an EU tendering, the final choice of contract form will typically depend on weighing a number of factors such as the combined needs statement compared to an evaluation of the market for the desired services. Here, it will be relevant to investigate if there are suppliers who have experience with agile or other forms of iterative development.
Thereafter, one should decide which form of tendering would be the most suitable in the given situation. There are several different forms of tenders. The most common are “Public Tendering” and “Limited Tendering”. Finally, there is “Competitive Dialogue”, which can be used for very complex contracts.
When developing an IT business project, the most obvious and common form of tendering is “Limited Tendering” since this allows one to pre-qualify the suppliers and thereby limit the number of offers. This can be desirable since tendering for the
19
>
development of an IT business project is often complicated, and competition is often conducted on more than just the price. Furthermore, the task of comparing the offers from the suppliers is empirically fairly demanding. In a “Limited Tendering”, there can be no negotiations with the potential tenders during the process.
For very complex IT projects, it is often desirable to use the form of tendering called “Competitive Dialogue”, in which it is possible to limit and determine how the needs of the public authority are best met. The competitive dialogue is similar to “Limited Tendering” in terms of pre-qualifying companies, but unlike this form, here the tendering entity has the option of discussing possible solutions during the dialogue phase with the pre-qualified companies. After the dialogue phase, the suppliers prepare binding offers, after which the public authority assesses the offers and awards the contract to the company that has prepared the most financially lucrative offer. In “Public Tendering” and “Limited Tendering”, the award criteria of “lowest price” can also be used, but empirically speaking, it is rarely used on contracts related to the tendering of IT projects.
5.2 The Tendering Material
Clients must prepare a number of documents describing what is being tendered. The documents consist of the tendering material, and these will form the basis on which the supplier compiles the proper tender.
The aim of the tendering material is thus to define the conditions and boundaries for the tender and in this way guide the bidders in developing a tender. The contractual foundation for the delivery is part of the tendering material. The tendering material typically consists of the following documents:
The tender notice must contain precise information regarding the service to be provided and must be published in the Official Journal. The advertising commences the formal tender. The description of the delivery is also called the subject of the contract.
The conditions of the tender sets forth the formal guidelines for the tender and must, for example, include demands for the configuration of the tender as well as the criteria for award and evaluation that the client will use as the basis for selecting the supplier.
The draft of the contract is the starting point for the actual contract with the supplier.
The addendums to the contract will consist of the authority’s demands in a number of areas, including demands for IT solutions, as related to function, service goals, etc.
When developing an agile development project, a key document is the overall needs statement. This describes the business processes that will support the business goals sought to be met. Such descriptions may be provided by user stories and usage scenarios.
20
>
5.3 The Needs Statement
The processes through which an authority must go in the case of public procurement, an agile development project does not, in principle, differ significantly from the tender process of any other IT project. However, as a consequence of choosing the agile development method, the supplier will not include in its tender an actual solution description. This is because the subject of the agile contract differs significantly from contracts relating to waterfall projects inasmuch as the delivery will be of process-related matters, such as resources counselling, use of methods, quality control, and coordination.
However, there are a number of considerations for the authority to make when tendering an agile development project. The biggest difference is the level of detail in the authority’s description of what is being tendered. Typically, when applying traditional development methods, one would have a requirement specification describing the subject of the contract (i.e., a detailed description of the actual delivery), but in the case of the agile development method, one has a statement of needs that focuses on business goals and demands. In other words, there is a description of the identified needs rather than of possible (technical) solutions.
It is thus important to consider the level of detail in the descriptions of the tendered delivery, both in the tender notice and in the document that replaces the traditional requirement specification. I.e. how much leeway should the description of the subject of the contract give as a result of the flexibility implied by the agile development method? The challenge is that the two documents must contain sufficient information for the supplier to be able to form an idea of what is being tendered, yet must not impose too many restrictions on the actual development process. According to the rules on tendering, the description of the functional demands or of the functionality must be sufficiently specific for the client to identify the subject of the contract.
There are several advantages to focusing one’s efforts on the development of a combined overall needs statement:
One need not prepare an extensive requirement specification
The supplier gains a greater lever of flexibility in meeting the authority’s demands since the design of the solution is not predetermined
The authority’s business demands are the focus, and it controls the development process.
It is important to ensure that an IT development project does not evolve so that the tendered service is not in accordance with the end product.
For instance, if the tender documents created in relation to the development of a new website state the desire for the website to support increased communication between citizens and companies, it would be a violation of the rules on tendering to wait until the development process to determine specific technological options such as blogs and other Web 2.0 solutions.
21
>
On the other hand, it is doubtful whether one could integrate the underlying IT solutions that have the ability to exchange specific case information between the authority on the one hand and the citizens on the other hand. A solution such as this would, given the circumstances, possibly require a new tender.
The conditions of the tender consist of the authority’s guidelines for the tender and describe, among other things, the acquisition process. Here, one would also note the criteria by which the suppliers’ tenders are being measured.
5.4 Requirements for the Eligibility of the Supplier
As part of the pre-qualification in a limited tender or prior to the tenders being evaluated in a public tender, the authority must select the suppliers that are considered eligible for the assignment. In the case of a limited tender, the circle of tenderers encouraged to provide a tender could be further limited by adding selection criteria.
The eligibility of suppliers is determined based on the supplier’s economic and financial capacity alongside their technical and/or professional abilities.
It is important that the authority ensures that the suppliers whose tenders are considered have these required professional skills and that they are capable of developing an IT project in accordance with the agile method in a reassuring manner. This form of development requires a significant level of maturity on the part of the supplier and the people the supplier assigns to handle the task. When assessing this, it will usually be relevant to review the deliveries or services the supplier has performed in the past three years and any information related to the educational and professional qualifications of the person or persons who will be responsible for carrying out the task.
5.5 Comparing Bids Special attention should be given to the tender evaluation criteria inasmuch as these constitute the basis for eventually selecting a bid. For the vast majority of IT projects, procurement takes the form of open tendering in which there is little or no potential for dialogue during the tendering process. Since the tender evaluation criteria represent the authority’s basis for procurement, they also indicate to suppliers what the authority deems valuable in making its decision. When the time comes to compare bids from various suppliers, it is necessary to use the tender evaluation criteria described in the conditions for tendering. It is particularly important in Agile development projects that one has the opportunity to compare the development methods of the different suppliers and the extent to which these methods involve the users. It may also be relevant to compare project management and control methods, time use estimation methods, and activity coordination methods. Additionally, it is necessary to establish a means of calculating prices during the evaluation of bids (see Chapter 6 on Price/Financial Framework). In order to undertake such a comparison, the basis for evaluating bids must be explicitly described in the tender evaluation criteria.
22
>
Additionally, it may be relevant to consider how the supplier will make use of its prior experience during the process. Before the authority can determine how such experience could be exploited in given circumstances, it is vital that procurement law expertise be enlisted to clarify these circumstances within the procurement process. This is because it can be difficult to differentiate between the criteria by which potential suppliers are selected and the tender evaluation criteria inasmuch as this area of law is still developing.
This means that Agile development IT projects require that aspects such as IT development method, project control method, and timescale be included in the tender evaluation criteria. Similarly, it must be determined whether making use of suppliers’ prior experience should be included. The question of a supplier’s prior experience can cause particular difficulties, hence the recommendation that authorities obtain special procurement law assistance regarding the handling of this issue.
23
>
6 Contract Formation
6.1 Introduction
This chapter aims to highlight a number of legal issues regarding contracts to which authorities must respond and to some extent incorporate in the contract when carrying out an IT business project.
The chapter also aims to direct the reader’s attention to publicly available materials and initiatives related to contract regulation of agile development projects.
Finally, it should be noted that this chapter provides no specific suggestions as to the wording of contract provisions. Other sources are recommended for this, and you may want to seek legal counsel, as well.
6.2 Choosing a Model
The matter of choosing a model has been thoroughly discussed in Chapter 4 above. Here, mention is merely made of the fact that there can be many considerations to factor in when choosing a model. Among the most important of these are service, price, and time.
As mentioned above, waterfall projects “lock” all factors regarding service, price, and time. This is not the case in agile development projects, but there are still boundaries for such projects in the form of a combination of the three factors and possible other external limitations. In the course of an agile development project, there would thus be a prioritisation or gradation of the three aspects correlated to their importance and to the degree of flexibility the authority can and will exhibit towards changes within each individual factor.
When choosing an agile development method, the authority must be prepared for some degree of flexibility regarding service, price, and/or time as these factors are the foundation upon which the flexibility rests.
Often, the development of an IT project becomes a combination of non-functional and functional demands. The non-functional demands are typically demonstrated in the business needs and demands. Non-functional demands can often be delivered at a fixed price whereas the agile development of functional demands must to a large extent be based on estimates.
In the following section, we consider a number of the central issues concerning the authority’s options to subsequently utilise the legal boundaries as a guide. We also consider how such boundaries can guard against the agile collaboration “sliding” without the authority having the possibility of stepping in with legal basis in the contract.
6.3 Precedents and Existing Standard Contracts
There seems to be no unequivocal precedent for the formation of contracts to support agile development methods. Agile development contracts are often based on the
24
>
supplier’s previous contracts, and these contracts are usually more or less waterfall contracts or framework contracts.
In this respect, note that an exorbitant amount of time could be spent adjusting, for instance, the standard K01 and K02 contracts to fit agile development needs. In reality, one runs the risk of the contract not supporting the agile process anyway. On the other hand, the K02 contract for example regulates a number of significant issues that can be relevant for the development of an agile contract. This means that the K02 contract can serve as inspiration for which aspects should be regulated given the circumstances.
Clearly, when public authorities want to undertake an agile development, it is undesirable to enter into contracts that do not specifically take into consideration requirements to which the authority must adhere as well as consider the specific challenges presented by agile development methods.
Denmark has no true standard contracts intended to support agile IT development in the public sector, though there are some initiatives from the private sector.
Outside of Denmark, contractual inspiration can only be gathered from a very few sources. In Norway, the public authority of the Directorate of the Administration and IKT is working on creating a standard contract called Systemutviklingsavtalen (SSA-S). The Norwegian Dataunion, which is a private company, has also created a standard contract, PS2000, that includes a guide called Smidig utvikling med PS2000 (Flexible Development with PS2000). However, it should be noted that the Norwegian tradition of contract creation is very different from the Danish tradition, meaning that the Norwegian standard contracts should be used with caution.
6.4 Brief Account of the Agile Collaboration
As a rule, one must assume that the two parties – authority and supplier –entering into a contract have a mutual interest in achieving the goals of the authority’s project. Furthermore, one must assume that both parties are diligently protecting their own interests by entering into this cooperation.
On projects based on agile development, one must, however, also be particularly aware of the structure of enticements in the contract, including:
that the supplier is not obligated beyond its abilities and
that the authority is not forced to continue the collaboration and may terminate future collaboration at any time.
Proper handling of these aspects ensures that neither of the parties risks being placed in a situation in which one of the parties no longer has an interest in collaborating.
In addition, the authority should be very careful about the wording of addendums to the contract. For instance, the traditional control and approval at the conclusion of the project or its phases is not exactly practical in an agile development project. The
25
>
addendums must, therefore, be adjusted significantly to the agile development and management process.
6.5 Risk
A number of the central aspects of developing collaboration between the authority and the supplier are discussed below. Different risks accompany this collaboration, all dependent on the contents of the contract. Does one party bear the largest burden of risk, or is it possible to balance this burden in a way that will satisfy both parties?
One must keep this in mind when drafting a contract for an agile development project. The basic notion of the agile development process is that close collaboration between the authority and the supplier ensures an ongoing adjustment of expectations and therefore a product that meets the authority’s business needs. It is thus natural to seek to balance the risk between the authority and the supplier in the event that the authority’s business needs are partially or fully not met.
Agile contracts represent a definite break from the traditional distribution of risk in development projects since the client in an agile project must take on a significant part of the risk involved. When creating an agile contract, it can be a challenge not to go too far toward the other extreme and reduce the collaboration to pure payment for hours spent; rather, the created model should have the supplier bear a part of the risk of fulfilling the client’s business goals.
6.6 Description of the Service (The Subject of the Contract)
6.6.1 The traditional Waterfall Method and the Service Description
In the traditional waterfall method, the subject of the contract (the IT solution) is described in the authority’s specification requirement and the supplier’s solution description. There are many ways of drafting a specification requirement. Traditionally, specification requirements are created in line with the principle that they are a necessary basis for both development and verification of the end product (testing and approval). This principle has been applied to functional as well as non-functional demands. The traditional specification requirement often contains an abundance of demands at many different levels, for example at the functional level, the designer level, and the need level.
6.6.2 Agile Development and the Service Description
In an agile development project, the traditional specification requirement is set aside in order to shift focus to a number of other aspects. In addition, the supplier does not prepare an actual solution description prior to the signing of the contract. As far as this is concerned, it is important to realise that the agile development method differs fundamentally from the traditional waterfall method, and the development of the IT solution is not locked in from the start. On the contrary, focus is on the authority’s business needs. The business needs should be described in a document that forms the basis for the supplier’s (and the authority’s) development of the end product. The first needs statement thus forms the core of the description of the desired solution.
26
>
Additionally, the agile method requires close collaboration between the authority and the supplier. This collaboration is partly based on mutual trust and partly on joint responsibility for the completion of the project, which necessitates that the supplier’s role be carefully described and made part of the subject of the contract. Therefore, the following aspects should generally be included as part of the supplier’s service:
Delivery of a development team with relevant programming skills
Project management, including management of activities and resources
Counselling on integration into the client’s existing IT environment, technology, and applied method.
Ensuring coherent architecture.
The creation of the aforementioned needs statement is central to the agile development process. The needs statement is not the same as the specification requirement used in traditional waterfall projects. The needs statement must ensure the creation of a document describing the business needs as well as an initial mutual prioritisation of these needs and any mutual reliance (The described needs statement is referred to as a “Product Backlog” in Scrum development. See Chapter 7). The described business needs should steer the development of the end product and should be carefully described and supplemented by user stories and user scenarios. The needs statement can thus contain both functional and non-functional demands for the IT solution. During the actual development of the IT project, the needs statement will play a significant role as a reference document in connection with the client’s approvals.
As far as functional demands of the IT solution are concerned, the description form should be short and precise, and demands should be worded through the application of user histories and user scenarios.
New business solutions will often be developed with reference to one or more predetermined demands, for example demands for integration, platform, and application of obligatory open standards (non-functional demands). Regardless of whether agile development is sought, such demands should be described in advance. By doing so, one lowers the flexibility of the development, but since demands have been locked in, there is no need for these to appear open on paper. The supplier’s possible insecurity and risk is also lessened accordingly, which could lead to a lower price.
The connection between the aforementioned requirements of user stories can thus be set forth as written below:
27
>
Overall Business Needs
IntegrationUser story 6 User story 5 User story 4
User story 3 User story 2 User story 1
User case 6C
User case 6B
User case 6A
User case 5C
User case 5B
User case 5A
User case 4C
User case 4B
User case 4A
User case 3C
User case 3B
User case 3A User case 2A
User case 2C User case 1C
User case 1B User case 2B
User case 1A
Non
Fun
ctio
nal
Req
uire
men
ts
Scope/IT platform
It is recommended that an authority that lacks experience creating needs statements for use in agile development projects seek assistance as to drafting the needs statement, etc.
6.7 Price/Financial Limit
When setting a financial limit (the supplier’s fee) in an agile contract, it is important to keep in mind the desired regulation of flexibility in price. Several models can be used for calculating the financial limit in an agile development process, but one should bear in mind that the financial limit does not commit the supplier to any particular results; rather, it sets the payment the supplier receives for its services.
Settlement can be made using fixed hourly prices, possibly fixed further within a given time period (time box) or a fixed financial boundary (money box), reflecting the combined financial limit set by the authority for the project described in the contract.
The work is more or less carried out in the form of independent deliveries in accordance with the authority’s ongoing prioritisation (iterations). Service, price, and time of delivery are not typically set in advance and are not necessarily part of the basis for the agreement. However, the authority could demand that a given service be ready at a certain time, for example to comply with a legislative requirement.
Payment for the contract can then be described as a time-based payment within the area described in the contract. The contract can, for instance, be created as a framework contract for the delivery of services related to the ongoing development of business functionality in a given IT environment. The authority would then later prioritise the supplier’s work into smaller independent deliveries.
28
>
In the agile model, the payment risk is generally greater for the authority as the authority cannot determine in advance the number of hours spent by the supplier to ensure the delivery of the supplied service.
However, the many iterations and the ongoing prioritisation of the supplier’s work gives the authority the opportunity to closely follow up on the progress of the project. It is assumed that the authority ensures ongoing payment in accordance with the delivery of services as a result of this close collaboration since the deliveries have a measurable business value for the authority. When carrying out an agile project, it is, however, unlikely that the client will set a condition of only paying for services that have business value. In an agile project, the client plays a part in the decision making related to the contents of every iteration and therefore also bears the risk for this. The supplier can be given a part of this risk, but not the entire risk. The term “business value” means that the authority can utilise the supplied service in the event that the collaboration is terminated after an approved delivery of the individual iteration.
One type of flexibility in price is the fixing of a financial framework that is only flexible in terms of time and service. The basis for this will then be that the collaboration is terminated when the agreed-upon financial limit for the parties’ collaboration has been reached. However, this model can result in the supplier not providing the desired service for the agreed-upon payment. In certain situations, this can be too big of a risk for the authority.
As mentioned above, the compensation can be fixed further, but it is important to remember that agile collaboration requires that there is no traditional agreement on fixed price, time, and service.
Determination of compensation can, however, be made so that the authority and the supplier jointly carry part of the financial risk for the completion of the project. This entails both parties being responsible for correct and responsible fulfilment of the contract. In this kind of compensation model, the financial risk is split equally between the authority and the supplier if, for instance, it turns out that the deliveries are more complicated than anticipated and thus more expensive to realise.
Another possible model involves part of the payment being made once the project has been completed. This motivates the supplier to work effectively and complete the development in order to receive the remaining part of the agreed-upon payment. One downside of this model is that the supplier will typically have finance costs, for example expenses related to borrowing the money to pay salary. The authority runs the risk of having to pay for these costs.
Authorities often choose the agile method as a means of receiving one or more (partial) solutions more quickly. However, this may make it appropriate to set the time used as one of the parameters for measuring the supplier’s work. Enticements should be linked to the speed with which the supplier achieves an acceptable result.
Another model could be one in which the supplier includes in its tender an estimate for the entire or partial completion of the project, also called a “target price”. If the estimate is exceeded, this will affect the payment that the supplier is entitled to collect for that part of the fee exceeding the estimate.
29
>
One way of doing this is to supplement the fixed estimate with the supplier’s risk assessment in the price quote. This means that the supplier includes in its tender a fixed estimate with a margin of uncertainty, for example +/-20 percent for the combined delivery. If the margin of uncertainty is exceeded, this becomes the sole or partial responsibility of the supplier. The supplier includes a risk assessment that describes the factors that make the estimate uncertain. One must keep in mind that the supplier will often link a possible uncertainty with increased risk. When the supplier takes on a greater risk, the predominant consideration for the supplier will be to increase the price presented to the authority. This means that the greater the risk for the supplier, the more expensive it will be for the authority.
Therefore, if the authority is subject to a certain requirement (for example, actual laws or mandatory open standards), this requirement should be described as precisely as possible in advance.
When entering into the contract, the authority and the supplier will discuss the identified risks that can affect the supplier’s completion of the delivery. If this discussion leads to changes in the risk assessment that affect the margin of uncertainty or the fixed estimate, this should be made clear in the supplier’s documentation for the discussion. This process can result in a changed contract or possibly in the termination of collaboration if a compromise cannot be made.
There are also other models that combine or modify the ones mentioned above.
Public authorities will often have been allocated in advance a pre-determined amount that can be spent on the project. The authority must, therefore, focus on how to manage the risk of exceeding this price. The authority must also ensure that the product delivered in exchange for the payment possesses a business value that corresponds to the payment.
6.8 Schedule
The supplier should include with its offer a combined schedule for the project based on the authority’s time frame expectations (for example, start and finish dates of the entire project, dates of various deadlines for completion of functionality, etc.).
The authority should likewise define its expectations and demands for the supplier’s planning of the development process.
Since an agile development project is planned throughout the development and on the basis of ongoing changes, the supplier cannot create a detailed plan for every development process (iteration) when making its tender. However, the supplier can set out its expectations for the course of the development process as a whole. This could contain:
Start and end dates for the project
Number of iterations
Start and end dates for the iterations
30
>
Expected times for testing and approval
Frequency of meetings between the supplier and the authority. The contract should be regulated to reflect the expected actions of the authority and the supplier in the event that the schedule cannot be met. If certain parts of the schedule are fixed, the contract should include a specific agreement to this extent, as is the case for price and service. It should also set out the consequences that this fixed schedule has for price and service. As mentioned above, it is important to remember that agile collaboration requires that there be no traditional agreement on fixed price, time, and service. If the schedule or parts of the schedule are locked in, it should be made clear whether the authority is prepared to pay extra for compliance with the schedule or whether parts of the service can be postponed for delivery after the fixed time set out in the schedule.
6.9 Organisation of Collaboration
As mentioned above, an agile development project requires close collaboration between the authority and the supplier. The authority must determine if it has the required maturity, and one must be ready to set aside the resources required to carry out the necessary dialogue with the supplier. This also entails the authority making the necessary business-critical decisions on an ongoing basis. This does not correlate to the typical development model in the public sector in which one group is given a mandate, and the management is sporadically involved as a managing group member. Agile projects require the client to make decisions and to decide on significant changes at short notice. This is one of the most important issues for a public client to consider prior to deciding to use the agile method.
As with IT-development projects managed with traditional methods, it is important to take care when describing what resources the authority has available for an agile development project.
It is also mandatory that one deals specifically with the resources provided by the supplier. The creation of the development team is central to this.
The authority should thus consider how many people will be on the development team, the combination of their programming skills, and the potential for their replacement. However, it is ultimately the supplier’s responsibility to ensure that the development team possesses the necessary skills. If there are any problems, it will be the supplier’s responsibility to make the appropriate adjustments.
6.10 Responsibility for Delivery
When an IT delivery is carried out in accordance with the waterfall method, the question of whether the supplier has met its obligation is typically measured by testing. The result of this testing (usually called an “acquisition test”) is critical for the authority’s acquisition of the IT delivery. It will not be clear until this late date whether the supplier’s service fulfils the contract - in other words, whether the services are adequate or whether they correspond to the authority’s demands as set out in the contract.
31
>
A prerequisite for agile collaboration is that the authority checks on an ongoing basis whether the supplier is delivering the needed progress in such a way that the authority consider it advantageous to continue collaborating with the supplier. This is achieved by having the more or less independent deliveries (iterations) be subject to testing and subsequent approval when the authority believes that the criteria for approval have been met. This form of collaboration can prevent unpleasant surprises for the authority very late in the project, for example that the supplier has difficulties in getting the product to the authority’s requirements or that it cannot deliver by the agreed-upon time.
However, depending of the specific coordination of the agile collaboration, including the structuring of its legal guidelines, collaboration can also make it difficult to maintain a clear-cut division of responsibility. The authority’s ongoing approval of the smaller independent deliveries could prevent it from objecting later on if prior deliveries turn out not to support certain transversal correlations or functions. The agile collaboration method does not prevent these situations from being rectified once the authority is made aware of the need. However, the supplier could, legally speaking, demand separate payment for the resources used in rectifying the situation. “Rectification” is simply handled as another iteration in terms of the authority’s prioritisation.
6.11 Guaranties
Delivery contracts such as K01 and K02 usually contain guarantee regulations that aim to ensure a contractual service for the authority even after acquisition of the IT delivery. Guarantees could, for example, target the delivered IT system as a whole being accessible at a given level. The guarantee regulations could also target specific aspects of the IT delivery – such as functionality – that are particularly critical for the authority.
In “pure” agile collaborations, it can be challenging to implement guarantee regulations that go beyond the small independent deliveries (iterations). Typically, the authority will approve these on an ongoing basis. However, the authority may not be able to assess whether, for example, partial delivery number 4, which could contain regulations regarding response time, supports the response times of partial deliveries 9, 10, and 12, to be delivered in later iterations. Making decisions as to approval can therefore be difficult.
As a result, when developing the agile collaboration model, the authority must address which guarantees it needs and how these are best implemented in the legal guidelines for the agile collaboration.
6.12 Breach of Contract on the Part of the Supplier
The terms related to breach of contract are included (from the authority’s perspective) in order to protect the authority to a reasonable extent in the event that the supplier proves incapable of delivering the agreed-upon service either by the agreed-upon time or in the agreed-upon form.
32
>
Delivery contracts such as K01 and K02 contain traditional remedies for breach of contract in case of the supplier’s delay (for example, fines, damages, and right of cancellation) and defects (for example, supplementary performance, proportional reduction, and right of cancellation).
In both cases, the authority’s use of its rights will depend on whether it can prove that the supplier is late or has delivered a service with defects. If using the first assessment, the authority must be able to compare the actual progress to the main schedule of the contract. If claiming defect, the authority must be able to compare the delivered IT service to specification requirement of the contract.
In agile collaborations, the demands for the delivery structure will not usually be static and will only be fixed following the commencement of the delivery in which the next partial delivery is to be produced. As is the case with the determination of the guarantees, the development process and the close joint effort of the authority and the supplier can make it difficult to determine whether there is actually a delay or a defect.
For instance, the authority’s acceptance of a lower prioritisation of a partly completed task in the prioritised list of tasks (needs statement/Product Backlog) could mean that the authority could claim later on that the supplier caused the delay. Something similar could happen when the agile collaboration is based on a flexible schedule in which the authority’s opportunity to claim delay is affected by the authority’s ongoing prioritisation of tasks.
Additionally, one cannot oppose one of the basic prerequisites for agile collaboration, i.e. that any subsequent change to the approved IT delivery is conducted as new iterations for which the supplier is paid separately.
Since an authority is unlikely to possess an infinite budget and since, for example, new regulations could make it subject to invariable deadlines for implementation of new business procedures, the authority should always carefully consider implementing remedies for breach of contract in the legal framework for the agile collaboration.
6.13 Compensation
No parties should be exempt from liability when entering into collaboration with an IT supplier. As a result, conditions concerning liability for compensation for damage resulting from work performed are a natural part of typical IT supplier contracts. Without these conditions, the parties’ liability for compensation would generally be regulated by the Danish Courts’ usual rules concerning liability for compensation claims in a contractual relationship.
The close collaboration between the authority and the supplier as well as the relatively informal decision-making processes may make the sufficiency of evidence for agile collaborations more opaque than is the case in forms of collaboration that are based on more traditional IT supplier contracts (such as K01 and K02). All things being equal, it could be difficult to clarify whether the supplier has acted in an actionable manner in relation to the authorities on any one matter.
33
>
The authority should thus consider the need for special conditions concerning the supplier’s liability for compensation. For example, it may be worthwhile to create specific contractual obligations regarding the supplier’s liability for repeated or significant differences between the supplier’s own project estimates (which the municipality has required to be completed in single iterations) and the eventual use of resources on completion of the project. The supplier may therefore need to take on a degree of liability for compliance with estimates.
6.14 Change Management
Change management must be seen in relation to the article of the contract that has been covered above. In the more traditional waterfall projects, changes to the agreed upon solution are typically managed as actual change management actions.
The agile development method is grounded in the idea that the solution itself is not predetermined and that no actual solution description exists in advance. When it comes to change management in agile development projects, these changes have a different character than they do in waterfall projects. Change management in agile projects thus has to do with aiming to meet conditions for the completion of the project.
Both the authority and the supplier may need to undertake changes during the course of a project.
6.14.1 The Authority’s Change Requirements
The authority’s change requirements for an agile project will typically consist of:
Changes resulting from changed business needs and/or legal requirements. As noted above, a statement of needs is prepared with reference to the authority’s business needs as well as to eventual legal requirements. The statement of needs and the business needs it contains will steer the whole of the development process, including the number and sequence of iterations, prioritisation of business needs, and resource allocation and management.
Changed business needs will thus affect a wide range of conditions fundamental to the completion of the project, including the supplier’s potential to deliver on its contractual obligations to manage resources.
A contract must, therefore, take a stance on the management of changes of this sort.
Changes to team composition or other organisational conditions.
Similarly, the authority’s requirement on changes to team composition or other organisational conditions could be difficult or impossible for the supplier to fulfil.
If the authority has committed itself to making available a certain amount of manpower, any reduction could affect the supplier’s ability to complete the project.
34
>
By the same token, the authority may require that the supplier place additional or other manpower at the development team’s disposal, for example in order to speed up delivery. Such a requirement might prove impossible for the supplier to fulfil and would normally require a separate contract.
It can be advantageous to integrate the framework for such requirements into the contract.
Changes to the schedule.
In relation to the above, the authority may need the project to be completed prior to the agreed-upon date. The authority could, for example, place additional resources at the supplier’s disposal or could tone down the business needs or remove them entirely.
The unforeseen need for early delivery could thus be managed in a variety of ways though each of these ways will have an influence on the project.
Particularly for long-term projects, it can be advantageous to take a contractual position on these types of changes.
6.14.2 The Supplier’s Change Requirements
The supplier’s change requirements for an agile project will typically consist of:
Changes to team composition or other organisational conditions.
The supplier could also find itself in a situation in which it is necessary to alter the team composition in terms of programming skills or total number of workers.
Changes to the composition of the development team – the members of which are experienced with the project – will result in more or less lengthy decreases in productivity. The authority should thus only accept changes to the team that have been agreed upon in advance. It is necessary, however, to first ascertain whether replacement of a worker is justified, for example by illness or end of employment.
Capacity to change these conditions should, if necessary, be contractually regulated.
6.15 Termination of Collaboration on the Part of the Authority
One of the two fundamental conditions for agile collaboration is that the authority is not forced to continue working with the supplier but is entitled to cease collaboration with future effect.
In Danish law, it is not generally permitted to annul an agreed-upon contract. Authorities considering entering into an agile collaboration should thus implement an explicit means of discontinuing contracts in order to promote balance within the agile collaboration. Thus the judicial framework of agile collaborations differs significantly
35
>
from that of traditional IT supplier contracts (such as K01 and K02), which do not permit termination of collaboration or state that the authority can only terminate collaboration relatively early in the course of the contract.
Capacity to terminate can extend from an ability to terminate the contract without further notice (discretionary) to a capacity that is conditional on certain circumstances (for example, a political decision). One can also imagine contract types in which the termination is made conditional upon a payment to the supplier; however, the reasonableness of this set up must be partially dependent upon the other contents of the contract, including the assurance that the supplier has, via regular payments, received full compensation for his work.
When the authority is in the position of determining where to draw the line in the legal framework regarding agile collaboration, it should note that this means of terminating a contract may function as the authority’s only sure way out of the collaboration. This is the case when the agile collaboration method has effectively blurred the degree of sufficiency of evidence necessary to determine whether the authority is entitled to make use of actual remedies for breach of contract.
On the other hand, such an extensive capacity for termination has far-reaching consequences. The discretionary capacity in particular can negatively influence the authority’s initial tendering process. Lack of clarity concerning the precise duration of the contract can lead to the bidders incorporating a margin of risk into their estimates. Similarly, there is a risk that suppliers will simply choose not to make bids on the contract.
The authority should also be aware that capacity to terminate can be an onerous option to utilise in practice. To the extent that the authority continues to require IT suppliers and the presumed value of the outstanding order exceeds the threshold value of the procurement directives, the authority could be forced to enter into a lengthy and expensive new tendering process prior to being able to enter into a contract with another supplier.
6.16 Rights
One’s choice of a particular service provision and business collaboration model does not generally affect the distribution of rights to the IT products.
The close collaboration between the authority and the supplier in an agile collaboration could – depending on the precise organisation and implementation of the agile collaboration – create uncertainty regarding which party has, for example, contributed proprietary input and which party (in the absence of a written agreement) have the rights once the contract is fulfilled.
On this account, authorities should integrate into the contract conditions concerning the distribution of rights, including whether it is the supplier or the authority that gains any intellectual property rights to the developed program. Note, however, that the client’s acquisition of rights is not conditional upon its approval of the results achieved. Even in the case of agile projects, the customer should generally have such
36
>
rights and documentation in order for the customer to continue the project following a termination of contract.
6.17 Testing
Testing of the product is traditionally described in the model appendices to K01 and K02. By “traditional”, we mean that the described procedure is oriented toward a project developed with the waterfall model. Such tests are long-term and concern the product as a whole, as it was delivered at the completion of the project. Agile development projects, on the other hand, include tests after every iteration. Each delivery is tested at the authority not only by the testers but by the users (or user representatives) of the project, as well.
The procedures for user involvement and the testing of each iteration should be described in detail in the appendix on testing. Describe any specific requirements, and expect the supplier to describe in its bid how these requirements will be fulfilled.
The appendix should also describe the conditions necessary for the authority to approve a product. This non-traditional contractual element can be referred to as a control point— that is to say, as a procedural step at which the authority and the supplier undertake a mutual evaluation of the agreed-upon product specification in order to ascertain whether the agreed-upon product has, in fact, been supplied.
6.18 Summary
The comments in the above section aim to clarify a number of central contract management considerations with which authorities must come to grips when deciding whether to enter into agile collaboration.
An examination of the tables of contents of traditional IT supplier contracts (such as K01 and K02) spur awareness of other problematic issues for which the authority should seek solutions. Finding the right balance between what should be contractually regulated and what should be left fluid depends on the overall state of the authority, its own experience with IT projects, the size of the order, the place of the order in the pre-existing IT environment, deadlines resulting from external factors or legislation, etc.
The trick lies in on the one hand respecting the fact that agile collaboration takes a different starting point than traditional IT supplier contracts (collaboration instead of control) yet on the other hand ensuring that the authority’s choice of this collaboration model does not compromise its adherence to principles of responsible use of public resources. The tables of contents of the state’s standard contracts (K01 and K02) represent a checklist of sorts for the kind of issues that the authority must consider when developing the judicial management framework of agile collaborations.
The authority’s deliberations may, of course, result in the decision that an agile collaboration would not be appropriate or advisable for a particular project.
37
>
7 The Agile Development Process
Agile software development is not a new phenomenon, and the principles of this theory have been in place since the mid-1970s. For example Edmonds’s A Process for the Development of Software for Non-Technical Users as an Adaptive System (1974) and Frederick P. Brookes’ The Mythical Man Month (1975) mention the thoughts underlying agile development. One of the most significant elements in this thinking is the enhancement of communication between client and developer.
Agile theory builds upon prior theorisation concerning development and production processes. The figure below provides a simplified overview of the historical development of the agile development method and how they connect.
In 2001, a number of the creators of the above methods as well as a group of respected software developers worked together to produce an agile manifesto with the aim of laying the foundations for future agile development methods.
The aim was to bring together the essential characteristics of all agile theories and present them in a unified reference work:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. “
38
>
Agile development methodology is not a monolithic concept; it covers a wide range of processes. Nevertheless, all of these are characterised by emphasis on the iterative learning process and a high level of communication with the authority.
One of the most widespread of the various agile development methods is Scrum, which is popular both internationally and in Denmark. The conceptual framework of Scrum is relatively simple and accessible. The National IT and Telecom Agency thus uses Scrum to exemplify agile development methods in general.
The use of Scrum as an example should not be seen as a recommendation of Scrum over other agile development processes. Rather, it represents a practical means of simplifying the complex issues faced by public authorities. We will consider the following processes: Project start-up, including the project organisation; the roles and activities during the project (such as managing the testing and completion of an iteration); and the completion of the project as a whole.
© Softhouse AG
The figure above illustrates how the authority (the man to the left, with the briefcase) engages in dialogue with stakeholders in order to select and prioritise the elements to be developed in the coming iterations. This dialogue results in the authority delivering to the development team an instalment that is now ready for further development in its next iteration. At this point, the development team has the opportunity to work on the delivery in question. The development team manager (the woman in black) ensures that, once the team has commenced an iteration, it is not interrupted unnecessarily.
39
>
She also acts as the authority’s point of contact. The authority nevertheless retains the ability to follow the process from the sidelines by means of daily recap and coordination meetings. Finally, at the end of the iteration, the authority (to the right) has the opportunity to test the delivery instalment.
7.1 Project Start-Up
Sorting out the agile project organisation is the natural first step in the project start-up phase. Although an agile project can theoretically be said to begin the moment the management decides to use the agile development method, we will define the start-up phase as once a supplier has been selected to bring the agile project to fruition. This permits us to differentiate between the internal organisation of the project (as part of the authority’s organisation) and its organisation in collaboration with the supplier.
7.1.1 Internal Organisation
Depending on the ways in which the authority tends to carry out project work, its internal organisation of an agile project can take its point of departure from a variety of models. There can thus be a significant difference between organisations that work in a structured manner using the PRINCE2 project management model and those that use no structured model at all. By the same token, the decision-making process and the degree of user involvement in project implementation are of great significance.
Many authorities will find project groups, steering groups, project managers, steering group chairpersons, benchmarks, and deliveries to be familiar concepts. As far as internal project organisation is concerned, it is generally best to retain those organisational methods with which one is familiar. Adaptability, however, is key: It is necessary to understand that agile development projects usually require the adjustment of organisational frameworks. This is true both for decision-making structures and for project participant roles.
The role of project manager (for example, as described in PRINCE2) necessitates certain changes. A Scrum-based project casts the adjusted project manager role as Product Owner. The roles are nonetheless different. A Product Owner focuses on business needs, prioritisation of development tasks, and the overall development vision. A Product Owner also acts as the link between the development and the business. At the same time, a Scrum Master focuses on the team, its progress, and quality assurance. Whereas a Scrum Master facilitates the development process, a Product Owner facilitates the business process.
Agile development projects require a high degree of user involvement, which can take place in a variety of ways and on a variety of levels. The stakeholders should be involved in the process on an ongoing basis in order to ensure that the project remains focused on business needs and is aware of its priorities. Even though the Product Owner is responsible for implementing needs and priorities within the development process, this can only be done in dialogue with the management and the stakeholders. The internal portion of the user involvement process should focus on ensuring internal approval and prioritising needs and demands.
40
>
The authority’s internal organisation should ensure that the contact points between the client and the supplier are managed appropriately.
The authority’s internal project organisation should ensure that stakeholders possess well-defined roles and decision-making abilities. In the case of a stakeholder external to the authority’s organisation, it is also important to agree upon ways in which the representative can act quickly and decisively. In other words, a well-defined framework is necessary to define the ways in which individual stakeholders are connected to the project and can make decisions regarding it.
The staff as a whole can often be brought together into a sort of working agreement in which both the client and the supplier describe their organisation, responsibilities, and mutual relationships. Such a working agreement can also give the authority the opportunity to ensure stability amongst the Scrum Team members. This is done in order to secure as smooth and flexible collaboration as possible between the authority and the supplier.
7.1.2 Collaboration with the Supplier
As far as organising collaboration with the supplier is concerned, the agile development model makes possible – and to an extent presupposes – a considerably higher degree of ongoing dialogue between the client and the supplier. In order to ensure that this dialogue takes place, it is important to consider the specific means by which stakeholders will be involved, thereby helping them to make real contributions to the development process. “Stakeholders” should here be understood in the broadest of senses, including both people possessing relevant knowledge relating to the actual development requirements (for example, the authority’s IT operations, IT architecture, data infrastructure, etc.) and individuals from the management who represent various parties involved in the project and who can make high-level contributions regarding the business perspectives of the project.
The agile process necessitates that the authority be relatively open and accessible to the supplier. The authority must be willing to free up the time and resources for making active contributions to the development process. Collaboration with the supplier can benefit from being organised in such a way as to make the Product Owner role act as the link between the authority’s and the supplier’s organisations. Contractually and formally, however, the steering group could continue making the final and binding decisions, approvals, changes, etc.
As noted above, we will use the Scrum method as our primary example. Here are the three roles utilised in Scrum:
> Product Owner (usually undertaken by the authority)
> Scrum Master (usually undertaken by the supplier)
> Scrum Team (usually undertaken by the supplier).
41
>
7.1.3 Role - Product Owner
The Product Owner’s most important task is to devise and manage the Product Backlog and to formulate a product vision that emphasises the business needs of the development.
> Product Vision
The product vision consists of a precise definition of what needs to be developed. The Product Owner is responsible for clarifying and delimiting the vision, ensuring that it provides a consistently useful framework for the project. The vision can be modified, but generally speaking, it should remain fairly stable relative to the size of the project.
> Product Backlog
The Product Backlog contains a prioritised account of the authority’s needs and demands. Typically, it should contain detailed descriptions of the contents of the first one to three iterations. For further iterations, it is only necessary to describe general contents since one cannot, of course, predict the entire course of events in advance. This leaves room for changes to the specific demands even as the general needs are well-defined.
Management of the Product Backlog involves the Product Owner regularly detailing needs and demands in relation to what tasks are at the top of the list. For such detailing to succeed, needs and demands must be continually examined, described, and reprioritised as project work progresses.
Detailing consists of ensuring that the highest-prioritised needs and demands of the Product Backlog (i.e., the first to be developed) are sufficiently detailed with regard to content and magnitude as to allow the supplier (the Scrum Team) to determine how many tasks should be carried out in next iteration. The Product Owner, therefore, requires regular input from the stakeholders, input that should to a great extent be evaluated in collaboration with the supplier. This takes the form of ongoing dialogue with the Scrum Master and the Scrum Team aimed at describing the contents of the tasks.
The Product Owner’s ongoing prioritisation of the Product Backlog involves ensuring accordance between the descriptions in the Product Backlog and the stakeholders’ assessment of what is most valuable and should, therefore, be developed first.
If the Product Owner is to manage these tasks, it is vital that dialogue is kept open with relevant individuals within the organisation and that resources are made available to promote this dialogue. This can be ensured by encouraging the Product Owner to convene brief, regularly scheduled coordination meetings with the stakeholders. The Product Owner should use these meetings to gain input for the dialogue with the supplier. It is thus beneficial if the meetings take place over the course of an iteration.
42
>
7.1.4 Roles - Scrum Master and Scrum Team
The Scrum Master and Scrum Team roles should be undertaken by the supplier. The authority can choose to take on the Scrum Master role or even leave it to a third party, just as it can choose to place representatives in the Scrum Team, for example testers, developers, and architects. If you, as a client, choose this option, you need to be aware that this gives you significant responsibility for the development process and makes it difficult to determine who bears ultimate responsibility if the development process fails to produce the intended results.
The Scrum Master must act as coach and facilitator for the project development team (the Scrum Team). If multiple development teams are involved in the project, they will each have a Scrum Master. The most important job of a Scrum Master is to ensure that nothing gets in the way of development and to find solutions to any obstacles so that the programmers can work in peace.
The Scrum Team is the group of individuals who receive the development task. A Scrum Team typically consists of people from the supplier’s organisation though authorities sometimes choose to involve their own representatives as well, especially those with special skills. The Scrum Team is responsible for planning individual iterations (sprints) in detail. This work is based on the authority’s Product Backlog.
7.1.5 Start-up Activities
An agile development project should begin with a series of introductory activities. At this stage, the client should once again differentiate between what project work needs to be done internally and what should form part of the agile process. Below, we will discuss only that which concerns the agile process.
There must be sufficient foundational material for implementing the first iteration. In order to ensure sufficient prioritisation of partial deliveries in relation to the first iteration, one must have an overarching plan for the combined subsequent iterations and their contents. This takes the form of the Product Backlog.
Prioritisation and planning is done in a general sense, but sufficient detail is required to define the various needs and the things that are dependent upon them. As a public authority, one’s vision of the product and its overall needs should be in place prior to any tendering process, but in other cases this can be defined in collaboration with the supplier. Regardless of one’s point of departure, the following activities should form part of the start-up phase:
> Planning of iterations (general) > Agreement on priorities among stakeholders and the transfer of these priorities to
the supplier’s team > Clarification of the developmental conditions and demo conditions.
43
>
The start-up activities should derive their targets from the initial version of the Product Backlog. This Product Backlog should be approved by the stakeholders, should be prioritised in accordance with business requirements, and should be scrutinised, prioritised, and organised with the supplier. In order to give the supplier a clear understanding of the requirements of the stakeholders, it can be beneficial to involve the supplier in activities that provide a comprehensive awareness of user behaviour and needs.
7.2 During the Project
The agile development process consists primarily of a series of iterations built on this same methodology. The authority will require ongoing input from the organisation during this process, and one should be ready to clarify various issues that come up during the course of the project. It is essential that, during the project, the authority is capable of acting quickly and, at times, pragmatically in order to ensure that the process does not come to a halt. One should be aware that an iteration is a carefully orchestrated process in which resources are targeted at completing tasks that have been collaboratively defined by the client and the supplier. Once an iteration is set in motion, both the client and the supplier must thus accept that it is too late to change the process.
7.2.1 Activities during the Project
Taking the Scrum development process as a point of departure, there are a number of activities that the client and the supplier must complete together and for which it is more or less required that the two parties are working on equal terms. As mentioned above, the authority must also undertake evaluations to ascertain internal consensus and priorities concerning the Product Backlog. A carefully crafted Product Backlog ensures that the development process is implemented so as to produce deliveries of high business value to the authority.
The activities taking place during an iteration could consist of (Scrum terminology in parentheses):
> Planning the next iteration (Sprint Planning) > Daily meetings with the development team (Daily Scrum) > Weekly recaps with the development team > Scrutinising and planning the Product Backlog as to the next iteration > Demonstrating the developed elements from an individual iteration (Sprint
Review) > Product Backlog approval meeting with stakeholders > Improving work processes (Retrospective) > Planning the next iteration (Sprint Planning).
The Product Owner should participate in all of the above activities, showing just how involved and approachable a client should be when carrying out an agile development project. Not all of the activities need necessarily take a long time. For instance, daily meetings with the development team may take just 15 minutes. The weekly recap could be scheduled to be half an hour long. However, the planning of iterations and
44
>
work with the Product Backlog takes up a great deal of the Product Owner’s time. Clients must be willing to invest the necessary hours and resources.
A client can plan a project so as to ensure strict adherence to the agile process cycle. In other words, one’s own decision-making processes can be planned to follow the agile cycle. If an iteration is of a predetermined length and follows set rhythms, internal process could be planned accordingly. For example, the approval meeting with stakeholders could be scheduled so that all stakeholders meet at a particular time (for instance, once a month) to deliberate the project priorities. This deliberation is inspired by the preparations (detailing and reprioritising) undertaken by the Product Owner.
Such meetings typically take place in person, but virtual meetings are also possible.
It is important to plan the process so that each iteration ensures further procedural improvements. This promotes continual learning and a shared understanding of the authority’s priorities. Scrum labels this activity “Retrospective”. This is a meeting at which the Product Owner and the development team (Scrum Master and Scrum Team) are brought together to discuss the previous iteration. Could the process be improved? Have new issues arisen? This meeting provides vital input and can help ensure that further development work makes use of lessons learned. The Product Owner takes part in order to ensure that information about the project is accessible to everyone. Conditions may arise that compel the authority to change priorities, or the authority may have information that clarify issues for the development team or help the development team reprioritise its tasks.
7.2.2 Test Management
Testing is an integral part of the agile process. As a result, each iteration will highlight which elements are unsuitable or do not work. The development team’s daily meetings provide an opportunity for feedback on the testing process and data on the reflow which it generates.
Although the level of testing will not remain constant during the iteration, the supplier should plan for regular tests inasmuch as they are vital to the agile process. Everyone taking part in the development process helps define the tests, their demands, and their success criteria.
7.2.3 Completion of an Iteration
Typically, an iteration is completed when the supplier demonstrates that the developed functionality accords with the planned functionality— in other words, that the iteration contains the agreed-upon elements. The Scrum development method does not provide a more detailed definition of just how such a demonstration should be carried out, though it is implied that there will be a visual presentation that includes scrutiny of the product established during the iteration. The demonstration ends with the authority’s approval that the delivered product conforms to that which was agreed upon in advance.
45
>
7.3 Completion of the Project
The project is completed when the final iteration is completed. The authority should then possess a fully developed, tested, and documented product, one which fulfils the needs defined by the authority and described during the course of the project.
Since each iteration is carried out as an independent process in which all elements are tested, a final test of the entire product is unnecessary. If various interlocking elements have been developed parallel to one another, the relevant combined testing should occur during the iterations in question.
One should consider carrying out an iterational evaluation of the process that has taken place. This should concern not only the intimately collaborative work with the supplier but also any internal process parallel to the collaboration. Just as developmental lessons from one iteration should be applied to the next, organisational lessons should be taken into account in the future agile project process.
The evaluation may gain value from including experiences regarding both the process itself and the Project Owner role. It should also make use of insights from the stakeholders.
46
>
8 Appendix 1: The National Survey and Cadastre (Case Study)
Interview with Mr. Søren Reeberg Nielsen
The 1989 merger of Denmark’s Geodetic Institute, Hydrographic Department, and Cadastral Department led to the establishment of the National Survey & Cadastre. Since 2001, the National Survey & Cadastre has been Denmark’s infrastructure business for maps and spatial data.
The authority’s mission to ensure that maps and spatial data promote the development of greater efficiency in public administration. This is in part achieved by acting as chair of the Service Board for Geodata, a public collaboration forum that was established by the Digital Task Force in 2002.
An important aspect of the National Survey & Cadastre is its cadastral responsibility, which forms the basis for land registration in Denmark, including the registration of new property— so-called property creation. Property creation takes place in close collaboration with registered land surveyors, the National Survey & Cadastre, and other public authorities.
8.1 An iterative Project is First Contemplated
Work on defining the framework for future land registration in Denmark got underway in earnest in 2002/03. The National Survey & Cadastre had long understood the need for increasing the efficiency of and replacing the old systems for cadastral casework. Additionally, the National Survey & Cadastre was on a burning platform since it was unknown for how long the old systems would be kept running. The system portfolio was no longer being maintained by an actual supplier, and all work was dependent on internal resources. Moreover, it would not be possible to move the old systems onto a new, more operationally stable platform.
It was therefore decided to start a project that would lead to the development and implementation of the miniMAKS system. In Danish, miniMAKS stands for ‘Cadastral Upgrading and Quality Assurance System’. Together with MIA (Cadastral Information and Upgrading System), it was intended to replace the previous cadastral systems and databases and to simplify and increase the efficiency of the authority’s working procedures.
“Cadastral casework is a very complex area”, explains Deputy Director General Søren Reeberg Nielsen. “We work with more than 100 different case types. Property creation cases move back and forth between private land surveyors and across municipal borders within the public sphere before they’re finally concluded. When we started the project, we knew that we wanted to jettison some of the old working procedures, ones that were dependent on the limitations of the systems we had at the time. That’s why we decided to reduce the plethora of case types and procedures to just a handful of fundamental user stories that could show how we could work with a new system in the future. Since our new miniMAKS system was meant to be able to interface with a variety of other systems, we drew up some central system use cases”.
The National Survey & Cadastre used a technical advisor to assist in its work during this stage of the project. Eventually though, as the conceptual framework for the new
47
>
system took form, the National Survey & Cadastre switched to a new advisor, which was intended to take on a greater role in aiding the authority with project management, for example with the tendering process and subsequent supplier management. The National Survey & Cadastre also consulted the Legal Advisor to the Danish Government.
After a long period of working intensively with user stories and system use cases, the idea came up to develop the new system using an iterative process. “We wanted to use what we’d already described as a springboard, but we didn’t necessarily want to write it all down in the form of highly specific demands”, explains Søren Reeberg Nielsen. “We didn’t want to start off by ‘making the solution’, and most importantly, we were eager to move away from the old working procedures. We wanted to clear some space for whatever good ideas the supplier might have”.
As a basis for the EU-wide tendering of the project, the National Survey & Cadastre made significant use of the user stories and system use cases that had been composed during the initial analyses. The National Survey & Cadastre also placed weight on describing the development process it wished to use.
“The most serious bidders made a real point of explaining which development and project management model they’d use for the project”, Søren Reeberg Nielsen says. “If I were to do it all over again, I’d make sure to be much more astute at evaluating the supplier’s level of maturity working with iterative processes. I’d also focus on the supplier’s project management experience. Next time, the supplier will have to document actual experience, and if possible, I’d like to have references from the supplier and the project manager. I can also imagine that it would be great to hold a workshop with the supplier for a few days during the clarification phase. Then we’d have a chance to agree on how both parties would approach the project. It’s really important to reach a shared understanding with the supplier about what’s needed from both parties for the project to be a success”. Søren Reeberg Nielsen continues: “If I’m being introspective about it, I’ve got to admit that although we were really good at communicating the issue of our burning platform internally, we forgot to communicate sufficiently about what it would mean for our involvement as a client in an agile project. I think that an internal training course in the project method – perhaps delivered by the supplier – would have made things much easier for us”.
8.2 Problems Arise
April 2005 saw the signing of the contract between the National Survey & Cadastre and their supplier. The supplier recommends a course of 8–10 iterations, condensed into 3–4 big releases. The first large release is a system description, which is delivered following a short delay. After this, however, the project simply idles along. The supplier has difficulty transforming the user stories and system use cases into actual programming tasks, and the National Survey & Cadastre’s frustration gradually grows as steering group meetings come and go.
“I think that one of the reasons the supplier had trouble getting started with the programming was that they quite simply didn’t understand the complexity of our work. Just as us at the organisation ought to have been a bit better informed about the project method, the supplier should have been up to snuff in its understanding of our
48
>
business”, Søren Reeberg Nielsen explains. He continues: “The supplier had, actually, taken on a land surveyor company as a subcontractor. They know about the business, of course, since they’re in contact with us. But only a few folks with the supplier got a sufficiently clear idea of what we do. And the supplier never managed to build up this knowledge, not even among the people who were most involved in development. Next time, I’ll make sure that we include a training course for the supplier. You can’t really have a conversation when one party doesn’t understand the business”.
Ten months after the supplier began its work, the project has reached a standstill. “At that time, we were in direct dialogue with the supplier’s top brass, and it was clear that the lack of progress was down to more than simple ignorance of our business and insufficient experience on the part of the project managers”, Søren Reeberg Nielsen says. “The supplier was in the middle of a merger with another company, and this internal organisational reshuffle meant discontinuity. There were times when the management’s focus on our project disappeared entirely”.
The National Survey & Cadastre had to consider whether the situation was serious enough to merit tendering for bids again and finding a new supplier. The supplier had inserted a new and more experienced project manager into the development. However, this project manager wished to switch from the agile development method to a waterfall method, which clashed with the authority’s desire for a project that was flexible to changes in terms of needs and demands. The National Survey & Cadastre nevertheless decided to keep the same supplier, in part because the supplier’s management had gotten involved and entered into the project’s steering group. A result of this choice was the sacrificing of the agile project form. The project’s conditions changed on one significant point though, resulting in a list of 52 change requests.
Even though the project ended up being somewhat delayed in relation to its original schedule (a schedule that Søren Reeberg Nielsen admits was ambitious), the miniMAKS project reached a favourable conclusion: Following a glitch-free data conversion, the system was up and running in 2008.
8.3 Building Trust between Client and Supplier
Søren Reeberg Nielsen feels that the National Survey & Cadastre has learned some valuable lessons from carrying out the miniMAKS project, and these are lessons that he would like to share with others involved in similar projects. In order for an agile development project to succeed, it is vital to build trust between the client and the supplier. Both parties have to feel and experience that their goals are in accordance. Søren Reeberg Nielsen holds that it is possible to “force” some of this accordance through on a contractual level. For example, the contract’s payment plan and penalty clauses can help keep the supplier focused and motivated right up until the delivery of a satisfactory product. However, Søren Reeberg Nielsen also highlights the need for both parties to take the time to understand one another’s business and way of working. As mentioned above, this can take the form of the authority investing employees’ time in learning about the development method used by the supplier, with the result that the employees become better at and more qualified to discuss issues with the supplier, for example when it comes to evaluating and approving partial deliveries. “A good caseworker will be very focused on whether the casework can be done correctly with
49
>
the new system”, Søren Reeberg Nielsen points out. “If you aren’t trained or prepared to think holistically and disregard the lack of detail, it can be difficult for the client and the supplier to engage in good dialogue”. Just as the authority invests time in understanding the supplier’s development method, the supplier should invest time and resources in attaining a broad understanding of the authority’s business and the challenges that the authority wants to meet with the new system. This understanding is necessary if the supplier is to get stuck in quickly and start producing deliveries that are of real business value for the authority.
Søren Reeberg Nielsen does not feel that this process can be forced; trust between the client and the supplier has to be built up. “Ideally, one should – depending, of course, on the size of the project – devote a couple of months to building up the project knowledge and organisation”, Søren Reeberg Nielsen says. “At the same time though, the supplier should be required to place managerial focus on the project, for example by having the upper management attend steering group meetings. And finally, I feel it’s important to require the greatest staff continuity possible regarding the project. This ensures that the supplier’s knowledge doesn’t go to waste”.
8.4 Schedule must Allow Time for Reflection
According to Søren Reeberg Nielsen, it is important that the schedule allows time for proper and reflective evaluation of the deliveries coming from the supplier. It is pointless, Søren Reeberg Nielsen feels, if a new iteration is underway even before the previous delivery has been appropriately demonstrated and discussed with the users and other stakeholders who need to be involved in the process. Especially as far as large releases are concerned, it will take longer time than the literature on agile development processes typically indicates to approve the delivery (by involving users and the management), revaluate the requirement specification on the basis of the delivery, and prepare for the next iteration.
8.5 Communication is Important
Søren Reeberg Nielsen is convinced that agile development projects require much higher levels of communication and dialogue than most authorities are accustomed to. It is necessary to communicate regularly with the supplier and keep a finger on the pulse of the project, thereby allowing one to evaluate whether the project is progressing and the supplier is moving in the right direction. Nor should one lose sight of communication within the authority. Ongoing dialogue on where the project is going is a prerequisite for gaining internal support for the development. Once begun, agile development projects can change course, and such changes will be documented via changes to the dynamic requirement specification. Nevertheless, this provides nowhere near the level of documentation that one expects from waterfall projects, in which such changes are documented by contracts on change requests, etc. It is therefore important that all changes are communicated clearly and precisely to the parties involved in the project.
50
>
9 Appendix 2: ADF and ALO (Case Study)
Interview with Mr. Mick B. Nielsen, ADF and Mr. Niels Peder Pedersen, ALO
Admiral Danish Fleet (ADF), which was established in 1961 and is based in the city of Århus, is the operative headquarters of the Danish navy. The headquarters has approximately 300 employees, of which about half are involved in 24-hour security functions at the Maritime Rescue Coordination Centre.
Admiral Danish Fleet undertakes assignments in Danish waters as well as participates in international operations. The authority’s domestic work includes surveillance of Danish waters, search and rescue services, maritime protection, and combating marine pollution. Many of these assignments are carried out in close collaboration with other authorities both within and outside the Ministry of Defence, including the Police, the Danish Maritime Authority, the Danish Maritime Safety Administration, the Danish Emergency Management Agency, the Danish Meteorological Institute, the Danish Ministry of Taxation, and other public authorities.
Assignment work is carried out around the clock at the Admiral Danish Fleet’s operations centre, in which navy and air force personnel coordinate the insertion of ships and planes. The operational units at the core of the assignment work are delivered flexibly by the Naval Helicopter Service, the Naval Frogmen Corps, the Danish Air Force, and the Danish Naval Home Guard.
For project-based development assignments, ADF collaborates with the Acquisition and Logistics Organization (ALO) of the Danish Defence. ALO is the military’s logistics authority and is responsible for maintaining, developing, and phasing out materiel capacities – from combat vehicles to boots, from fighter jets to pocket knives – for all of the military authorities. ALO is part of the Defence Command and manages nearly DKK 7 billion of the total defence budget. Besides supplying materiel capacities, ALO carries out projects for the Navy, Army, and Air Force. It is also an important player when, for example, ADF undertakes projects involving the procurement and development of new operative IT systems.
9.1 System Restructuring
Central to ADF’s work is the Royal Danish Navy Command Control and Information System (RDNCCIS). The first version of this IT system began operation in 1985. Prior to implementation, RDNCCIS was a traditional development project in which the system was described by a detailed requirement specification.
“It was possible to develop the first version of the system the way we did because, at that time, we were working in a relatively stable environment. Things hadn’t advanced too significantly from when we started specifying the system to when it was ready for use. It’s not quite the same today”, says Commander Mick Nielsen of ADF.
Already after a few years’ use, ADF could see that the system’s capacity would be a limiting factor. The first major change to the system therefore consisted of restructuring the underlying system architecture by switching from a mainframe solution to a more modern client/server solution.
51
>
The task of restructuring the system from one platform to another appeared relatively simple on paper. There were, however, a few challenges to take into account. For one thing, the system is in continual use by about 30 operators— 24/7, 365 days a year. Additionally, some of the technology for the new, restructured solution was still stuck in the development stage with the suppliers. Thus, even though one had a general idea of how the solution would look and function, much was still unclear and would remain unclarified until the suppliers finally developed the technology to completion. In part on account of these issues, ADF and ALO decided that it was best to carry out the restructuring in phases.
“We were well aware that we’d be learning as we went along. And that’s why we decided to work with a series of iterations, which would allow us to regularly adapt the system when new technology was introduced and to gradually transfer functionality from one platform to the other. This time around though, we didn’t want to follow the ‘big bang’ approach to development and implementation”, says Niels Peder Pedersen of ALO.
Mick Nielsen of ADF adds, “At this time – I mean, in the early- and mid-1990s – we were working on relatively long iterations, about half a year in duration.” Like Niels Peder Pedersen, Mick Nielsen believes that it is difficult to estimate in advance just how many demands for a system one will have. Over the course of the development process, a series of outside influences began affecting the project. For example, the EU had gotten underway with a specification of the SafeSeaNet system, with which the Danish system would one day need the capacity to integrate.
It is thus that the agile method of iterative development was introduced to the ADF and ALO collaboration.
Following the restructuring of RDNCCIS at the end of the 1990s, a series of events took place that laid the foundations for the next significant modernisation of the system. The ERIKA oil tanker catastrophe of 1990 pushed the EU to devote further resources to the development of the SafeSeaNet system, which is an EU-based electronic network for the exchange of maritime information between member countries.
The 11 September 2001 terrorist attacks on the World Trade Center in New York sharpened international focus on harbours and other facilities that are particularly susceptible to breaches of immigration law, etc.
This led to the 2004 political decision to establish the MASOC (Maritime Assistance Services Operational Capability) program, which was intended to strengthen ADF’s ability to offer maritime assistance. The program covered integration into SafeSeaNet, the fusion of the Danish sea- and air-based rescue centres into the Joint Rescue Coordination Center, and the creation of a centralised maritime contact point. Niels Peder Pedersen and Mick Nielsen were at that time in complete agreement as to the necessity of implementing MASOC in a series of small instalments, each of which would, wherever possible, be developed iteratively.
52
>
Mick Nielsen says, “We’ve become aware that, ideally, projects shouldn’t last longer than 6 to 12 months. They need to fit inside your head and consist of around six iterations”.
Niels Peder Pedersen adds, “The way things are today, the world around us is constantly changing. As a result, it’s important to be flexible and adaptable to new needs and demands. Trying to fix needs and demands early on in a project is unworkable because both internal and external assignments and circumstances are changing all around you”.
Since MASOC was to be used by the military, ALO and ADF were not required to go through the tendering process. The parties could therefore directly select known suppliers with which they had already had good working relationships and positive experiences. Niels Peder Pedersen feels that it would have be a greater – and more difficult – task had he needed to have sent the project out of tendering.
9.2 Communication, Communication, …
Many years of experience with iterative development projects and work with various agile methods have granted ALO and ADF valuable experiences that they bring to bear on their continuing collaboration.
When it comes to dealing with stakeholders, Mick Nielsen and Niels Peder Pedersen agree that tight expectation management is key to prioritising demands from both system users and the organisation’s management. The challenge to acting as the link between the supplier and the internal stakeholders is that it is not always clear in advance which new demands will be made and how these will affect preexisting and described demands. As a result, it can be difficult to give precise answers as to when delivery can be expected. Part of the solution to this challenge is communication. Keep the management and other stakeholders regularly informed about the project’s progress. This information should also include the risk of errors, delays, and other potential bad news.
Mick Nielsen says, “You can’t communicate too much— only too little. As soon as something happens with the project – and of course, something is always happening – you have to communicate the news. Agile development projects should simply course with information. It’s incredibly important to create the necessary trust both between the client and the supplier and between the project management and the rest of the organisation— between the users and the management. You have to be on the ball and tell people about the things that are going well and the things that are going poorly”.
Niels Peder Pedersen mentions that most authorities are unaccustomed to the extent of ongoing dialogue and engagement with suppliers that agile development projects require. He notes, however, that this interaction is rather evenly distributed across the project’s running time. Whereas clients in traditional development projects are usually closely involved in the specification phase and during testing and implementation, working with agile development means staying involved the entire time. Following each iteration, the agile project framework typically calls for testing of the developments, requirement specification of the functions to be developed during the next iteration, and perhaps even implementation and use of the delivered functions.
53
>
The fact that ongoing dialogue takes place alongside development, implementation, and operations means that agile development requires greater investment not just from the project management but also from other bodies within the organisation, for example the IT department.
Agile development projects allow future users to quickly begin testing the system inasmuch as the users receive regular instalments with which to involve themselves. Even though user involvement usually leads to new requests and demands, Niels Peder Pedersen views it as absolutely vital: “User feedback gives us a much better chance of correcting the project’s course in case the supplier suddenly goes off on a tangent”.
9.3 Handling a Dynamic Requirement Specification
Niels Peder Pedersen and Mick Nielsen note that handling a dynamic requirement specification – the type typically used in agile development projects – is not wholly unproblematic. The regular stream of adjustments, both small and large, makes it difficult to evaluate how these new demands will affect the project’s eventual solution and budgetary status. New demands that change the project’s preexisting underlying elements can be especially difficult to handle.
Mick Nielsen mentions one point of particular importance in the handling of a dynamic requirement specification: It is vital to have the management’s support. Inherent in a dynamic requirement specification is the risk of the project going off track or going over budget in the event of too many or too major new demands.
Once again, communication is part of the solution. The better the management is informed about the project and potential setbacks, the easier it is to manage the project. At ADF, Mick Nielsen and Niels Peder Pedersen have worked to balance the risks of agile development projects against the risks of more traditional development projects, the latter of which entail the risk of clients ending up with a product that, at the time of delivery, does not live up to their actual business needs and demands.
Finally, Mick Nielsen feels that the agile development method requires clients to be better at budgeting. The experience at ADF and ALO has been that, on the one hand, ongoing dialogue and close collaboration between the users, the supplier, and the management means that projects rarely goes seriously off track. On the other hand, the addition of new demands – especially external demands – can contribute to making a project more expensive than anticipated. Of course, one has the choice to prioritise new demands and reduce product functionality, but this is sometimes either impossible or inexpedient. Generally speaking, the feeling is that agile development projects produce higher quality products in relation to business requirements. Mick Nielsen feels that, if you know in advance that new demands will be necessary, it is best to budget them in. A rule of thumb for ADF’s and ALO’s projects is that the final requirement specification will be approximately one-third larger than the initial requirement specification.
At ADF and ALO, the agile method has become a fully accepted means of carrying out development projects. Mick Nielsen and Niels Peder Pedersen are in agreement that it would be difficult – if not impossible – to return to the old ways, in which
54
>
55
everything was specified in advance. That is why they set for themselves the following guidelines when working on their projects:
> Break large projects down into smaller, independent projects that can be handled in between 6 and 12 months. A project should be small enough for a single person to comprehend it in its entirety.
> Make sure that you receive the management’s support and approval. > Make sure that there is a steady flow of information about the project to all
relevant stakeholders. > Involve the users from Day One. > Find ways of building a relationship of trust with the supplier, and make sure that
the supplier knows and understands your business.
Agile Methods in IT-Based Business Projects
Guide to Agile Development in the Public Sector At the request of the K02 working group, the National IT and Telecom Agency has produced a guide on the use of agile methods in IT projects. This guide aims to support the use of agile development processes in the public sector’s IT-based business projects. The guide will hopefully help qualify the basis for decision when it comes to commencing a new IT development project in which one may want to apply an alternative project management method. The guide should also help authorities enter into contracts that differ from the traditional IT supplier contracts, with their fixed prices, deadlines, and services. This publication comes as a result of the recent increase in interest concerning the management of public sector IT development projects. The 2008 National Audit Office of Denmark report, for example, revealed some of the challenges facing public authorities working with IT projects. This has placed additional focus on efficiency in IT investments and has led to stricter methodological requirements on how public sector bodies go about IT development projects. Opting for agile development processes represents a strategic managerial shift that requires focus, will, maturity, and effort on the part of the public authority. In addition, one must ensure that the supplier is capable of delivering the required product without possessing complete requirement specifications at the start of the project.