Wednesday, January 19, 2011

Inspections

I have a client that has a practice of doing inspections, such as requirements inspections at the end of the analysis phase. Most of their projects follow a waterfall methodology. They implemented the practice because they were finding to many defects in testing and production, and they wanted to be able to identify defects earlier in order to reduce the cost to fix them. For their waterfall environment, that seemed like a logical approach to them.

However, we started talking about if/how inspections would work with agile, and particularly Kanban. We had just wrapped up project using Kanban techniques, and there were no defects found in testing. So if we did inspections, how would we do them?

On our project, our cycle time was 2-3 days per feature. We would then review/gain acceptance of that feature with the business owner. While this might seem like an inspection, it wasn't the same as what our client was doing. Their inspections didn't involve the business owners. A typical requirements inspection would involve the business analyst, someone from the quality engineering team, and someone from testing. So this would be an additional step every 2-3 days in our approach. As a lean advocate, my question is "what value does this add?"

The real answer goes back to Deming, and the 3rd of his 14 points (slightly paraphrased) - don't rely on inspections to ensure quality, build quality into the product from the start. If your quality assurance approach consists just of testing at the end of development, you aren't meeting Deming's point. However, if you have other QA activities such as paired programming, TDD, code reviews, frequent feedback from the business owner etc, you don't have to rely on testing to find all your defects, you've already worked them out, or at least most of them.

That's not to say we don't do any testing. It's still part of our overall QA approach. We also conduct our retrospectives to see how we can fold even better QA activities into our next project. I think with a couple more successful projects, I'll be able to get the client to see my perspective on this.

6 comments:

  1. Bob, thanks for reminding us about inspecting for quality per Deming. Good luck in moving the "inspection" mindset.

    ReplyDelete
  2. Thanks Don. The other Deming point I see so many companies violate is the whole annual performance review.

    ReplyDelete
  3. Bob

    Would it be fair to say that there are now many more inspection points, but they are more tightly integrated into the flow of delivery?

    My experience was that the initial total inspection effort went up, but it eventually plateaued and the declined to become almost invisible. We went something like 20 releases with no defects escaping a sprint (e.g. into UAT/prod.)

    ReplyDelete
  4. Craig - one difference in my situation is that I involve the real end-users in reviews, but my client believes in having folks from the QA department do the inspections. I question what value they would bring, where it seems obvious what the end user can bring to a review.

    ReplyDelete
  5. Ah yes... Because we've aways done it that way!

    ReplyDelete
  6. This comment has been removed by a blog administrator.

    ReplyDelete