Lean/Agile KPIs for Large Enterprise Systems (Part 2)

Continuing from the ‘Predictability” KPI from the last post

Reliability: Reliability means that changes in priority can be addressed quickly with minimal cost and quality. It’s common that teams don’t believe in ‘TDD’ or ‘Automation Pyramid’ and although the cost is high at initial phase but the overall reliability is great as the project progresses or for the releases.

Metric to measure is 1) Technical Debt 2) Functional Debt

1) TD: TD may arise from poor decisions made on requirement, design and code but also could be deliberately introduced since at that time there was no other alternative solution for the release. Technical debt can be invisible in the projects and may create a huge backlogs for the product in the long run but can be managed in long run with teams choosing items from backlogs to develop/fix/configure one by one. TD may be categorised as (but not limited to):

• Architectural Debt — Examples are Needless dependencies of components , Layering violations, poor cohesion, poorly understood modules, Cyclic dependencies, redundant systems, and unused systems.
• Code Hygiene — Examples are duplicated code, dead code, inadequate documentation, huge classes, inconsistent code standards etc. Teams may skip these for a sprint/release but need to fix in subsequent releases.
• Process Debt — Processes become more complex and inefficient over time. Examples include builds, automated tests, check-ins, reviews, bug logging, bug tracking, etc.

Measuring TD : Use tools or Ratio. There are several s/w tools that scan code to determine whether it meets coding standards defined. These tools include SonarQube, Sonarj etc.

Use following Ratio to measure . Generally, no teams wants a high TDR, some teams favour values less than or equal to 5%. High TDR scores reflect software that’s in a really poor state of quality.

Technical Debt Ratio = (Remediation Cost / Development Cost) x 100%

2) Functional Debt — As products grow , becomes complex and team members , functionality is lost ie lacks documentation. It takes longer for developers to become familiar with the workings of coupled systems. This can lead to cases where existing features are re-implemented/ reworked

to be continued