Tuesday, 16 December 2014 00:00

Ten Thoughts on Contracting Out Agile Software Development

Written by

In my company, we operate IT projects under Prince 2 . For some types of software delivery we find agile methods are appreciated our customers. In these cases we use the two approaches in a complimentary way - software products of the Prince 2 project are delivered using an agile method. We find the sweet spot for Agile methods is in-house development where requirements are uncertain, there are changing needs and the development team size is 2 to 6 relatively experienced people.

The 2013 State of Agile Survey results give an industry wide view of the perceived benefits of agile methods, while Rico’s paper on the business value of agile project management , gives an overview of quantitative studies of the benefits. In terms of agile methods my company typically uses Extreme Programming and Scrum .

The advantages of agile methods that we appreciate are:

  • An agile development can effectively accommodate strict time constraints (by number of iterations) and budget constraints (the cost of the team for the number iterations) managing scope (which features from the backlog are scheduled) and maintaining required quality.
  • The discipline of delivering user valued functionality in time bound iterations manages many risks. In a project where the customer has tested and accepted deliveries every two weeks it is difficult to find a sign-off block towards the end. Any deviation from planned velocity is visible from the first iterations.
  • Detailed requirements analysis is done just in time so less time wasted in detailing requirements or features never built.
  • Early iterative delivery sometimes allows return on investment earlier.

We are moving towards contracting out a proportion of software development work. Traditional models for contracting out include time and materials and fixed price delivery. Most of us appreciate the risks of these extremes of the spectrum. In the first the supplier’s economic objectives are clearly not aligned with those of the customer. The second extreme favors inversion of the Agile manifesto ; focusing on artifacts, process and contractual negotiation rather than collaboration, embracing change and working software.

The question many ask is, can we retain the benefits of agile methods when contracting out software development? Others have studied this question including Abogast, Larman and Vodde . The following analysis derives from our use of agile methods in-house and in two tenders for software development recently conducted through the UN Global Marketplace .

The first lesson we learnt in contracting out agile software development (or anything else for that matter), is to align objectives of the supplier and the customer. It is highly desirable to align supplier success with customer success.
The key here is to define the product vision and what must be achieved; foster shared ownership of the goals by treating your supplier as a partner; and consider offering the supplier incentives for meeting key business performance indicators that require partnership with you.

1. In contracting out Agile software development, contract the product vision, define the desired end state and define how completion will be determined.

Define how the project is to be run. Tasks that are done repeatedly in each iteration or sprint become smooth and efficient. Tasks that are left as one-offs for the end of the project contribute to the, “ninety-ninety rule” , and those interminable delays that occur in the last 10 percent of the project.

2. As far as possible minimize the number of one-off tasks by doing them incrementally in each iteration.

Ideally delivered software should be integrated into your environment and your project management methods ready for you to take over control without further effort. We therefore recommend you make your toolset for software development (e.g. source code versioning, backlog management and continuous integration) available to the supplier and require them to use your tools from the beginning. If you have a deployment and quality assurance team, we recommend they do their part in every iteration. We recommend selecting suppliers with a strong ethos of automated testing and test driven development. There is nothing more frustrating for your users than finding the same regression errors in each iteration.

In terms of the agile method, the contract must establish key control points, e.g. how iterations are planned and accepted and the parts of the agile method are mandatory.

3. The contract must define essential process and toolset requirements without unnecessarily limiting the supplier’s freedom to work in the best way possible.

The contract appendices must define conditions for acceptance of each iteration. These will include the tests to be conducted and passed including user acceptance; the standards that must be adhered to (e.g. coding, security, architecture, look and feel, quality, performance, accessibility) and how they will be validated; and what documentation and knowledge transfer is required.

4. The contract must define the conditions for acceptance of each iteration and the overall product.

Do not throw away years of acquired wisdom when authoring the first contract for agile software development. Examine each of the boilerplate clauses your organization typically uses. Clauses on ethical standards, intellectual property, information confidentiality, and maybe even liquidated damages are as relevant to Agile delivery as to any form of delivery.

Related to this, the question of warrantee of delivered software often arises. We recommend warrantee only if the code will not be modified by other developers subsequently. Requiring warrantee will not make proposals cheaper, but proving that a bug derives from the work as delivered can be time consuming.

5. Do not throw away years of acquired wisdom when authoring your first contract for Agile software development.

Some argue that the supplier team membership should be formalized in the contract and changes should be authorized by the customer. On the face of it, this may sound attractive but it dilutes supplier responsibility for the team and the team’s delivery. Our recommendation is to contractually establish the customer’s right to authorize changes to people in customer-facing roles only, and specifically, the scrum master/leader.

6. The supplier should have the responsibility of providing a multi-disciplinary team capable of doing the job.

The contract must provide a mechanism to ensure that both parties are comfortable with the proposed scrum master or team leader.

7. The Scrum Master or team leader will probably be from the supplier side but supplier and customer need to agree that the Scrum Master is suitable and well qualified for the job.

The product owner is another key role and will be nominated from the customer side. They represent the customer and communicate the customer’s vision and requirements and most importantly, from a contractual point of view, ultimately control the backlog.

The Agile Manifesto says, “the most efficient and effective method of conveying information to and within the development team is face-to-face conversation”. Co-location of the team is therefore desirable but not always possible. Sondra Ashmore 2012 examines impact of process on virtual teams on agile and waterfall projects.

Embedding a member of the customer team in the supplier development team by mutual agreement is an often workable one fall back option. This gives the supplier team insights and interpretations; and the customer can get an early heads up of supplier side tensions and problems. It is important that these arrangements do not undermine the role of the product owner.

8. Ensure the product owner knows the Agile method in question, has a stake in the delivery and can dedicate sufficient time and energy to the project and assessment of deliverables. Contractually establish the role and responsibility of the product owner.

We recommend measuring progress counting only fully accepted features when they are accepted at the end of time boxed iterations. The contract must make provisions for how to handle issues such as higher or lower velocity than expected.

At a very basic level, specifying that iterations are time-boxed; setting a minimum proportion of features as a criterion for acceptance of an iteration; and making payment on the basis of accepted iterations or sprints offers the customer a reasonable degree of control.

9. Establish how progress will be counted, the rate of implementation will be measured and the payment schedule.

When software is delivered only after significant investment of time and money, early termination is a huge risk and requires a lot of attention in the contract. With agile methods it is still necessary to consider early termination but exposure is more limited.

Whilst an obvious option is symmetrical right to terminate after each iteration, such short notice may deter a supplier from bidding for, or committing their best resources to the contract. In long projects it may be better to define groups of iterations that arrive at a cohesive state as optional termination points.

It is also important to consider what actions are required with termination, e.g., what becomes of partially developed products or materials provided for the execution of the contract.

10. Establish conditions for early termination and what actions are required by both parties upon termination.

Regarding future plans, we aim to re-use the contracts we have and use lessons learnt to improve our future formulations. We would also be interested in hearing of your lessons learnt in this area.

Don't forget to leave your comments below.

http://davidfrico.com/rico-apm-roi.pdf The Business Value of Using Agile Project Management for New Products and Services
http://agilecontracts.net/agile_contracts_primer.pdf - AGILE CONTRACTS PRIMER
http://lib.dr.iastate.edu/cgi/viewcontent.cgi?article=3267&context=etd The Impact of Process on Virtual Teams: A Comparative Analysis of Waterfall and Agile Software Development Teams

Read 9268 times
Richard Hoad

Richard Hoad is Senior Officer for IT Sourcing in the IT Division of the Food and Agriculture Organization (FAO) of the United Nations. Prior to that he was Chief of the Knowledge Information Systems Branch of the IT Division and before that he ran the Project Management Office.

© ProjectTimes.com 2017

macgregor logo white web