Quintagroup works under agile development practices. In our work we value:
-
Individuals and interactions over processes and tools.
Development is done in short iterations - instead of running off with the specifications and coming 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.
-
Working software over comprehensive documentation.
At the end of every iteration a working running system is delivered. Every developed piece of functionality is first done as minimal as possible, then improved in small steps. Thus, there should be no hanging, unusable, not completely done components. Just small components that can be expanded to the intended functionality.
-
Customer collaboration over contract negotiation.
The customer is invited to plan which features will be worked on in the next iteration after evaluating the previous achievements.
-
Responding to change over following a plan.
Test-driven
During test-driven development 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.