From childhood we are programmed to fear the failure, the opposite behavior is rewarded. I still see many companies & people trying to recruit people with a “Failure is not an option” requirement. Such practices reinforce this behavior. In many cases the “prevention” causes more problem & costs more than the actual issue. Without failure there is no learning. Any process/framework/companies which needs people to follow the “dotted” lines and where “failure is not an option” will not result in innovation or new ideas ; And eventually they will cease to exist. A lot has changed in the last decade, now we have tools and process to give instantaneous feedback to any changes we can think of. Clean code + Short feedback cycle (CI/CD) + automation + transparent data metrics should be the cornerstone for any software development team A good software development strategy will have process to review failures and make the changes to ensure that people are learning from their mistakes. S
Agile teams work in iterations. During this period, they are supposed to work on product increments which can be “delivered” at the end of iteration. But how you know that the correct product was delivered? Many teams have different kinds of acceptance criteria and Definition of Done (DoD). But in many cases, this “done” is not the real “done” there might be some testing pending, some integration or review pending or anything else which prevents the actual use of the product increment. Many of these teams will need additional iterations to finish hardening their products. Many teams will implement different types of “gates” or approval steps to move to next stage. The free flow of product will be interrupted. They might end up doing mini waterfall within their agile process. Many don’t even realize this. This results in poor quality and requires additional effort to “harden” the product. Potentially Shippable Product increment The acceptance criteria and DoD should be modified