Flashback: Quality Week 2001

In 2001, I saw Kent Beck speak to a standing-room-only crowd at Quality Week, a conference for quality and testing professionals. Kent spent the first portion of his talk explaining how QA is a throwback to Tayloristic, Time-and-Motion, Scientific Management practices, and that XP teams just don’t need any of that. He went on to explain the XP practices, and how they are both disciplined and self-supporting.

Then he tried to step off the stage. What Kent didn’t realize is that he had a double time slot. The crowd wasn’t about to let him go after he’d just offended all they knew to be good and holy. He spent the next 45 minutes answering questions posed by extremely angry QA professionals.

The good news is that Kent survived the experience. Despite a few tense moments, the audience did not charge the podium after all. I must say that I was impressed with Kent’s courage and grace under fire.

The insights I gleaned from that talk may not have been exactly what Kent intended. It seemed to me that:

1. XP teams still needed Test QA people.
2. XP teams might not need Process QA people.
3. Kent didn’t understand (or at least didn’t articulate) the difference between Test QA and Process QA; he seemed to paint all “QA” people with the same brush.
4. I should learn more about this XP stuff.

Fast Forward to the Present Day

In the 5 years since Kent’s talk, I’ve immersed myself in Agile, joined the Agile community, and have worked on XP teams. I can now say that the first two insights I gleaned from Kent’s talk were right on target, although I would phrase them differently today.

• Lesson 1: XP teams do need testers. The role of a tester on an XP team is quite different than the role of a tester on a traditional phased project, but XP teams need people with a deep understanding of how to test software.
• Lesson 2: XP teams do not need specific individuals assigned to the role of Process QA. As Ilja Preuss points out in a comment on the Agile Forums, the activity of QA is so important on an Agile team, all team members constantly work on it.

Process QA, Process Police

Let’s consider the typical activities that Process QA is responsible for:

• Establishing quality gates and project checkpoints
• Identifying key artifacts to be reviewed/inspected
• Establishing a change control process
• Defining quality-related project metrics for statistical process control
• Analyzing and mitigating risks
• Monitoring the project to guard against deviations from the process or plan
• Reporting to the executive stakeholders on deviations from the process or plan
• Continually improving the process, often by incorporating industry best practices

Now let’s consider some of the key words here: checkpoint, inspection, control, monitor, guard, report. Consider what these words suggest. Indeed, much of Process QA work involves policing. Process QA is supposed to protect project stakeholders from the harmful effects of process deviation.

But XP Customers don’t need to be protected from XP Programmers. In XP, the Customer and the Programmers work together to produce software that meets the needs of the business.

“That’s all fine and well,” a Process QA specialist might argue, “but nobody’s perfect. An independent QA group is objective. That objectivity enables them to see when people are making mistakes, and also enables them to help the team continually improve their process.”

Ah. But do XP teams need that objective viewpoint?

XP teams are not perfect. Quite the contrary: XP teams still have bugs, bad days, periods when it seems no progress is being made, requirements churn, scope creep, and process problems. Anyone who thinks adopting XP makes all problems disappear has confused Extreme Programming with Fantasy Island.

But visibility is built into the process so it doesn’t take a specialist to spot problems. The team as a whole can see that the tests are “red,” that stories are stuck in “waiting for approval” on the story board, that the Velocity is 0, or that the team is fudging on a core XP practice. And the team is empowered to take remedial actions.

Agile Teams Monitor and Police Themselves

Consider the team who’s standup meetings were becoming so drawn out that team members began sitting on the floor. Since stand ups are supposed to be short meetings, the fact that multiple team members gave up on standing was a concern. The team as a whole asked themselves why that was happening, and they realized that the quick morning check in devolved into an extended discussion about design more often than not. Further reflection revealed that the standup meetings were the only venue the team had for such discussions.

The team decided to hold design discussion meetings on a regular basis in a conference room with a lot of white boards where they could really hash things out. This isn’t one of the XP practices. In fact, some XP teams would balk at having such a meeting. Others would have the discussion, but hold it in the bullpen rather than moving it to a conference room. But for this team, given their context, having meetings in a conference room was just what they needed. The process breakdown (sitting down at a standup meeting) provided the feedback the team needed to see that something was missing in their process.

This team happened to be an XP team, but visibility and team empowerment are common to all Agile teams. And such capacity to reflect and adjust is why Agile teams don’t need an external Process QA specialist to monitor their process conformance. An Agile team can identify, diagnose, and fix process problems much more quickly and effectively than an external Process QA group could.

But What About…

Sometimes Agile teams experience bigger process breakdowns, and sometimes those breakdown result in chaos. And occasionally the situation will devolve to the point where some stakeholders feel angry and resentful, and blame others for not holding up their end of things. “They should be held accountable!” say the angry stakeholders. Who “they” are and what they should be held accountable for varies. Some typical situations:

• “The Customers should be held accountable for creating the Acceptance Tests!” say the Programmers when they notice that there is no agreement on what “done” means.
• “The Customers aren’t Accepting stories! They’re not keeping up!” complain the Programmers when stories are languishing, waiting for approval.
• “The Programmers must not be testing enough, because we find bugs all the time!” laments the Customer when they find they can’t accept anything.

What about those cases? Wouldn’t Process QA help? Process QA could make sure the team members all do their bit.

They could, but it probably wouldn’t help. That’s because the real problem is not process compliance. Lack of compliance is a symptom of a larger problem, a problem with the process itself.

Rather than bringing in the process police to enforce the process, the team needs to reflect and adjust.

Perhaps an outsider could help the team do that. If so, it’s in the same way that couples having problems might seek a marriage counselor. The team needs a facilitator, a mediator, or a coach. The team does not need an enforcer. The team also does not need most of the other services that Process QA provides. Statistical process control and quality gates can only tell us what we already know: we have a problem. The team is in the best position to identify possible solutions.

And all of this—the nature of Process QA, visibility in Agile processes, and the power of self-managed teams—explains why I maintain that:

An Agile team that needs a process cop is an Agile team that needs to adjust their process. Somehow their process is no longer working for them; instead they are working for the process.