SWE II: Agile Contracts

Question 1

Agile contracts

Answer 1

• Goal: successful project that is different from successful contract.
• Avoid silo mentality.
• Involved lawyers should understand agile principles (values)

Question 2

Agile manifesto: principles

Answer 2

Question 3

Agile values

Answer 3

Question 4

Key points of contract

Answer 4

Question 5

Agile contracts vs traditionals

Answer 5

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.

Question 6

Delivery cycles

Answer 6

At each iteration (of fixed length) contractors deliver deployable system with useful feature.

Key points: “doneness”, ready for deployment, duration, timeboxing (fixed time).

Question 7

Project scope

Answer 7

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

Question 8

Change control

Answer 8

Change is fundamental to agile strategy.

Relationship between parties may change (but defined in contracts)

Project scope may change (not stories already committed)

Question 9

Termination

Answer 9

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.

Question 10

Acceptance

Answer 10

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.

Question 11

Deliverables

Answer 11

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.

Question 12

Limitation of liability

Answer 12

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.

Question 13

Timing of payment

Answer 13

Usually after each iteration acceptance 100% of the iteration price is payed.

Deferred payment may be applied.

Question 14

Pricing scheme

Answer 14

Pay per use: by number of connection/active users/registered users.

Question 15

Fixed-price, fixed scope

Answer 15

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.

Question 16

Agile misconception

Answer 16

Question 17

Time and materials

Answer 17

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

Question 18

Variable-price variable-scope

Answer 18

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.

Question 19

Flexibility levels

Answer 19

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.

Question 20

Fixed price per iteration

Answer 20

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!

Question 21

Fixed price per unit of work

Answer 21

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

Question 22

Risk shifting and sharing

Answer 22

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

Question 23

Hybrid Target cost

Answer 23

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.

Question 24

Multiphase variable model

Answer 24

• Projects have a changing risk profile over time
  
  • Hopefully risk is getting smaller over time
• Mulitphase adjusts contract type to accomodate risk change

Question 25

Risk bounding

Answer 25

• 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.