The agile manifesto

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile Approach

Short iterations. Instead of running off with the specifications and come back six months later with a system that probably does what the customer needed half a year ago, an agile process relies on frequent communication between customer and supplier.

Primary differences from traditional waterfall development

• Development is done in short iterations (typically of two weeks length).
• At the end of every iteration we deliver a working, running, system.
• Every developed piece of functionality is first done as minimal as possible, then improved in small steps. Thus, there should be no hanging, unusable, “80% done” components. - Just small components that can be expanded to the intended functionality

• The customer is invited to plan which features will be worked on in the next iteration after evaluating the previous achievements.

Test-driven

The functionality of the software is demonstrated by a set of automated tests. The tests are delivered with the software and the customer is free to run them at any time. The customer is furthermore invited to provide his own set of tests, if desired. Automated tests, in particular unit tests, are a core practice in any agile methodology. Tests make sure we deliver low-defect components. Even more important, they provide the safety-net essential to the ability to evolve the software in the face of changing requirements, so the software can even be refactored or rewritten at a later date with minimal risk of disrupting the running system.

Transparency of Open Source

Every piece of code is open to scrutiny by peers and customers, and frequently also to the public and the Plone community. We normally have automated mails produced from every check-in done to our version control repository, - to mailing lists that customers and fellow developers are subscribed to.

Open Scope Contracts

Open scope contracts are designed to accompany agile software projects. In essence, they attempt to align the interests of customer and supplier, instead of pitching them against each other.

Think of it this way: If the four variables of project management are time, cost, scope and quality. Traditional IT contracts tend to set values for three of them: time, cost and scope. The fourth variable, quality, is left to flap freely in the breeze.

When reality intrudes and a feature turns out to be harder to implement than envisioned, or when requirements change over time, software quality - being the only "variable" - inevitably starts to suffer. Low-quality software however, is neither in the interest of the customer nor of the supplier.

Also, tying scope to cost leads to a situation where the supplier aims to reduce expenses by interpreting the requirements as narrowly as possible, whereas the customer intends to maximize investment by demanding the most generous exegesis of the requirements documentation. Extensive possibilities for controversy ensue.

Lastly, traditional contracts fail to reflect the realities of iterative development methodologies, where the project is allowed to change focus with every iteration.

Now, let's say we use a contract that specifies time, cost and quality, and let scope absorb the uncertainty inherent in every project? We end up with a contract where:

• Sacrificing software quality on the altar of finishing on time is no longer necessary.
• Changing requirements (scope) no longer threatens the project.

Open Scope Contracts have a contract model that fits the iterative approach of the development process, and makes the customer and supplier work together — and produce results that are on time, on budget and beneficial for both parties.

For more information on Open Scope Contracts from some of the world's most recognized experts on agile development methodologies, Kent Beck and Dave Cleal — download this PDF.