mikkeman.nl

One of Deming’s 14 principles states that we should cease dependency on inspection. Does this mean that we should try to eliminate testing in favor of prevention?

Machiel Groeneveld tweeted about (automated) testing, he argued that tests fit Deming’s definition of inspection.

I replied that, when tests are being developed and executed at the same time as the software, you could see that as a form of “build quality in” instead of inspection. That leaves room for interpretation, as Machiel instantly noted. For instance, does that only include developer tests? Or do tests from a separate tester (in the same team) also qualify as built-in quality?

Lars Vonk chipped in that software tests should not be primarily aimed at quality, but as a tool to prevent bugs and as a process improvement tool.

Donald Reinertsen then introduced an economic perspective on the situation. His argument is that there is an economic tradeoff between prevention and inspection. If inspection (and the associated rework) is economically more feasible than prevention, than you may have a legitimate case for inspection, despite Deming’s principle.

Deming’s underlying assumption is that prevention is always cheaper, because to prevent an error from happening again is a one-time investment, while inspection and rework is a recurring cost. An interesting observation is that automated tests may violate this assumption. An automated test lowers test execution cost significantly, maybe even more than the cost of preventing bugs. Reinertsen uses the example of the spelling checker: experience tells us that inspection with a spell checker is cheaper than preventing spelling errors in the first place.

If you or your team are moving more towards prevention instead of inspection, that’s a good thing. But keep in mind that one day, the cost of more prevention might outweigh the cost of inspection and rework. As soon as you hit that point, look for more valuable alternatives to improve your process.

User Stories are a nifty concept to convey “what needs to be done” in an agile environment, where not all analysis and design activities have been done before coding has started.

User stories need to be clear and concise, and everybody (Product Owner and Team) should have a basic understanding of the story during the Sprint Planning. Just enough info to determine the approximate size of the beast.

After the Sprint Planning, there will be (should be) LOTS of conversation and confirmation. By definition. Because the requirement is still only briefly analyzed, it is a false expectation to be able to understand and code a user story right after Sprint Planning (of course, it happens, but it shouldn’t be the standard).

I sometimes come across teams that look back and conclude that they didn’t deliver what was expected and propose to be “more clear in the wording and details of the user stories”. Don’t try to go that path. It’s a slippery slope, and before you know it, you’ll be back reviewing detailed designs. You might say it’s an anti-pattern of agile.

I don’t care what the user story says.

Make sure everybody has a basic understanding at first and work together to deliver what’s expected. That’s my preferred strategy if you adhere to agile principles.

Photo taken from koalazymonkey’s photostream under Creative Commons license.

Recently I wrote an article (in Dutch) for Whitehorses that discusses technical debt. What is it, when (not) to use it and how to deal with it in environments that have lots of it.

Read it here: “Kort-door-de-bocht of elegant?“