Agile Collaboration and the Search for Truth

Television physician Gregory House lives in chronic pain, a result of a diagnostic error. In most episodes House is cranky, sarcastic, abusive, and lives by the rule "everybody lies". He trusts no one's judgement but his own, and treats each case as his own personal search for truth.

Occasionally the show's writers permit House to be pain-free. In the episode "The Softer Side", House is oddly congenial, open, and trusting. He accedes to a family’s request for an MRI before he’s utilized simpler diagnostic methods. The MRI starts the diagnostic team down a path that is ultimately a red herring, obscuring the true, simple diagnosis. By the end of the show, House is convinced that his collaboration with the parents of his patient caused the diagnostic error. He tosses his pain meds, convinced that too much "nice" prevents the questioning necessary to prevent errors.

The efficiency of Agile is appealing. And yes, it's more efficient for the tester and developer work closely together to identify and fix defects in rapid-fire succession. There's a sort of Zen experience where the team becomes as one. In search of that Zen moment, a colleague recently asked me, "Then why do we need to track defects? Can't QA just tell Development about problems, then trust Development to fix them? We want to collaborate more closely—where is the trust?"

Granted, more/better bugs may be found when the two sets of eyes from the two different disciplines compare their observations about the code. Beyond that, though, asking QA to be trusting can get in the way—especially if it means taking testing "shortcuts" like the following:

• QA can start testing before the user requirements for a story get defined. After all, we're Agile.
• No need for design. QA can just test whatever's coded—because whatever's coded will be the correct design.
• There's no need to check for breakage in last iteration’s code. This iteration’s coding didn't touch anything which would break, and checking for breakage will just take more time when we could be coding instead.
• Code can be produced until the last day of the Iteration. QA can finish execution in the next iteration, and any defects they find can be fixed later.
• We're trying to get away from "formal" testing, so there's no need to document most defects—we'll just fix them.

An Agile team might make some of the above work for a while. Yes, Agile is partially about efficiency. Agile is also about stable, functional code with each iteration. Agile methods are geared toward quick identification and elimination of defects with the goal of lowering risk in the user experience. And yes, finding those defects can require a healthy dose of skepticism. When the tester believes too much in the quality of the initial code and the team has too much emphasis on producing code quickly, even a seasoned tester may be tempted to not dig too deeply, or to not follow up on something in the rush to keep the momentum. The true Zen moment in Agile is when the unified team produces code quickly and it works well.

Getting there is not without tension—and, in fact, requires it. It requires that users have articulated needs (requirements, stories) for the team to satisfy. It requires that team members advocate for the priorities that their roles dictate. Testers advocate for the customer by raising issues in light of requirements or story definitions. Software engineers strive to add value by producing more features quickly. Both are necessary to a satisfactory customer experience. House's approach would be to conduct a "differential" to arrive at an appropriate diagnosis of the problem, with all views being heard in a quest for a true solution. Consider Fred (Developer), Ginger (QA), and Gene (BA):

Fred: "Ginger, I don't think this defect your reported is really a true problem. The real problem is that the original plan would require twice the effort, for development and QA. This solution takes half of the effort, and touches less code."

 Gene: "Fred, I appreciate your approach means touching less code—and less risk of breakage—but approaching the code this way only satisfies 75% of the requirement. The story was framed this way to solve a particular customer issue. The problem is that the requirement is not being met."

Ginger: "We've tested the story as planned. If the story is good, than this is a defect. We need to take the time to look into it and resolve it.

I've seen a great deal of excitement on new Agile projects about how quickly the team will be able to produce code. I don't often see excitement about reducing rework (saving time, reducing expense) with Agile. There's an appropriate tension between doing something quickly and doing something well, and it applies to Agile. Achieving “well” requires that someone on the team play the role of skeptic. A poster I once saw showed hippos jumping into a rowboat, with the motto, "More is not always better". When collaboration is taken to mean the cessation of skepticism, the product team will produce more software—but not necessarily better software.

House cures patients when he's pain-free, asking fewer questions. He cures more patients when he trusts a little less and asks more questions—and we know that it's all about creating healthy patients.