When you ride a dead horse, dismount! (old Indian proverb)
In many companies today, there is still a culture where it does not pay to openly admit a fail. People are affraid that open communicating about bad customer feedback will be seen as a personal failure by their colleagues or company management. And they also worry about the consequences for their career growth or even a job in the company. They have become accustomed to selling presentations full of successes, but you sometimes find out the real state only during informal communication somewhere in the corridor or over coffee.
The whole thing then leads to the fact that we spend a lot of money on the operation and maintenance of projects or even entire applications that are actually not worth maintaining and should be stopped. But we don’t know about it, or we’re afraid to admit it.
Why is this?
This situation is due to the corporate culture. However, it does not arise by itself and is usually influenced by a number of things such as corporate processes, setting rewards, or even a strict superior.
Possible reasons for this include the following:
- Absence of a safe environment
- Part of the company supports learning from mistakes and the other part does not yet
- We can´t yet make small enough versions of products or projects that wouldn’t cost as much money to discover the bug
- Lack of transparent communication in the company
- Admitting failure has an impact on our rewards
How much does it cost us to ride a dead horse?
It depends, of course, on how often this pattern of behavior occurs in your company. However, it can be said that the following items will appear in the budget, for example:
- Costs for further development of functionality that has no value
- Increased costs for regression testing and analysis so as not to break existing functionality
- Higher operating costs – capacity of people and hardware
- Reduced motivation of people who know the real state, risk of burnout
- Technical debt is growing
So what will help us reduce these unnecessary costs?
If you know that these problems also occur in your company, your scrum master or agile coach can help you with the change. However, it certainly cannot do without the active support of the company’s management. Here’s what worked for us:
- Let people know that you want information about what went wrong
- Try to find out what settings in your company today prevent people from making this change.
- Learn to verify success on smaller parts – prototypes, or small functionalities that already have value for the customer (MVP)
- Lead by an example
- Praise people for admitting a fail that happened
- Ask them how they learned from their mistake so it doesn’t happen again
- Do not decide remedies for them.
- It always works better when corrective action is devised right where the error originated. For example, teams can schedule a retrospective on this topic and then tell others how they want to prevent the mistake next time.
- Learn to praise people for a sealed useless project, admitting the result of a failed MVP, or even a canceled unused application.
And what works for building open communication about successes and failures for you?
Pingback: Illusions about team performance and fragmented focus - Lucid Bay Digital
Pingback: Muda or 7 Types of Waste in Software Production - Lucid Bay Digital