Wednesday, 29 June 2011

Worth Repeating - XP Bills of Rights

While doing the electronic equivalent of cleaning the attic yesterday, I stumbled across an internal paper I wrote at a client back in late September 2001 describing Extreme Programming.  While waxing nostalgic, I did notice a section that remains important today and is worth repeating - the Customer and Developer Bills of Rights from XP Explained and XP Installed.  The text below is unedited from 2001 - you can substitute Product Owner for Customer and Team Member for Developer.

Since communication is a critical aspect of XP, the people involved must know up front
what they can expect, and what is expected of them. As such, the following are lists of
"rights" that the Customer and Developers are accorded in XP:

Customer Bill of Rights
As the customer, you have the right to:
  • An overall plan, to know what can be accomplished, when, and at what cost;
  • Get the most possible value out of every programming week;
  • See progress in a running system, proven to work by passing repeatable tests that you specify;
  • Change your mind, to substitute functionality, and to change priorities without paying exorbitant costs;
  • Be informed of schedule changes, in time to choose how to reduce scope to restore the original date, even cancel at any time and be left with a useful working system reflecting investment to date.
Developer Bill of Rights
As the Developer, you have the right to:
  • Know what is needed, with clear declarations of priority;
  • Produce quality work at all times;
  • Ask for and receive help from peers, superiors, and customers;
  • Make and update your own estimates;
  • Accept your responsibilities instead of having them assigned to you.

These rights resonated with me in 2001, and I believe we need to revisit them from time to time in order to ensure that the values of Agile are instilled within an organization.

2 comments:

Kerry Buckley said...

>An overall plan, to know what can be accomplished, when, and at what cost

Doesn't that come dangerously close to trying to fix scope, time and cost?

Dave Rooney said...

Context is important here... a Release Plan in XP is very, very different from a traditional project plan. See http://xprogramming.com/book/whatisxp/ about 1/4 of the way down the page, the 3rd paragraph in the Core Practices section.