Read Part -1 here. Continuation ..
The depth of the relationship and level of dependency the customer has towards the supplier vary depending who has the most specific technical knowledge to give to the project. The beginning of the project should contain active communication that lays foundation for the standardized mode of development used during the project in order to build trust between (at least) the key communicators. Few indicators which are of course context based are given below.
- Pricing models can vary but fixed-price is probably the customer’s favorite but difficult for Supplier: Customer pays a fixed amount and gets a fixed set of features at the agreed date. The end product has to contain the features agreed in the contract. The pricing of the project would need to be defined in the contract in a way that would drive both parties towards the joint success of the project. The pricing model (bonus paid when release meets its success criteria) oﬀers reasonable incentive to the supplier. Cost plus pricing or performance based pricing, target cost shared pain&gain, etc some of good fit models. Combination of pricing models should be right thing to do.
- Project may uses bonus/loss pricing model where the supplier will work under reduced hourly rate if the target is not reached and gets a compensation for the whole project if the project is finished early. When some of the requirements change, the others are adjusted so that the total scope of the project does not change or, if that is not possible, the plan or target-cost is adjusted accordingly. The contract should state who has the authority to do the changes to the project. Poppendieck and Poppendieck suggests that the customer incentive is a clause that if the actual cost is significantly higher or lower than the target, new cost-sharing negotiations should be held.
- Sharing of risk and rewards: Supplier not just takes the reward or penalty, this even applies to customer – both penalty and reward. E.g.: The customer should be entitled to compensation for direct damages (and not for indirect damages) caused by delay to the extent by which the damage exceeds the contractual penalty
- Acceptance test is traditional delivery is one time, but in agile that will be different
- Warranty and Liability. E.g. All the errors have to be fixed by the supplier at his own expense without a delay, and the supplier has to pay a contractual penalty for the time used for removing the errors after the agreed delivery time
- The termination of the project should be easy and can be done after any iteration. In order to this to be fair for the supplier, the customer will pay compensation for the next iteration for the resources the supplier cannot immediately reallocate
- Defined responsibilities should have to contain the right for the product owner to do small changes e.g. changing priority of the features. Unlike in traditional development where customer collaboration is minimal, agile development needs a contract that clearly states the activities needed from the customer.
- One of the main ideas in agile is the rapid change management. Still, even agile projects cannot aﬀord to not to have any change management procedures, and larger agile projects do need a steering committee to handle the business requirements as well as larger changes to the project. It should always be stated in the contract who has the authority to do changes, but for small changes (that do not aﬀect cost or schedule) this could be someone else than the steering committee, e.g. the product owner.
- Resources should be replaced ASAP E.g. within 2 days and any delay should come under risk sharing clause
- When using Scrum or any other agile process model with short iterations the contract should specify the agreed duration of each iteration. Contract also should provision If all the agreed items in the sprint cannot be completed, the unfinished items should be put back to backlog to be implemented in the future sprints.
- Another key aspect in agile is to deliver working software to the customer after each iteration and have the software as the primary measure of progress. But how to determine this when the deliverables are small and missing lots of the features the final product needs to have? This can be achieved by defining an agreed “Definition of Done” ideally already in the contract that can contain e.g. items like: all code is reviewed and tested (acceptance tests as well as non-functional tests such as performance tests), all code follows agreed coding standards and have been refactored when needed, and all necessary documentation has been completed.
- Initial Product backlog: Agile projects also need some sort of specifications to start with, which in traditional development methods can take months to define. One way of doing specifications is special time boxed two day intensive workshop to specify and plan the project. During this period, the project stakeholders get together and a trained professional will squeeze the requirements and their priorities out of them. The end result is a prioritized, work-estimated high level release plan for the project. This plan can be used as the base for the contract, but agile principles should not be forgotten. This is just the first guess about the future stories and will become more precise and sure will change when the development starts.
To be continued in next article.
Read Part -3 here..