SWE II: Agile Contracts Flashcards
Agile contracts
- Goal: successful project that is different from successful contract.
- Avoid silo mentality.
- Involved lawyers should understand agile principles (values)
Agile manifesto: principles
Agile values
Key points of contract
Agile contracts vs traditionals
Why is quality not set? It is very important! Otherwise stories are delivered but with low quality!
Variable scope: means that depending on the situation the team is going to deliver a product that is not clearly defined in the beginning.
Delivery cycles
At each iteration (of fixed length) contractors deliver deployable system with useful feature.
Key points: “doneness”, ready for deployment, duration, timeboxing (fixed time).
Project scope
Project scope in agile contracts is not fixed:
- Target-cost contract: change scope based on the current situation, making the best possible with what is available. Included machanisms for chaning scope.
- Progressive contract: scope is defined only for next iteration, then re-defined.
- Maintenance and additional work are implicitly included
Change control
Change is fundamental to agile strategy.
Relationship between parties may change (but defined in contracts)
Project scope may change (not stories already committed)
Termination
An option of change.
Ideal option: allows customer to stop without penalty at the end of any iteration.
- Early termination should be viewed as a postive aspect.
- Typically a sliding scale of penalty is implemented by the contractor to the customer.
Acceptance
Contract should define the framework for acceptance only.
Acceptans ::= conformance to agreed-upon acceptance test suite (automated).
Possible involvement of prospective users in the acceptance.
Deliverables
Contracts often contain a list of deliverables, but in agile contracts this should be avoided:
- Distracts focus from working software
- attracts focus to conformance (e.g. we have to commit 4 stories each sprint), rather than collaboration
- Reinforces false belief of predictability
Documentation may be included, but may only be useful in maintenance phase.
Source-code is not always included: usually a software is accessible through a repository, but the customer doesn’t own it.
Limitation of liability
Early and frequent delivery helps in reducing liabilities, because issues get discovered earlier and fixed soon.
I can offer warranty in a similar manner, since I deliver frequently.
Timing of payment
Usually after each iteration acceptance 100% of the iteration price is payed.
Deferred payment may be applied.
Pricing scheme
Pay per use: by number of connection/active users/registered users.
Fixed-price, fixed scope
Loss-loss strategy.
Selecting lower price, other companies will lower their, you will end up with low quality SW.
We can still replace existing requirements with new ones of equal effort.
Or change order of implementation (priority).
Or improve def. of done.
Including additional released priced in Time and Materials.
Set early termination price: e.g. 20% of remaining unbilled value.
Agile misconception
Time and materials
These type of contrats fit perfectly with agile.
Iterative nature solves typical issues:
- the endless cycles fo payments before useful results
- Good value for the money?
Exposure mitigations:
- Capped Time and materials per iteration/project/release
- capped time and materials per iteration w/ adjustments
Variable-price variable-scope
Continue working until I get something that satisfies my customer, I continue adding iterations.
Before each iteration, customer and supplier agreen on a goal (with an horizon of 1 or two iterations.
Customer exposure is limted: termination at any iteration with a working system.
Flexibility levels
3 variables: price, scope, time can range from fixed to flexible.
Examples:
Capped price, partial fixed scop: small subset of requirements fixed.
Fixed-price, variable scope: with fixed-time becomes optional scope.
Fixed price per iteration
Requirements defined and agreed upon before iteration.
Like fixed-price per project but with smaller scope.
Supplier must estimate correctly.
Supplier adds contingency fee for risk.
Maximum transparency!
Fixed price per unit of work
UoW == running, tested features.
Working software is primary measure of progress.
Measure of features:
- story points, feature points, use case points, function points
Issues:
- Feature measurement should be standardized, there shuold be a shared framework between customer and supplier.
- Business values vs size points
Risk shifting and sharing
Align motivation of the two parties.
Sharing: both parties have skin in the game.
Shifting:
- Risk to the party that is more accountable
- Requirements-related risks in the hands of customers
- technical related risks in the hands of supplier
Hybrid Target cost
To shift the risk we can use shared pain and gain.
Cost definition:
- identify and estimate requirements and change cost
- Supplier establishes a target cost and calculate target profit
- Share result with customer.
During project execution:
- Actual cost of tracking and sharing
- Determine adjustment = (actualcost - tgtcost) * customer share
- Payment = targetcost + target profit + adjustment
Tradeoff with Time and material, avoids costs becoming too large.
Key elements:
- Higher transparency and near-real time open book
- Collaboration for continuos improvement
- Agreement on guidelines for target-cost adjustment (inherently fuzzy)
- Test-driven acceptance
- Works only if the team is trusted.
Multiphase variable model
- Projects have a changing risk profile over time
- Hopefully risk is getting smaller over time
- Mulitphase adjusts contract type to accomodate risk change
Risk bounding
- Level of trust is a key element
- For example with a new supplier:
- 1 year: fixed price, fixed date, variable scope
- Series of 2-months, fixed price, fixed date, variable scope contracts, with termination option at each iteration.
- A few low risk contract cycles may help build trust.
