This document describes the definition of an Open And Agile Development Manifesto and Principles. We have adopted and adapted the original for Agile Software Development and Twelve Principles of Agile Development to accomodate for the fact that an open development community is more diverse and distributed when compared to a typical agile development team.
View a diff of changes between draft 1 and draft 2
Please see discussion of this document in our mailing list.
Manifesto for Open and Agile Software Development
Naturally we started this work with the Manifesto for Agile Software Development. We found that the vast majority of the Agile Manifesto was equally applicable in the open development space. However, one key difference was identified. The Agile Manifesto says "Customer collaboration over contract negotiation", we felt that the focus on "customer" here was difficult in an open development model since there is no single customer in an open project. We also felt that the focus on "contract negotiation" was out of place in an open development project where contracts are external to the open project. We therefore changed this line of the manifesto to Contibutor collaboration over organisational objectives in order to recognise that there are many types of contributor in an open project and that individuals within that project should consider the health of the project community over the individual interests of their organisation.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Contibutor collaboration over organisational objectives
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Principles of Open and Agile Development
These principles are inspired by the Twelve Principles of Agile Development
We follow these principles:
Our highest priority is to enable collaborators to "scratch their own itch" through early and continuous delivery of valuable software code [Collaboration]
Welcome changing requirements, even late in development. Open and agile processes harness change for the collaborators competitive advantage. [Change]
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. [WorkingSoftware]
Build projects around motivated individuals. Give them the environment, support and recognition they need, and trust them to get the job done. [MotivateIndividuals]
Optimal solutions are the product of collabarating minds. All decision making and development processes must facilitate distributed engagement, no contributor is to be unnecessarily excluded from participation. [Access]
Working software is the primary measure of progress. [RealeaseEarlyReleaseOften]
Open and Agile processes promote sustainable development. Open projects transparently capture, document and distribute their history to enable survival beyond the departure of any contributor. [ProjectMemory]
Continuous attention to technical excellence and good design enhances agility. [TechnicalExcellence]
Simplicity--the art of maximizing the amount of work not done--is essential. [Simplicity]
The best architectures, requirements, and designs emerge from self-organizing teams. [SelfOrganisation]
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. [Reflection]
All constructive contributions, no matter how small, are to be encouraged, recognised and rewarded publicly [Recognition]
Justification of Principles
Suggested Principles from Expert Workshop
In July 2009 OSS Watch held an expert workshop where the following principles for open development were suggested. We note which principle covers each of these points below.
Survival of People - dynamic teams [ProjectMemory]
- o Diversity [Access]
o project independence and survivable of team replacements or forks [ProjectMemory] o Sustainability [ProjectMemory]
- o Diversity [Access]
- Public decision making [Access]
Project Memory (public) - availability of outputs [ProjectMemory]
- No barriers to access [Access]
- Low barrier to participation [Recognition]
- clear pathway to committing [Access]
release early release often [ReleaseEarlyReleaseOften]
- OSI/FDF freedoms [Access]
- visible community rewards [Recognition]
- community over output desire[Collaboration]
- o New blood/ideas [Recognition]
o vigour [MotivatedIndividuals] o revitalization [TechnicalExcellence]
- o New blood/ideas [Recognition]
- customer is part of community [Collaboration][Change]
- o cust role == dev role
scratch your own itch [MotivatedIndividuals][Access][Recognition]
- motivated individuals [!Motivatedindividuals]
honesty about outputs [WorkingSoftware][ReleaseEarlyReleaseOften]
o running tested features [WorkingSoftware] o QA management [ReleaseEarlyReleaseOften]
Many of these principles are direct modifications of the original agile principles. The main difference is the change in focus from "customer" to "collaborator". That is we are focussing on the developers of the product. Note that in an open project developers can include customers of collaborators who would submit feature requests and bug reports.
The following agile principles have been removed or modified
- "Business people and developers must work together daily throughout the project" - "the project" is different in the open development world. We have a single project that is a part of individual customer facing projects managed by individual collaborators. The point at which business people and project collaborators work together is within the local project, not in the global collaborative project.
- "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." has been replaced with a principle of inclusion of diverse people, that is: "Optimal solutions are the product of collbarating minds. No contributor is to be excluded from decision making processes."
- The second part of "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely" has been removed and replaced with: "