Bug and transparency
Ben, an engineer in our development team reported two issues from production and he didn’t like to report them as bugs. A bug is visualized as red card on the visual board and is visual to the whole organization. Moreover, Ben’s manager when looking at the board and saw red ticket, he began monitoring bugs. This is acceptable, however, he started attributing bugs to specific developers and considered this part of not doing good job. This manager is the one who completes the yearly appraisal of Ben and he is considering these red cards on the board as input for evaluation the performance of his people.
Ben today was unshaved and depressed. All what he wishes to happen is to tear down the visual board which I demand to have the bugs in red, while his manager punishes him for what I am asking. Ben pushed back to add cards on the board and he tried to give political non-accurate meaning by renaming it as task or enhancement and not to call it in its real name “BUG”.
I can think of the following scenarios, if Ben situation persisted:
- Continually being depressed
- Unmotivated and lost interest in quality and process improvement
- Quit the company
- Loses morale and fabricate the work to appear correct while it’s ion reality defective
Many other scenarios can happen in addition to the previous ones, which non of them is positive.
Encouraging people to report issues and bugs is part of respect of people. It’s a catalyst to drive fear out from people so that they are proud of their work and therefore interested to continually improve their development skills. Trusted people can innovate, they are well aligned with the organization and motivated enough to proactively find issues rather than hiding bugs. I lost Ben’s interest to come up with unnoticed problems which are a common situation in software development.
The visual board has exposed management dysfunction at middle and higher level about building their teams. Though bugs are waste which create the hidden factory and should be removed, the management solution to this problem is “Carrot and Stick” based. In other words, punish those who produce bugs. Management discounted that the problem is not because of people, it’s because of the process and hand-offs among various groups. In fact, the problem because of the work ethics and culture which management put in place.
If I were Ben’s manager, I would ask him to expose more issues, praise him for his authenticity and institutionalize periodic sessions for Root Cause analysis with no attributions. The Root Cause Analysis meeting has developers as main attendees, project manager is facilitator, and management review findings for decision-making.
Fear is the root cause of jeopardizing the measurements system and produce mis-leading metrics on product quality. Ben and his colleagues, because of the way they have been evaluated, will manipulate the measurement system. This if they chose not to quit!