A software development/product development organization should always be learning and improving.
When the organization is not learning or improving means that it is going backward, software development is a complex socio-technical system formed by several interrelated reinforcing loops. Some of the loops are positive (virtuous cycles) and some negative (vicious cycles), but the problem is that in such a complex system is difficult to find any balance, so in general, we are always moving.
So the question is, in which direction? Are we learning and improving as a team, or are we dying or falling behind?
Even if we managed to maintain a continuous flow of development with stable quality and speed (which is impossible), the whole ecosystem around us continues to improve and advance, so even in that case, we would be losing ground.
In general, the reinforcing loops are generated by things that compound with time or volume.
For example, these are some things with negative compound effects:
- Complexity and basal cost of the product (cumulative features)
- Quality problems.
- Technical debt (if not managed).
Virtuous cycles examples:
- Continuous delivery requires quality, requires small batches, removes silos, improves ownership, etc.
- Product Team ownership requires autonomy, requires product instrumentation, requires learning from customers, generating more value, etc.
Vicious cycles examples:
- Unmanaged technical debt, remove capacity from the team, generate more pressure, generate more technical debt, etc.
- Accidental complexity makes difficult to understand the code, so generate more bugs, generate more pressure for the team, generate poor solutions with more accidental complexity, etc.
- A bad deployment process generates frustration, so we tend to larger batches that are riskier, so have more problems, generate even more frustration, etc.
When we have several of these vicious cycles, it is easier than it seems to fall into a downward spiral from which we cannot get out.
So, are you investing in breaking the vicious cycles of poor quality, high resource usage, and unmanaged technical debt? Or are you investing in improving your virtuous cycles of working in small batches, with ownership and high quality?
Are you improving, or are you dying and falling behind?
And if the problem is that you don't know what a high-performance technology organization should look like, you are lucky; we now have information on how it should be (Accelerate book).