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.

photo credit: criggle1

…but some people tend to treat them that way.

Lately, a lot of agilists are discussing differences, similarities and (in)compatibilities between Kanban, Lean and Scrum. Google is your friend here, search for “scrum vs kanban“, “scrum vs lean” and “lean vs kanban” to get you started. In this post I’ll add my opinion to the discussion.

Scrum is a very popular framework for managing the software development process. It has a small number of roles, artifacts and meetings, which makes it easy to grasp. Scrum gives you some guidance when starting out with an agile development process. It is based on multidisciplinary teams that are authorized to do whatever is necessary to deliver working software to their customer, working in short iterations to enable fast feedback and delivery, regularly inspecting and adapting their process for improvements.

More about Scrum can be read here, here and here.

Lean is a mindset. It is used for production environments (e.g. the Toyota Production System) as well as product development environments. Depending on who you ask or what you read, there are several principles you should adhere to. To quote Womack and Jones, these principles are:

• Identify value
• Map the value stream
• Create flow
• Establish pull
• Strive for perfection

The Poppendiecks have translated these principles to software development in their book “Lean Software Development” and added twenty-something tools you can use to create and support a lean software development process. Their book is recommended reading (if you haven’t already).

More on lean can be read here, here and here.

Kanban is very closely related to Lean. When people use the term Kanban, they mostly mean “kanban system”. A kanban is literally a “signal” that can be used to trigger activities in your value chain. In fact, a kanban is a tool to implement lean principles like flow and pull. Every piece of work needs to flow through all activities to create value for the customer. Kanbans are used to make sure that there is not too much work-in-progress and everybody in the value chain focuses on the work at hand. A kanban also points out bottlenecks in your value chain if a certain activity takes unusually long and redirects all efforts in the value chain to elevate the bottleneck.

More on Kanban can be read here and here.

To me, Lean and Kanban are synonymous with respect to software development. The Kanban movement promotes a lean process to deliver software. It lets you think about your value stream, gives you tools to make work flow and lets the customer pull that work. Combined with a regular reflection on process improvement, Kanban equals Lean.

Scrum and Lean are not synonymous. However, they do share common ground in their principles. Scrum has a strong focus on value creation (just as Lean), limits work-in-progress to a “sensible” amount each iteration, puts the customer in control (pull, which is controlled by Sprint Planning) and has regular process improvement meetings (Sprint Retrospective). They mostly differ in how they apply practices and tools to the situation at hand.

Scrum and Kanban are also not synonymous (which follows logically from the previous two paragraphs ). To me, the biggest difference is whether to use iterations or not. The Kanban movement eliminates the need for iterations, while Scrum makes extensive use of iterations.

The real question is of course not what differences, similarities and compatibilities exist, but what method/framework/mindset to use? The consultant answer here is, “it depends”. Every project, team or organisation has its own context where one or the other may be a better fit. There is no “single best answer”. Generally, I would advise Kanban in a context where priorities tend to change much quicker than the length of an iteration, while Scrum is a better fit if priorities are usually stable throughout the length of an iteration. And I would advise everybody to use lean principles in every problem at hand, no matter what tool you will use to solve it .