In today’s blog post we will start to look into another common symptom; “Hidden faults/low quality are discovered too late”. This is a really treacherous symptoms and is part of many other chains, which means that when we analysing faults and quality problems, we need really understand which principle(s) we are violating.
Asking why on “Hidden faults/low quality are discovered too late” gives these three symptoms.
- “Contradictory/late requirement changes”, which is already part of a chain of symptoms. This chain represent complexity, the Complex domain, if we refer to the Cynefin™ framework [1]. For faults and low quality this symptom means changes to what was originally planned with the risk of that everything is not considered. The system requirements for the product has already been set, and what is happening is that we many times do not have the time to redesign the product, and instead we add things on. The implication of this is that it will give us chains of symptoms, and many we can see and we can try to cure the worst ones, but everything cannot be seen. We can see it as trying to cure symptoms, which is impossible.
- “Too slow feedback”, which is the latter part of the “Contradictory/late requirement changes” chain, and represents the ordered domains in the Cynefin™ framework, when we already have the knowledge, with or without the help of experts. Here we find for example repetitive work like production, service, or late in the product development cycle when we already have gained the knowledge, etc. This means that some faults and low quality we get because we have a too slow feedback, depending on too big batches. And my own experience says that, if too many problems are corrected in early stages of the project, that for sure indicates that the customer also will experience many problems later on.
- “We have a crappy systemisation”, an old favourite, which is already part of a chain of symptoms. And of course, if our architecture is bad from beginning, will give us a product looking like a patchwork. Visible for the customer if it is hardware, but invisible in software, but the bugs from patchwork code is painfully visible for the customers.
A part of the Prefilled Problem Picture Analysis Map with the chain of symptoms for “Hidden faults/low quality are discovered too late” will then look like this, where the already found chains are scaled down:
And as we can see, we have the same root causes as for the symptom “Contradictory/late requirement changes”. This is not unexpected, since bad planning of the architecture, late changes of the requirements, too big batches, will not only slow us down for the moment, it will have a big and bad impact on hidden faults and low quality in the future. It does not matter if it is product development or the later production of the products, our risk decisions in the line and the projects must always be balanced, otherwise we will destroy ourselves with bad quality.
This was all for this blog post, and in the next blog post in this series we continue with the next symptom, “Cadence problems”, a special made chain of symptoms to challenge the need of unnecessary big margins, especially in sprints. C u then.