Software Development

The three basics of software development governance; Jidoka, Poka-yoke y Kaizen

Oct, 28, 2019 | Reading 3 min.

Toyota surprised the world with the development, by necessity, of its Toyota Production System or, as they hastened to call it in the West, Lean Manufacturing. The bases of this system may seem simple once explained, as simple as Columbus’ egg, the difficult thing was to develop and, above all, apply them.

Why apply them?

Simply because in spite of being known by all, many companies still do not incorporate them in their day-to-day work, despite the fact that Lean has been able to end with a model as consolidated as mass production, and that had generated so much money.

But, what are the basic pillars to apply in the software development governance to take advantage of part of the power it gives us in avoiding waste? Let’s look at them.


Jidoka is the principle of detecting errors as soon as possible, to avoid unnecessary waste in the processes that use the wrong data. In the software development governance, one of the pillars is the definition of the budget, avoiding errors in this calculation becomes a vital task for the software development life cycle that needs the funds are in accordance with the effort that we will need. For that, having a tool that allows us to calculate the software development budget taking into account the idiosyncrasy of our company, the way we do things, and follow a rigorous, precise, and standardized method, becomes a vital need and that is why we have included it in Quanter.


Do you like to do things twice? And thrice or four times? Well, if we were referring to playing with your children or watching a movie or a football match, you would say yes, but if we are referring to calculating the budget or the cost of software development because previous calculations have been wrong, we are no longer so willing. Having a fail-safe tool, which is what poka-yoke means, will give us a huge advantage in our governance.

Can anyone make a mistake when plugging in an appliance? You can’t accidentally make a mistake, because the plugs prevent you from plugging in something that isn’t suitable. This is an application of the poka-yoke principle. A tool to calculate the cost of projects that avoids technical terminology, that avoids interpretations, that makes everything clear and that avoids error, the error of the user, can mean the difference between success and failure of a software development governance. That is why we have made Quanter error-proof.


Kaizen has a clear and direct translation: continuous improvement. Without continuous improvement, everything else is of no use to us. What good is a system that allows us to incorporate a method that is reliable, accurate, simple, and recognizable as the industry standard and that also allows us to implement it in a fail-safe way, safe from human errors that can occur through ignorance, it would not do us much good. Therefore, our tool must have a part that allows us to know how we were in the past and how we evolve over time, to know where we need to focus and where we need to improve. Because there is nothing more beautiful than criticism because it helps us to improve because if we don’t improve we will stop competing.

Quanter is an initiative we are driving from LedaMC with that goal in mind, a tool based on all these features to help our customers in their software development governance including Jidoka, Poka-yoke, and Kaizen because our desire is to facilitate and provide an adequate and waste-free software development governance.

About the author

| | | | | | |