6 ways to tighten Agile feedback loops

The later testers find software defects, the more expensive they are to correct. This economic reality holds especially true for Agile teams. In fact, the quality of an IT organization's Agile feedback loops determines how much the enterprise gets out of the methodology. So, you want to find bugs as soon as possible.

Software feedback loops help people find, report and fix bugs. Feedback can occur between testers and programmers, and from end users to the software team. The more software makers tighten feedback loops, the better they can address defects and boost productivity.

It's hard to resolve defects found late in software projects in a quick and simple fashion. QA estimates the scope, tracks the bug and, eventually, assigns it to a programmer. However, that programmer must first finish other work before he starts to fix the bug, and he might not even be familiar with that aspect of the application's code base, causing further delay.

Compare that workflow to one where a QA tester makes a programmer aware of a defect the same day it was added to the source code. The programmer can fix the bug quickly with the context for it still fresh in his mind. That's why fast Agile feedback loops make a difference.

Here's are six ways that Agile teams can tighten their feedback loops.

1. Put testers and programmers in the same room

Reduce the distance between testers and programmers. Testers can't easily notify programmers about defects when the organization siloes each group from the other, and it's harder for programmers to fix bugs the longer ago they created the defects.

Place testers on an assembly line of sorts, where they take the work from the programmer and immediately inspect it. If the tester has a question, she can turn to the programmer and ask him directly. The goal is to detect the bug before the programmer moves on to the next feature.

One of Agile's most transformative changes to how software gets built was to take testers from a separate group with a separate manager and embed them into specific development teams. Simultaneously, testing also shifted to focus on one feature at a time, instead of end-of-line system testing.

Some teams even embed testers the programming process, meaning they flip between code and test frequently, and even contribute to code.

2. Reduce work in progress -- and reduce it again

Measure average work in progress (WIP) and cut it by 10% to 25% -- then, cut it one more time. The software feedback loop will get shorter, and you can fix the application more quickly.

Envision an overworked team: Programmers work on 10 things at a time, support multiple projects, hit roadblocks when they can't get answers to their questions and hit more snags when a pull request gets blocked. Nothing in that WIP-heavy way of working is conducive to fast software releases.

Now, picture a team where programmers work on one thing at a time. When the tester evaluates a programmer's work, the dev waits until they finish looking for defects. This second team has little to no task-switching costs or delays; in my experience, each individual task can get done as much as 30 times faster than in the hands of the overloaded team.

3. Shorten testing preparation time

If you spend a long time preparing tests, you could delay the development process -- which makes the test feedback loop longer.

Some groups spend a lot of time preparing tests. They create test strategy documents, master test plans, test cases and other documentation. Finally, when the test documents pass review, actual testing begins.

A capable tester should look at the work that's done and create a test plan concurrent with the actual testing. Some argue that many testers are simply not capable of this approach -- that a QA lead must tell them what to do. But, if testers have the aptitude to multitask, train them; if they don't, maybe they don't have the aptitude to do effective testing.

4. Set up test environments quickly

A lengthy test environment setup slows down testing and delays feedback, so identity and address bottlenecks in that process.

If it takes hours to set up a test environment, testers will likely do that work once per sprint, which further separates development from testing. If setup takes days, your Agile team might inadvertently be stuck in what is effectively a Waterfall model.

Figure out what takes so long in the setup. Once you identify the bottleneck, reduce the delay. For example, if data creation is an issue, build a batch program to load data into a database. If server availability is a problem, move to an automated, push-button process to create a standard server for any given build or branch.

5. Improve first-time quality

Reduce the number of defects you introduce in the first iteration of software. The more bugs you create, the more trips through the software feedback loop happen. Many software defects happen because of a lack of attention to detail or misinterpretation of vague directions. When such bugs become too common, programmers can't advance to create new features.

To fix this bottleneck, reduce the defect injection rate: the total number of known defects per iteration. Analyze the root cause of these missteps, and remove them to improve first-time quality. This shift in approach often draws testers into the creation of software requirements.

6. Balance automated and manual testing

Naive attempts to add automated tests on top of a legacy system will probably add cost, time and not much benefit; so manual testing should persist.

Obviously, test automation can accelerate the completion of a test feedback loop, but teams easily overemphasize it. Human testers examine the software in a way that automated tests can't.

Unit tests and test-driven development, along with a modest amount of automation, can improve first-time quality. For example, a light build verification test can help; just don't overdo it.