Be Efficient: Reduce Effort for Defect Fixing

Context

This use case is applicable to any kind of software development, independent of process methodologies (waterfall, agile, scaled agile, V-model, …) or type of software systems (IT applications, SaaS, mobile apps, embedded systems, …)

Pains

You see that your developers spend a significant portion of their time for defect fixing. This is “wasted” time that should be used for implementing valuable features instead.

You can only observe the developers' fight against the defect backlog but you don’t see recurring patterns and neuralgic points that cause the defects. Hence, you cannot pinpoint and eliminate the root causes. For example:

• Are there hotspots in the code landscape that need to be fixed over and over again?
• Do these hotspots contain complex code (“technical debt”) that is difficult to be understood?
• Are these hotspots only weakly secured by automated tests?
• Do developers have to enter into unfamiliar code that is additionally complex?
• Do developers perform code changes that are largely scattered across the architecture?

To reduce this wasteful defect fixing you would need to trigger improvement measures in multiple dimensions. But which ones and where to start?

• Focus on code: reducing code complexities and optimizing architecture decomposition
• Focus on testing: increasing test automation
• Focus on team structure: finding the sweet spot of code-ownership and harmful knowledge monopolies

Gains

It would be helpful to quantify the amount of time spent for defect fixing as KPI. This way, you could systematically monitor the effectiveness of your improvement measures.

An early warning system would be perfect that tells you about future defect risks, for example, because of:

• Blind spots in the test automation
• Increases in technical debt
• Team fluctuations and bad knowledge distributions
• Requirements that induce broadly scattered changes in the code architecture

Light-weight but effective risk-mitigating activities should be integrated into the daily doing of the developers. For example:

• Determining how well a work item (story, change request) is secured by test automation and adding an appropriate code coverage threshold to the definition-of-done for work items.
• Remark: This requires a profound analytics approach that determines the code units that are changed in the context of a work item and calculates code coverage by tests for exactly these code units.

An effort stream monitoring would be helpful to steer towards the sweet spot between working on test code versus production code.