Difference between revisions of "Reciprocal altruism"

From Pearl Language
Jump to navigation Jump to search
(Sources++)
m (terse/full)
 
Line 3: Line 3:
|theme=Agile, Scrum
|theme=Agile, Scrum
|context=two autonomous parties needing each other.
|context=two autonomous parties needing each other.
|wish in a single line=A light-weight contract and protocol that respects the interests of both parties facilitates a healthy business and fosters mutual trust.
|goal=elegantly work together, reinforcing and complementing each other's strengths, while respecting mutual interests
|therefore in a single line=Collect the core interests of both parties and turn them into mutually agreed principles or ‘rights’.  Ensure they resonate with each party's values.
|wish=A light-weight contract and protocol that respects the interests of both parties facilitates a healthy business and fosters mutual trust.
|wish=A light-weight contract and protocol that respects the interests of both parties facilitates a healthy business and fosters mutual trust.
|therefore=Collect the core interests of both parties and turn them into mutually agreed principles or ‘rights’.  Ensure they resonate with each party's values.
|so=Collect the core interests of both parties and turn them into mutually agreed principles or ‘rights’.  Ensure they resonate with each party's values.
|wish full=A light-weight contract and protocol that respects the interests of both parties facilitates a healthy business and fosters mutual trust.
|therefore full=Collect the core interests of both parties and turn them into mutually agreed principles or ‘rights’.  Ensure they resonate with each party's values.
|new=Consider writing this up in a contract. If you {{p|track done}}, then you can even pay only work that is formally accepted by client. This keeps both parties sharp and focused. The client has to invest the time to test and accept what has been delivered by the vendor. The vendor gets paid as soon as items are accepted, no earlier. The vendor will be focused to deliver items that meet or exceed the {{p|ready to ship}}. The client will be focused to get things {{p|ready to build}}.
|new=Consider writing this up in a contract. If you {{p|track done}}, then you can even pay only work that is formally accepted by client. This keeps both parties sharp and focused. The client has to invest the time to test and accept what has been delivered by the vendor. The vendor gets paid as soon as items are accepted, no earlier. The vendor will be focused to deliver items that meet or exceed the {{p|ready to ship}}. The client will be focused to get things {{p|ready to build}}.
}}
}}

Latest revision as of 09:31, 16 June 2013

…two autonomous parties needing each other.

✣  ✣  ✣

A light-weight contract and protocol that respects the interests of both parties facilitates a healthy business and fosters mutual trust.


Therefore:

Collect the core interests of both parties and turn them into mutually agreed principles or ‘rights’. Ensure they resonate with each party's values.

✣  ✣  ✣

Consider writing this up in a contract. If you track done, then you can even pay only work that is formally accepted by client. This keeps both parties sharp and focused. The client has to invest the time to test and accept what has been delivered by the vendor. The vendor gets paid as soon as items are accepted, no earlier. The vendor will be focused to deliver items that meet or exceed the ready to ship. The client will be focused to get things ready to build.


✣  ✣  ✣

For instance, in scrum, a product owner and the development team or vendor are on either side of the interface. Based on the agile manifesto and principles behind the agile manifesto, both parties may agree on the following ‘rights’ up front.

As product owner, you want to:

  • Plan on a large scale with investments and real options.
  • Change your mind without paying exorbitant costs and set priorities at any time.
  • See progress in the form of a working system at the end of the first iteration, and to see a little more functionality every iteration thereafter.
  • Have updates of the schedule, good or bad, as soon as the information is available.
  • Stop the effort at any time and still own a usable system on par with the investments made up to date.

As a development team, you want to:

  • Always know what needs to be produced with clear requirements, and crystal clear acceptance criteria.
  • Estimate work and have those estimates respected by all stakeholders.
  • Honestly report progress with impunity.
  • Produce high-quality work at all times.
  • Know what is most important to work on next.
  • Ask business-oriented questions whenever they arise, even if they are uncomfortable ones.
  • Facilitate a self-selecting team.
  • Engage in joyful, exciting, challenging an productive work.

Sources