Introduction to Agile and Testing Best Practices for Distributed Software Teams with Hardware Dependencies

Abstract

There is no shortage of literature on how to use Agile and Scrum to speed up software development and deploy working code more frequently, however many of the concepts presented these days are geared toward pure software solutions, that are often web-based, where testing can be fully automated. This paper will address using Scrum and Agile software development practices in solutions that have hardware and/or regulatory dependencies, and a distributed development team. The hardware and regulatory dependencies, and distributed development team, can complicate the use of these development practices and limit the frequency of deploying working code due to the time consuming testing that is often involved • sometimes delaying a release for months. This is very different than with some pure software solutions, developed locally, that strive to be able to deploy working software “continuously” through the use of automated testing. This paper will attempt to reconcile the issues around using Agile and Scrum for developing HW and regulatory dependent software solutions that are not fully addressed in many agile / scrum literature and presentations. We’ll start by revisiting the core principles around agile / scrum development, and testing best practices. Then, we’ll look at examples from our own development processes at National Instruments, where we’ve adopted an agile process for the development of our software application that is used to automate the calibration of NI’s many hardware products, for both our internal service laboratory and 3rd party metrology laboratories. This application presents a number of challenges that should resonate for any software group that has a large number of hardware dependencies or regulatory requirements on their applications. For example, the broad portfolio of NI products and instrument standards that this application supports, makes regression testing for large changes an extremely time consuming task. Finally, we will address some of the challenges with using scrum with a global team, as we have developers split between Austin, TX and Hungary.