When XDx's Software Group adopted an agile approach to application development, we achieved the fastest development time on any software project in the company's history. While we expected to shorten development time and reduce costs, we discovered that agile provides several hidden benefits. Beyond its value as a software development methodology, our agile platform is a tool that enables and improves communication with our users which has been a key success factor, because user groups have a hard time thinking in the software development terms imposed by the traditional waterfall method of upfront specification. This improved communication has helped everyone to let go of complete up-front specifications and trust the agile process.
First Agile Project: A Call to ARMS
At XDx the road is short between business needs and IT concerns: projects are small, user groups are small, and because of this our company is an ideal environment for agile software development methodology. Our software team has direct access to users and we receive feedback on a daily basis, often working with requirements that are incomplete or susceptible to change.
Our team received requests for a business application to track and analyze the diagnostic tests required in clinical studies. This was the perfect occasion to try out an iterative approach, and we conceived a phased rollout of the new application that we could implement rapidly. The project-an application called Analysis Request Management System (ARMS)–automates the tracking of clinical trial samples and pathology requests for diverse studies. For the end result we wanted ARMS to support all the studies for which we have clinical data to manage or for which we need to manage sample workflow.
For the initial phase we devised a pilot project to allow the software team to learn a new software development platform well enough to deliver follow–on applications and, at the same time, evaluate the development platform (OutSystems' Agile Platform) for use in future projects.
The agile methodology we used is a customized composition of various existing techniques and tools based on the Scrum process. The elements we used stringently were short development sprints of pre-determined length that need to deliver functional software, frequent verbal communication with end users, and small, cross-functional teams with little if any hierarchies. Continuous integration is inherent in the Agile Platform used. In a more flexible way we also sometimes used pair programming and design patterns. We did not use techniques like test driven development, unit tests, or mandatory daily meetings.
Our most important considerations for the project were integration with existing applications by using services, re-use of software components, speed and agility of development, and ease of maintenance. We knew that once the pilot application was in production we would be able to fine-tune it and add other studies to the mix.
From Pilot to Production
The final pilot application was delivered in just six weeks, including a one-week fine-tuning phase where we let the application rest and made minor adjustments as needed. Once we had prepared the original pilot application, it was simple to add a second clinical study involving the same type of samples (small glass slides) and generate value immediately.
Since we had added another user group, composed of different people, this was an opportunity to optimize for both studies with feedback from a larger number of users who responded with requests for modifications (such as data uploads, display optimizations, more efficient search functionality, etc.).
After implementing these changes we focused on a third study that involved different types of samples and analysis requests. These samples have properties requiring adjustments so the application needed to be more flexible: for example, property names for the different objects had to be able to change easily between studies. Throughout the entire process, the basic workflow in ARMS stayed the same.
Since we had gained experience with the tool and designed the application to be easily changeable, the development time was quite short. For the second study, we used three sprints of one week each, with one developer. For the third study, we had two sprints of two weeks, with a part-time developer. Team size and sprint length were determined based on expected complexity and size of application features in a project and on resource availability.
Agile Improves Communication: Test-driven Development amp; QA