What proved to be one of the biggest advantages of agile is using the platform as a communication tool. We can very easily build not only mockups, but also user interfaces that have basic functionality and present them to users very early on in the iteration. The aspect of delivering working software early is a key concept of agile methodology and is particularly enabled by our development platform. It also enables communication since users can interact with the software and provide feedback and discover and specify additional needs. Even if the application is barely functional, we can ask users to try it out and see if it fits their workflow, then work from their immediate feedback. By the same token, an agile approach makes it much easier to "sell the concept" to decision makers. When you ask for sign-off on a project or new tool and can already present a few working pages as a ‘preview", the decision process is easier and faster.
Working closely with business users throughout the development and rollout of the ARMS application also made for easy, accurate testing. Instead of measuring differences in software defects, we could track improvements in development cycle times, through "right first time" feature metrics.
As for QA in an agile environment, it took a few iterations to find the best way to integrate our QA team in the process. We decided to include a Software Quality Assurance representative (SQA) as part of the entire project lifecycle, right from the start. Since each development cycle produces a working piece of the software, test cases could be developed alongside the implementation. Since all the test cases were already present and the QA team knew the application well, final testing was simple and communication with the QA team was fairly easy.
Testing the system and incorporating more user feedback took a week. We needed fewer developers to create these applications then originally planned. In quality terms, we've achieved our goal of unification and shorter development cycles.
The feedback we receive comes directly from users in-house, mostly at meetings and demos where we show the new functionality; in a small company like ours informal channels are also very effective. The amount of feedback-and the quality-increased once the users learned that it is effective and gets them what they want, and often quickly. And the more responsive we were, the better the application became and the more easily it was adopted. This has created a positive feedback loop of better-applications-quicker -gt; more-and-better-feedback -gt; better-applications-quicker, etc. Since decisions about additional features or changes, about prioritization, or about the schedule are made jointly in our agile projects by developers, users, and QA, the typical tension between requestors who want more software earlier and engineers who can't do everything at once has been minimized and late stage surprises have been eliminated.
Agile methodology provides opportunities to introduce or include design controls for development in FDA regulated environments. In fact, FDA Design Control Guidance considers "concurrent engineering models [is] more representative of the design process in use in the industry" than the waterfall model. We have established concurrent engineering procedures which enable the utilization of agile development under design control. These efforts provide customers with potential new tools in the development of products in a regulated environment. One key element in our strategy has been the use of elements of Hazard Analysis and Critical Control Points (HACCP) methods, a risk-based approach that helped us to define key features on which testing and documentation can be focused while maintaining agile development sprints.
With the first ARMS project, we gained experience