It’s a cliché that the perfect is the enemy of good. It’s also a driving principle of agile software development. Delivering software, or even ideas, that are good enough to work with but not “perfect” can encourage collaboration and creativity—and lead to a better solution.
But finding the line between “good enough” and “good riddance” can be tricky. It’s possible to get caught up in the drive to deliver something quickly and lose track of the goal of delivering value. We have to deliver value, first of all the MVP, and step by step add more and more value.
But, how can we detect if this “good enough” is really “good enough”? what is good enough for us? what is good enough for our current clients? what is good enough to get new clients? Sometimes, whatever works is good enough.
Following rules like the principle of good enough is more complicated than it appears.
Getting to good enough starts with planning an outcome in mind that’s good enough and then comparing it to our perfect outcome: what’s different in how we achieve each?
Having high standards is not the same thing as demanding perfection. Making mistakes is part of playing the game; mistakes are part of progress, they make us improve and grow.
Our challenge is to create an environment that makes it safe to assert that something is good enough, an environment that helps teams be comfortable deciding it, an environment that leads to the right kind of “incremental perfection“. This way, we can reduce our time to deliver and also deliver more value.
Summing-up: we have to work and deliver value taking always into account whether it’s “good enough”. Depending on the context, “good enough” can means different things, with more or less functionality and quality. Sometimes, if it only works, it could be “good enough”.
These notes have been taken from: