Agile Contracts                       Andris Bariss                  Vladimir Tarasow
supplier   customer
negotiations
contract
risks
Risk is the potential that a chosen action or activity, including the choice of inaction, will lead to a loss.            ...
Risks should be: ● identified — severity and impact ● classified — people, process or   technology ● analyzed — prioritiza...
risks are uncertain
When we estimate  a project we base it  on our idea of scope.       But actually,    its the customerwho is in control of ...
requirementsare uncertain
agile contracts
Capped Time & MaterialTraits:  ● Fixed time  ● Fixed budget  ● Scope can be altered  ● Requirements are stable
Capped Time & Material
Capped Time & MaterialPros:  ● Supplier gets full coverage of its      expenses.  ● Customer benefits from the limit to th...
Capped Time & MaterialCons:  ● Requirements should remain stable.  ● Both parties must work closely together     to identi...
Incremental DeliveryTraits:  ● Regular inspection points.  ● Can be stopped after some point.  ● Requirements can be chang...
Incremental Delivery
Incremental DeliveryPros:  ● Natural for the Agile Teams.  ● Supplier gets full coverage of its      expenses.  ● Customer...
Incremental DeliveryCons:  ● Customer should be familiar with     incremental development.  ● Requires a certain level of ...
Cost TargetedTraits:  ● Fixed scope.  ● Better for long-term relationships.  ● Share risk fairly between Customer and     ...
Cost TargetedMore gain,more pain.
Cost TargetedPros:  ● Both sides benefit of savings.  ● Both sides share the penalties.  ● Gives certainty about the maxim...
Cost TargetedCons:  ● Its very hard to agree on a realistic final     price of the product.  ● Both organizations must tru...
time to practice
Every Friday I like to enjoytasty cocktails.
Rules● 5 mins to discuss what you will do● 10 mins to ask me questions● 10 mins to build a proposal
???
Vladimir TarasowAbout: http://about.me/netratE-mail: netrat@netrat.euAndris BarissAbout: lv.linkedin.com/in/andrisbarissE-...
Thank You! Please, leave feedback!http://spkr8.com/t/21031
CreditsMaterials used in the presentation:●   Wikipedia: www.wikipedia.org●   Agile Contracts collection by Alistair Cockb...
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. To view a copy...
Upcoming SlideShare
Loading in …5
×

Agile contracts

806 views
746 views

Published on

Presentation about different approaches both common — Capped T & M or Incremental Delivery — and rare, e.g. Cost Targeted, and share our experience about what's is going on in real life.

2 Comments
1 Like
Statistics
Notes
  • === NOTES FOR THE SLIDES ===
    Negotiations— that's what we're all doing everyday. Most kind of every day activities can be treated as a negotiation.
    Even convincing yourself to wake up in the morning is a kind of negotiation. :)
    ----
    Usually there should be at least 2 sides who're negotiating on smth.
    Sometimes you're a supplier. Sometimes you're a customer.
    In any case you're trying to gain smth useful for you in exchange for smth.
    ----
    It's a process of defining some rules which both sides will follow in order to achieve the agreed target.
    You can verbally agree in common cases,
    but if you're doing business the result of the negotiaions should be a contract.
    ----
    And you have to sign the contract before project begins.
    However, sometimes contracts might look like that. :)
    ----
    And here comes risks.
    That's why people try to analyze the requirements, try to identify risks and mitigate them.
    ----
    By the way, can you give a definition of the risk?
    Here's the classic one.
    However this one is better, isn't it? It pays more attention to the fact of uncertainty instead of probality of losses.
    ----
    And the classical approach is as follows: risks should be identified.
    It takes a lot of time to imagine all possible and impossible causes. You're lucky if you had some experience in the project's domain. In that way, most likely you won't make the same errors again.
    Risks should be classified. For example using this kind of classification: people - customers, end users, stackeholders, team structure, organizational politics, team skills and so on; process - project structure, engineering process, sales process and other process-centric areas; technology - security environment, development tools, PM tools, sales tools, customer adoption policies.
    Then they used to be analyzed so we will know what risk is most dangerous and most probable and finally we should create some plans to rid of most of such risks or make the probability of their occurence as small as possible.
    ----
    But are all risks are bad? We can't be sure, because risks are uncertain.
    And as a suppliers we invest our time and efforts in order to mitigate them. Sure, as a suppliers we cannot do something unprofitable.
    But what's about customer?
    ----
    In most cases the customer himself don't know what he want to achieve, however there might be some kind of the Goal or Vision or Definition of Release.
    Talking about the bricks what the building named project is made of, nor you, nor customer don't know their form or their quantity for sure.
    ----
    The only way to validate the new stuff is to sell it. If somebody needs it, so it's fine. To prove it you should develop a small part of the scope, deliver it and grab the feedback to prove weather the feature is needed or not.
    That's why we can say that requirements are uncertain, too. So what should we do in that case?
    The answer is quite simple: we should focus on the requirements which are clear at the moment and work with risks which are clear at the moment.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • ----
    And here goes agile contracts — tools which can help both a supplier and a customer...
    let's cover some popular types of agile contracts...
    ----
    The other name is 'Not-to-Exceed with Fixed-Fee' (NTE/FF).
    Supplying the most valuable stuff first and in case the time is up, most likely customer forgive the undone scope or roll into a follow-up contract.
    ----
    In that case: Time = Budget. Stories/requirements are estimated as assumpted story points or even as men/hours.
    A Minimal Marketable Feature (MMF) is the smallest piece of functionality that can be delivered that has value to both the organization delivering it and the people using it. The Lean-Startup community sometimes call this a Minimal Viable Product (MVP) to underscore that one should come up with something as quickly as possible. The Agile community sometimes speaks of a Minimal Viable Feature (MVF) meaning what can be built to validate we're moving in the right direction. In any event, the MMF is a concept meaning - build the smallest thing possible to get value as soon as possible. This can be for release, discovery of what to build, or validation of the path you are taking.
    ----
    As you can see it's very similar to the classic T&M contract. That's good, because customer most likely is familiar with this kind of contract. The bad part is that we said that just a part of scope will be done from the very beginning. On the other hand, it will be the most important to customer part of the scope and it will be delivered early.
    ----
    The other difference from the usual T&M is that customer is involved deeply into the development as he or she should participate in prioritization and refinement of the requirements. And that's the thing which won't be so easy to achieve.
    ----
    This type of contract is the best if the supplier's team is familiar with agile, because it's the most native type of contract for them.
    However it's not so easy, because requirements or stories can be changed often. But let's back to the subject.
    ----
    At the inspection point - release - there should be a product which can be deployed into the production environment.
    However it doesn't mean that a collaboration with customer isn't necessary during the iterations inside the release.
    Grooming the backlog together with customer in order to find out what should be done is vital for that kind of contracts.
    ----
    The fact that the customer can stop the project is both the good thing and not so good thing. Good for customer, but, as to me, not so good for supplier, because it's not aimed for the long term cooperation and not motivated for that.
    ----
    To some extent it's because of customer which might be unfamiliar with agile/lean approach of doing things.
    ----
    If the Supplier come in under the target, the savings are shared equally between both parties. Likewise, if we come in over the target, the extra cost is shared evenly – but only up to the cap. If we reach the cap, it acts like a fixed price.
    This type of contract is used by Toyota for suppliers. However it can be used in SW industry too.
    Why it's good 'to minimize scope'? That's because, more simplier it becomes, more certain it will become. So it's much easier to develop or improve the certain things.
    ----
    To some extent it's a good example of the idiom 'eating your own dog food'.
    ----
    The most interesting part is that even the risks are shared the side which gains more might loose more either.
    ----
    The fact that the idea is based on uncertainty which is in the negotiated price of the project is a flaw for the short-term projects.
    ----
    Let's have some practice taking into consideration all the things heard. Let's form the teams of 4-5 people. The task will be the same for every team however the characteristic of the customer may vary.
    ----
    Customer: I'm a customer. Every Friday I like to enjoy tasty cocktails. I won't be here tomorrow, so I want to see your proposal today and the result on Friday. The best one wins.
    ----
    Questions should be asked one by one, team by team. One question at the moment.
    Each team has its own type of the customer. For example:
    - innovator
    - greedy
    - wishy-washy person
    - government
    - group of shareholders
    - propose your own
    The person who will act as a customer should align his or her answer according to the type of the customer.
    ----
    Check:
    Is it really a contract or a promoters gossip?
    The reason why exactly this type of contract was selected by the team?
    Is it the best for the customer? Why?
    Is it the best one for the supplier? Why?
    In which way the customer will be satisfied?
    How it will be profitable for the supplier?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
806
On SlideShare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
18
Comments
2
Likes
1
Embeds 0
No embeds

No notes for slide

Agile contracts

  1. 1. Agile Contracts Andris Bariss Vladimir Tarasow
  2. 2. supplier customer
  3. 3. negotiations
  4. 4. contract
  5. 5. risks
  6. 6. Risk is the potential that a chosen action or activity, including the choice of inaction, will lead to a loss. WikipediaRisk is the effect of uncertainty on objectives. ISO 31000 (2009) / ISO Guide 73:2002
  7. 7. Risks should be: ● identified — severity and impact ● classified — people, process or technology ● analyzed — prioritization ● planned, tracked and etc.
  8. 8. risks are uncertain
  9. 9. When we estimate a project we base it on our idea of scope. But actually, its the customerwho is in control of scope.
  10. 10. requirementsare uncertain
  11. 11. agile contracts
  12. 12. Capped Time & MaterialTraits: ● Fixed time ● Fixed budget ● Scope can be altered ● Requirements are stable
  13. 13. Capped Time & Material
  14. 14. Capped Time & MaterialPros: ● Supplier gets full coverage of its expenses. ● Customer benefits from the limit to the total exposure. ● Both parties interested in delivering high value functionality as early as possible.
  15. 15. Capped Time & MaterialCons: ● Requirements should remain stable. ● Both parties must work closely together to identify needs, wishes and priorities from the very beginning.
  16. 16. Incremental DeliveryTraits: ● Regular inspection points. ● Can be stopped after some point. ● Requirements can be changed wildly. ● Good for building prototypes.
  17. 17. Incremental Delivery
  18. 18. Incremental DeliveryPros: ● Natural for the Agile Teams. ● Supplier gets full coverage of its expenses. ● Customer can stop the project after the inspection point to save the budget.
  19. 19. Incremental DeliveryCons: ● Customer should be familiar with incremental development. ● Requires a certain level of trust between supplier and customer. ● Uncertain future for the supplier.
  20. 20. Cost TargetedTraits: ● Fixed scope. ● Better for long-term relationships. ● Share risk fairly between Customer and Supplier. ● Align goals by giving both parties an incentive to minimise scope.
  21. 21. Cost TargetedMore gain,more pain.
  22. 22. Cost TargetedPros: ● Both sides benefit of savings. ● Both sides share the penalties. ● Gives certainty about the maximum price.
  23. 23. Cost TargetedCons: ● Its very hard to agree on a realistic final price of the product. ● Both organizations must truly understand the model.
  24. 24. time to practice
  25. 25. Every Friday I like to enjoytasty cocktails.
  26. 26. Rules● 5 mins to discuss what you will do● 10 mins to ask me questions● 10 mins to build a proposal
  27. 27. ???
  28. 28. Vladimir TarasowAbout: http://about.me/netratE-mail: netrat@netrat.euAndris BarissAbout: lv.linkedin.com/in/andrisbarissE-mail: andris.bariss@gmail.com
  29. 29. Thank You! Please, leave feedback!http://spkr8.com/t/21031
  30. 30. CreditsMaterials used in the presentation:● Wikipedia: www.wikipedia.org● Agile Contracts collection by Alistair Cockburn: alistair.cockburn. us/Agile+contracts● Minimal Marketable Features - MMFs Explained (www.netobjectives.com)● Target Cost Contracts by John Rusk (www.agilekiwi. com/estimationandpricing/target-cost-contracts)● Photo from Wikimedia by Properpilot● Photo from Wikimedia by Nik Frey● The reproduction Saint Wolfgang and the devil by Michael Pacher via GNU Free Documentation License● Illustrations by Arina Noviani (arinanoviani.deviantart.com)● Illustrations by Vladimir Tarasow
  31. 31. This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/.

×