Agile Strategies for Geographically Distributed Quality Management

Geographically Distributed Development (GDD) is a common strategy in the software world today. Organizations are gaining experience in developing software globally and are discovering that the competitive demand for best-in-class, high quality applications requires greater agility in quality management. Unfortunately, IT budgets are not keeping up with the staff required for quality management and the response is to accelerate quality management by leveraging global teams. This article compares and contrasts agile GDD testing strategies for affecting quality management.

Geographically Distributed Development (GDD) is a common strategy in the software world today. Organizations are gaining experience in developing software globally and are discovering that the competitive demand for best-in-class, high quality applications requires greater agility in quality management. Unfortunately, IT budgets are not keeping up with the staff required for quality management and the response is to accelerate quality management by leveraging global teams. This article compares and contrasts agile GDD testing strategies for affecting quality management.

IBM has one-third of a million employees worldwide and we've succeeded at GDD for more than 15 years. Most importantly, we've had the opportunity to try out a range of development strategies in practice, strategies which many organizations are just considering today. Our strategies in agile quality management elaborated in this article will focus on the intimate link of requirements and change management. We will explore three strategies for geographically distributed quality management, the associated challenges with doing so, and how to address these challenges.

Quality Management

Quality management is the process of ensuring that the defined business requirements have been successfully translated into a working product. In traditional environments, quality teams often find that a significant amount of their work is not aligned with business requirements, but instead in testing unintended changes to the end product as a result of breakdowns in communication and human error. In this state, the role of the quality engineer is reduced to a "last line of defense tester." Quality teams operating in this lower state of existence are failing to realize the significant value they can bring to their software delivery organization.

{sidebar id=1}Quality engineers require intimacy with the business domain, requirements, and stakeholder motives just like developers. Traditionally, when business analysts write requirements, they may leave out minute, important details assuming they are "common knowledge" in the business domain. Relying only on a requirements specification proves to be risky in practice. One agile approach is to capture requirements as "customer tests," what traditionalists would refer to as function tests, whenever possible. By doing so you arguably eliminate the gaps that are introduced by statically capturing requirements and then recapturing the information as tests - in short, you cut out the documentation "middle man." However, not all requirements can be captured as tests and confirmatory testing (validation against requirements) is just part of the overall quality picture. More to come on this issue below.

The Challenges with GDD

Common approaches to agile software development have everyone involved in delivery collaborating together in one location. This is definitely preferable, but in practice this isn't always an option. A common strategy is for organizations to have independent quality teams which validate the work of development teams, even when the development teams are doing Test-Driven Development (TDD), and those independent testers aren't always co-located with the developers. When quality teams are geographically distributed from the developers, who in turn might even be separated from the stakeholders, it becomes very difficult for them to stay in synch with changes to requirements and application code. This results in a lot of cross-talk when the remote quality team isn't working with the most recent version of the system.

The result is risk to the integrity and quality of the end product. In order to reduce the risks of remote quality management and offshore testing, you must ensure that everyone has a common focus and stays in synch. Both development and quality management are driven ultimately by new and changing requirements and as a result it's critically important that these teams have visibility and are a collaborative part of the change management