As I was researching material needed to write, Distributed agile: Fostering development collaboration without collocation, I had the privilege of interviewing two of the authors of the IBM Press book, “A Practical Guide to Distributed Scrum.” I was able to catch up with Elizabeth Woodward at Agile 2010 and pick her brain about her experiences working in distributed agile environments.
More recently, I had the pleasure of doing a podcast interview with Steffan Surdek. In the interview with Surdek, we spoke about three practices which were described in the book to be particularly valuable to fostering collaboration during a Sprint: continuous integration, test automation and test-driven development (TDD). Surdek describes each of these and their importance in software development.
I realized, as Surdek described these practices, that although they are often associated with agile development, they could just as easily be used in traditional software development and certainly they could be used regardless of your team distribution. I managed teams who used JUnit and other programming techniques to automate unit tests and integration tests many years ago. Though our overarching methodology was more traditional with phases and gate reviews, we still used practices to ensure quality was being considered and tested for from the beginning.
Quality gurus continue to argue the pros and cons of various methodologies, but one thing seems to be clear: the earlier we can find defects and get them fixed, the better. Regardless of the methodology you use, practices such as continuous integration, automation and TDD will help you test for quality throughout the lifecycle.