This presentation tells what things are essential for any contract, what information has to be included in typical software development contract, what has changed after agile software development approach emergence and how to prepare your own agile software development contract.
28. Legal frame
Quality requirements
Supplier’s scope of supply:
a) non-functional requirements
(for example, technology requirements, integration
requirements)
b) support and maintenance of functionality in
production
30. Together with a
customer gather
user stories for
least possible
project scope that
brings value to a
customer
Gather non-
functional
requirements
Agree with a
customer on
software
development
approach and
explain involvement
requirements
1. 2. 3.
31. Agree with a
customer on
needed
deliverables and
acceptance
procedure
Agree with a
customer on price
and payment terms
Prepare a legal
frame
5.4. 6.
32. Sources of inspiration
Agile Contracts by Alistair
Cockburnhttp://alistair.cockburn.us/Agile+contracts
Agile Contracts by Tom Arbogast, Craig Larman, and
Bas
Voddehttp://www.agilecontracts.org/agile_contracts_prim
er.pdf
Scrum guide (in
Latvian)http://www.autentica.lv/lv/article/scrum-celvedis-
latviesu-valoda/
original (in English)
http://www.scrumguides.org/scrum-guide.html
Typical software development contract consists of:
1) legal frame – part of a contract which contains general information about a project and contains references to attachments;
2) supplier’s scope of supply – functional and non-functional requirements of a solution;
3) Price and payment terms – price and terms when and how it is paid;
4) customer’s scope of supply – material and non-material deliverables, which a customer has to supply;
5) quality requirements – measurable requirements of a software solution (e.g, performance requirements, requirements towards number of known errors);
6) project plan –activities required to meet project goals scheduled in time;
7) project governance – the way how a customer and a supplier will keep control over a project;
8) delivery and acceptance –project deliverables and their acceptance criteria;
9) change implementation procedure – contains principles, how to change a scope of a project.
Contract is not a document written by lawyers and used only by lawyers, but it is a document that describes the way how a customer and supplier will cooperate to create an IT solution and reach goals of a project.
Each member of a team needs to know a contract to some extent.
Contract needs to reflect reality, i.e., how an actual work will be done during a project. If contract does not reflect a reality, then reality changes to reflect what’s written in a contract, not vice versa.
Changes in a contract can be made at any time during a project – there is no need to spend too much time before the project to have a perfect contract.
Each contract motivates people act in one or other way. Good contract motivates people to cooperate in order to reach project goals.
Has there been a lot of changes since agile was started to be used in software development projects? Not so much.
If there is no clearly described outcome, then it will not be possible to demonstrate solution at the end of each sprint.
It is important to have the LEAST possible scope and use it for learning. Since agile has built-in option of self-improvement, both a customer and a supplier will be more informed and able to build better IT solution.
It is also important to reach a level where a scope brings added value, because then a customer will be able to use it for a business and feel safe about an investment.
In order to be able to replace user stories and prioritize them there has to be an estimate for each user story.
If you are not able to explain your payment term in 60 seconds, there is a great probability that a customer will not accept them.
There is no link between software development approach and payment terms – agile does not mean time/material.
The most often used are fixed price contract, where fixed price is number of complexity points multiplied by a price of a complexity point.
Focus of this section has shifted from infrastructure to participation in a project. It is very important that a customer understands software development approach and requirements towards involvement in a project.
Although it would be nice to start programming solution immediately, there is usually a need to spend some time on doing formal things like getting access to environments, setting up infrastructure etc.
Although system testing is done during each sprint, there is a need to test a whole solution.
Usually there is no need of having separate governance procedure, since there are frequent meetings with a customer as part of agile software development approach.
Delivery and acceptance procedure has shortened, because software has to be potentially shippable at the end of each iteration.
Documents are accepted he same way as before.
User stories can be replaced or they can be eliminated at all.
Support and maintenance of a solution starts as soon as some part of functionality is given to the end users. This should not be forgotten.