Difference between revisions of "Reciprocal altruism"

From Pearl Language
Jump to navigation Jump to search
(Added News: context.)
(Sources++)
Line 26: Line 26:
*Facilitate a {{p|self-selecting team}}.
*Facilitate a {{p|self-selecting team}}.
*Engage in joyful, exciting, challenging an productive work.
*Engage in joyful, exciting, challenging an productive work.
==Sources==
*[http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts Agile Software Development » 10 Contracts for your next Agile Software Project]
*[http://jeffsutherland.com/agile2008MonetforNothing.pdf Jeff Sutherland » Money For Nothing, Change For Free]
*[http://scrum.jeffsutherland.com/2008/08/agile-2008-money-for-nothing.html Jeff Sutherland » Money For Nothing, Change For Free]
*[http://www.coactivate.org/projects/agile-contracts/money-for-nothing-change-for-free CoActivate » Money For Nothing, Change For Free - Agile Contracts]
*[http://alistair.cockburn.us/Agile+contracts Alistair Cockburn » Agile Contracts]
{{Source
{{Source
|author={{mvs}}
|author={{mvs}}
|coder={{mvs}}
|coder={{mvs}}
}}
}}

Revision as of 11:33, 17 December 2012

…two autonomous parties needing each other.

✣  ✣  ✣

{{{wish full}}}


Therefore:

{{{therefore full}}}

✣  ✣  ✣

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