activities are in continuous lockstep with the development team, as shown in Figure 3. The quality management team is not focused solely on testing the last iteration of work completed, but instead it performs investigative testing on the current iteration reducing the overall feedback cycle. Development teams participate in confirmatory testing of changes with their peers and collaborate with one another to formulate ideas for solutions to identified problems. In this approach, the quality management team has a reduced need to produce elaborate test plans because there is a smaller backlog of changes in each release. This continuous approach enables the quality management team to realize its full potential to accelerate the software delivery lifecycle, helping the organization realize a "follow-the-sun" approach with temporal distribution. Successful application of this approach requires a high degree of maturity in collaboration and understanding between GDD teams.
Once again, the quality management team identifies change stories and reports them back to the developers, often using a defect management tool such as FogBUGZ or ClearQuest. Interestingly, many agile GDD teams use these sorts of tools for all their requirements needs, a perfect example being the Eclipse development team which uses Bugzilla for this. Next generation IDEs such as Jazz have these sorts of requirement/defect management features self-contained, enabling close collaboration even in GDD situations. Continuous integration is leveraged in this approach and further integrated with automated deployment tools to manage change and service overhead between the GDD teams. This approach is made further resilient when security roles, workflow handoffs, server provisioning, and self service are managed and implemented by the change and release system.
Agile is Relative
There is no single solution for quality management in a GDD situation and your organization will need to choose the approach that works best for you. This is why we described three different strategies in this article. Although the continuous approach is "more agile" than the incremental approach, which in turn is more agile than the first strategy, the fact is that the first strategy may prove to be a sufficiently radical improvement over what you're doing today. Many people would like to have a single answer; the fact is that agile is relative and a quality management strategy which works well in one situation may not work well in others.
Global agile quality management is truly enabled when remote quality teams understand the complete story of changes and can provide feedback to the developers on a continuous basis throughout the project. This reduces the risk of miscommunication, incomplete communication, or often no communication of changes to distributed quality teams. However, this doesn't imply that you need a complex change control process, a change control board following an onerous process, or detailed documentation describing every potential change. The agile approach is to institute "just enough" change and test management in order to get the job done. A fully integrated agile quality management team has a continuous and collaborative feedback loop with the business analysts and customers, as well as the development team. An effective global change management solution should drive this and also provision and manage quality efforts so they don't overwhelm or derail project goals.
Lately, the Agile community has started applying its techniques at scale and geographic distribution is one of several critical scaling factors which are being explored (team size, regulatory compliance, governance, and complexity are other factors). We've still got a lot to learn about GDD, but luckily there are some very good resources out there that can be leveraged along the way. IBM has