Quality Assurance

Orange11 believes that high quality standards result in high productivity. The extra effort needed to meet these standards pays off only a few sprints into the project, as high quality allows new features to be developed at a constant pace even as the system becomes more complex.

Our quality standards are secured by ensuring that the code for each new feature meets these requirements:

1. The code is checked into a source version control system.
2. An automated build process is run each time new code is checked in (Continuous Integration). This ensures that the system can be rebuilt from source without compilation errors.
3. There are unit tests for all logic in the code, and all tests are run as part of the automated build. This verifies that all tests run successfully after each change to the code. We apply Test Driven Development (TDD) practices; unit tests are an integral part of our development work. Unit tests are often created prior to the code that implements the logic under test.
4. There is extensive code level documentation in the source files. More specifically, all classes are documented (class level) as well as all exposed methods, using JavaDoc, according to the Sun Java coding standards.
5. Code is re-factored where needed. Re-factoring means modifying the code to improve its structure, without changing its functionality. It is considered indispensable as a practice to keep the codebase clean and maintainable as it evolves and becomes more complex. Furthermore code can only be reliably re-factored when there are enough unit tests, since these will detect when a refactoring might break existing functionality.
6. Code is reviewed by a senior member of the development team to verify that it meets all the criteria above and fits the architecture of the system.

Scope management
An essential characteristic of an agile approach, the scope of the project is not fixed upfront. Instead we acknowledge that our insight into the value and priority of features will evolve over time as we see the system take shape. This way we avoid spending unnecessary time on features that seemed important at the start of the project, and instead focus our efforts on the features that actually have a higher priority.

For individual sprints however, the scope is fixed at the start. After the planning and estimation meetings, the scope is defined as a list of features that require implementation. The team can select a subset of the features that  they will commit to complete during the sprint. The remaining features will be optional features, i.e. those that could still be completed in the sprint as well, or otherwise those that will be carried over into the next sprint.

In our experience we have seen that development teams need two or three sprints to settle in and become familiar with the project specifics. In the course of the project, perceived productivity goes up and estimates become more reliable.

Project management approach

Key elements of our agile project management approach:

1. Orange11 provides a development team with a Scrum Master.
2. Customer provides a Product Owner.
3. At the start of each sprint the Team and Product Owner meet to determine the scope and planning for each new sprint.
4. At the end of the sprint the Team presents the results to the Product Owner, and, optionally, other stakeholders.
5. The result of the sprint will be deployed as a working system to a user acceptance testing environment and to other stakeholders.
6. Feedback by stakeholders is fed into the next sprint as new features and priorities.