SMR are practitioners of agile software development, a development approach that brings developers closer to the customer and uses short iterations with regular customer feedback to ensure the customer is getting the software they want. Our approach has a greater focus on meeting business needs and creating business value than more traditional methods or ad-hoc development. We demonstrate our software regularly to the customer to get feedback and show progress. Our process is usually split into two parts:-

• Development of a specification for the system.
• Development of the system based on the specification.

The first part produces a specification with enough detail to allow us to get a better idea of what the customers want and is written in terms that are understandable to the developer and the customer. The specification would typically consist of:-

• User stories describing what the system should do from the customer’s perspective. (User stories are known as use cases in other methods.)
• Performance, scalability, usability and other non-functional requirements.
• Description of the data that needs to be captured / stored / calculated.
• Screen definitions with a description of each screen.
• Report definitions with a description of each report.
• A budgetary estimate for the proposed project.
• A cost benefit analysis of the proposed project.

The second part of the process produces the software required by the specification at a fixed price. During the development the customer and developers interact to fill in any details not specified by the user story. The developers deliver working software to the customer at a steady incremental pace, normally every two weeks. This allows the customer to measure progress and allows them to begin acceptance testing earlier in the life cycle. This iterative approach greatly reduces the risk in the project. The delivered software would typically include code for the application, automated tests, installation scripts, database designs, help, documentation etc.

The separation of the process into two parts enables SMR to estimate the development more accurately and is not a “normal” agile process. Most “normal” agile developments take place in Corporate development teams or on time and material contracts where a fixed price is not essential and specification and development can be carried out concurrently to some degrees, but most customers want a fixed price.

SMR’s approach is a compromise that has risks. The two major risks are: underestimating and specification errors. SMR carries the underestimation risk which we mitigate through experience and the specification error is handled through a change management process where SMR simply requotes on an existing requirement or quotes for new requirements.