The first answer to this question is…. ‘quality build in’.

The Toyota philosophy knows the concept of Poka-yoke, ‘mistake proofing a device by preventing, correcting, or drawing attention to human errors as they occur’. Poka-yoke is a means of building quality into the device since it prevents making mistakes. It doesn’t only have an effect downstream. In combination with ‘stop the line’ (stopping production and finding the root cause of defects) this also works upstream.

Maria Montessori, the inventor of the Montessori Method (child education), uses the same concept. The Montessori Material has a build in ‘control of error’. The children work with the material but don’t need the teachers assistance to check their own work. The check is build in.

Agile IT knows concepts like continuous integration, test automation and tracing and logging to build quality within the development process and within the IT solution. Guessing whether the solution works is not necessary, nor a lengthy manual testing phase. You get instant feedback on the quality of the solution. (Of course test automation does have it’s price). When the solution has gone into production, build in tracing and logging helps locating and fixing problems.

All three cases share the concept of ‘quality build in’, but that’s not the true connection. The true advantage of ‘quality build in’ lies in increasing the learning capacity.

The effectiveness of the learning process is greatly influenced by the feedback cycle. We need feedback to determine if what we do is right. The shorter the feedback cycle, the better. Building quality into the process and product shortens the feedback cycle substantially.

The true connection between the Montessori Method, The Toyota Way and Agile IT is that all three are learning processes.