header-hero-dark1

Be Efficient: Reduce Effort for Defect Fixing

CIOs, IT Executives,
Product Owners

Use Case CIO Product Owner

Project Managers,
Application Managers

Use Case Product Manager

Software Architects,
IT Architects

Use Case Software Architect

Engineering Leaders
 

Use Case Engineering Manager

You are responsible for a development team that works on a software system.

You need to make sure that the developers can spend as much time as possible on value-generating features.

Hence, you need to identify and remove obstacles in the development process that steal developer time.

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, …)

context

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
Pains

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.

Gains
background-02

Contact us & discuss with a Seerene expert
how to relieve your pains and boost your gains

Contact Client Success Team