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
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 working with the development platform, and in subsequent applications we've been able to reuse the look and feel, the code and many of the templates we developed at the start. From a user perspective, every application developed on this platform has the same look-and-feel, which makes it effortless for users to start using new applications.
Lessons Learned: Design Matters
The strategy of embracing changing specifications and the ability to implement changes quickly in an agile fashion seems to imply, on first sight, that there is no plan and projects are done in an ad-hoc fashion with a lot of back-and-forth. Nothing could be further from reality; agile development methodology in our projects actually does put much greater demands on design. Anticipating specification changes forces a greater level of abstraction, which leads to a clearer, more generic and robust design. Starting out with little detail or information about features means you need to focus on core business processes and design the application in a way that enables evolution and re-factoring instead of recurring re-implementation. Abstracting even further, strategies such as interface-driven design and service orientation are used in all of our projects and enable a maintainable, modular software infrastructure. This in turn gives us the ability to implement application changes quickly in a non-disruptive way. In the case of ARMS, we had to make sure to implement the workflow in a generic way, thus limiting anticipated changes to the tracked objects and their properties. Along the way we have build necessary infrastructure modules (authentication, authorization, general data services) that have been decoupled from the actual application to allow reuse in future projects.
Developing and maintaining the design becomes the responsibility of each developer, which is ideal since everyone is involved in design and nobody gets stuck with doing ‘just implementation' The selection of a development platform is, however, an important success factor to enable this focus on design. The platform we selected supports change management with rapid deployment features, built-in error checking, on-screen capture of user feedback, and automatic creation of documentation, which has turned out to greatly facilitate our agile projects. It integrates graphical editors for each layer of the application (presentation, business logic and database) and allows for compilation and publishing of the project at a click of a button, including verification of dependencies and consistency. That way changes to application behavior can be implemented extremely quickly, sometimes even in the course of a user presentation meeting.
A number of software development platforms, including some with ‘software as a service', are available that make it easy to generate and change applications quickly. The ability to make changes quickly can, by itself, be the road to disaster if there is no sound concept and design of the application. The easier it is to create functionality and make changes the more time there is for conceptual and design work, and that time needs to be invested.
Agile is a good fit for XDx - it's exactly what we need to communicate with our users and add value quickly and effectively. Everyone loves the fact that each person is now part of the development project - everyone knows what's going on and participates in the team effort. Since planning and decisions are done jointly by users, developers, and SQA there is no longer the need to compile long lists of wanted features up front to make sure everything one could possibly think of is on the list; instead, the most important features are developed first and enable subsequent, refined specification of the next round of features. When the process has been started all participants experience the rapid progress and the ability to co-steer iterative development, and once this agile team experience is established the project can only succeed.
About the Authors
Jochen Scheel, Director of Software Development, and Stefan Meier, Associate Director, work as part of XDx's Information Sciences Department.
About XDx
Founded in 2000, XDx Inc., a molecular diagnostics company from Brisbane, California, is on the fast track to a new era in personalized medicine. XDx focuses on the discovery, development and commercialization of non-invasive gene expression testing in the areas of transplant medicine and autoimmunity. The company has developed a proprietary new method of utilizing gene expression that provides additional options to current patient management by physicians specializing in these disease areas. This work is the basis for AlloMap® Molecular Expression Testing.
One of the first companies to develop and bring to market products and therapies derived from the fundamental Human Genome Project, XDx has devised a new method for non-invasively monitoring the immune system by measuring gene expression in a patient's peripheral blood. This technology has huge potential to decrease healthcare costs and improve the quality of life for patients suffering from a variety of immune-mediated diseases.
