Optimizing Software Development with Evidence-Based Approaches
“Without data, you’re just another person with an opinion.” — W. Edwards Deming

Optimizing Software Development with Evidence-Based Approaches

This post discusses how the software development process can be optimized by using an Evidence-Based KPIs approach alongside a continuous improvement process.

Why Use Evidence-Based Approaches?

Are you certain about the real causes of your project's problems? Or could your judgment be influenced by cognitive biases such as:

  • Status quo bias
  • Confirmation bias
  • Illusions of validity and skill
  • Overconfidence bias
  • Recency bias
  • Anchoring bias
  • Sunk cost fallacy

In general, cognitive bias refers to the systematic tendencies of the human brain to deviate from rationality or optimal judgment in decision-making processes. These biases arise from the brain's inclination to simplify complex information processing and can manifest in various forms, influencing perception, memory, and decision-making.

Implementing evidence-based practices alongside Key Performance Indicators (KPIs) is crucial for mitigating cognitive biases. Here are some advantages:

  • Objective Decision-Making: Using KPIs as measurable metrics enables teams to base decisions on objective data rather than subjective opinions or biases.
  • Reduced Confirmation Bias: Relying on empirical evidence instead of seeking information that confirms pre-existing beliefs helps reduce confirmation bias within teams.
  • ?Improved Problem-Solving: KPIs provide clear benchmarks for evaluating the success of software development processes, aiding teams in identifying and addressing issues more effectively.
  • ?Enhanced Accountability: Establishing KPIs for measuring progress holds teams accountable for their performance, mitigating biases such as overconfidence.
  • ?Data-Driven Feedback Loops: Coupling evidence-based practices with KPIs allows teams to establish feedback loops based on real data, facilitating continuous improvement and reducing biases like anchoring or recency bias.
  • ?Informed Risk Management: Insights from KPIs enable teams to make informed decisions about risk management, reducing biases such as the sunk cost fallacy.

In the following sections, I will discuss the importance of employing a continuous improvement process and selecting the most important KPIs for each iteration to ensure successful implementation of Evidence-Based Approaches.

Continuous Improvement

Continuous improvement can be simply defined as 'getting better all the time.' It involves an iterative process where each iteration focuses on making small changes rather than radical ones.

You might consider adopting a methodology such as Scrum for your continuous improvement process. Keep in mind that it's crucial to clarify the improvement objectives before each iteration.

Nowadays, the “popular” candidates for improving your organization’s IT performance are related to the Agile and DevOps practices. Yet, it's essential to remember that Agile, DevOps or any other new “silver bullets” to come?are only means for achieving your?objectives. Therefore, you should always choose and adapt the relevant practices for your?organization’s?or project’s specifics.

In the next section, I will discuss the importance of selecting the most pertinent KPIs when establishing the 'improvement list' or 'activity plan' during each iteration of your continuous improvement process.

KPIs selection

When selecting the KPIs you want to monitor, it's important to apply the 'Law of The Vital Few' (also known as Pareto's Principle or the 80/20 Rule) and choose the KPIs that are most relevant to the major project goals:

Implementing the 80/20 rule facilitates the adoption of continuous improvement as an iterative process, where each iteration focuses on making small changes rather than radical ones.

Below is a non-exhaustive list of 'to be improved items' that you might consider using their relevant KPIs during your continuous improvement process:

Clearly,?the selection of those items is contextual to the project or the organization?state,?objectives,?and priorities.

Top Key Performance Indicators

KPI 1 - Customer Value Delivery Effort

The customer value delivery effort indicates the percentage of the total effort directed towards delivered user stories out of the overall delivery effort for each given period (e.g., sprint).

This metric is one of the most important KPIs. Information related to customer value delivery effort should be continuously collected.

The diagram below provides an example of a Customer Value Delivery KPIs report:

It shows that an average of 56% of effort is spent on delivering customer value. This suggests that the high expenditure of 44% on 'Defect' and 'Technical story' activities should be audited and potentially improved.

We also note that in sprint 4, the team allocated 65% of the effort to bug corrections and technical improvements, while only 35% was dedicated to delivering customer value (user stories). Are you encountering challenges in your product development? It's essential to identify the root cause of this issue:

  • Is it a testing problem?
  • Is it a result of miscommunications between the client, product owner, and developers leading to incorrect specifications?
  • Is it due to a lack of a 'fast feedback' process resulting in an accumulation of error reporting?

Once the root cause is identified, a correction or recovery plan can be established and implemented.

KPI 2 - Defects (bugs) Injection Rate and Defect accumulation

KPI 2.1 - Defect injection rate: ?

The defect injection rate measures the total number of defects detected during a specific interval of time (e.g., days, weeks). The Defect Injection Rate is also a KPIs that should be permanently collected.

The diagram below depicts a report of the defect injection rate over a weekly period:

The high variability of the defect injection rate should be studied.

Can it be attributed to:

  • Bad test quality?
  • Scrum “gaming” phenomenon?

As always, these indicators need to be analyzed within the specific project context.

KPI 2.2 - Defect accumulation ?

Another crucial report to consider is the defect accumulation report, which includes both defect injection and defect removal metrics, as illustrated in the following reports:

(Note that to generate the defect accumulation report, information on defect removal should also be gathered)

The reports above suggest that the project faces a quality issue, as the defect accumulation is increasing instead of converging to 0.

If you are facing a similar situation, conducting a root cause analysis followed by an improvement plan is advisable. Such a plan should include actions such as:

  • Improving the testing process in general
  • Prioritizing an automated early detection process
  • Providing clear best practices recommendations for developers

KPI 3 - Technical Debt

?Technical debt indicates the current correction time (might be indicated in days) required in order to handle all the open defects.

Note that technical debt is closely related to the defect accumulation indicator mentioned above.

The technical debt is of interest to high-level non-technical managers as it helps them understand the number of working days (equivalent to money) required before the product can be delivered.

Note that for most projects, I recommend including only critical and blocked defects in the calculation.

Below is an example of a weekly technical debt report for a project:

The reports indicate that the project's technical debt is increasing over time instead of converging to 0, which suggests quality problems within the project.

As mentioned earlier, a reduction in defect accumulation over time will signify a decrease in technical debt.

KPI 4 - Flow efficiency.

Flow efficiency measures the ratio of time spent on active work to the time spent in the pending state for each activity.

The slogan attributed to Agile, 'Stop starting, start finishing' emphasizes the importance of monitoring this indicator.

The reports below provide an example of flow efficiency for 14 sprint periods:

Note that a high number of 'pending state' days indicates bottlenecks.

In cases like the example above, where the “Pending” average is 34%, it's crucial to investigate the causes of these bottlenecks.

For instance:

  • Are activities blocked too often due to coordination and planning issues?
  • Was the task switching overhead taken into consideration?
  • Is the “WIP limit” definition optimal or should it be modified?

The flow efficiency indicator will help optimize the product flow and enable the implementation of a continuous integration and continuous delivery process.

Key Takeaways

  • Implementing Evidence-Based KPIs practices is crucial for mitigating cognitive biases.
  • Some of the advantages of Evidence-Based KPIs practices include: Objective Decision-Making, Reduced Confirmation Bias, Improved Problem-Solving, Enhanced Accountability, Data-Driven Feedback Loops, and Informed Risk Management.
  • ?The implementation of Evidence-Based KPIs practices should be carried out as a continuous improvement process.
  • ?In each iteration, improvements are made through small changes rather than radical ones, aligning with the Pareto principle. Therefore, it is advisable to limit the number of KPIs to no more than four at a time, especially during the early stages of the process.
  • ?Many KPIs are worth collecting for a period of time. Each time you introduce and begin collecting a new KPI, you need to establish a mechanism to stop collecting that metric at some point in the future.
  • It is highly recommended to begin the Evidence-Based practices with the following KPIs - Customer Value Delivery effort , Defects (bugs) Injection Rate, and Defect accumulation, Technical Debt and Flow Efficiency

?

Contact

Mendelson Amir

Paris, FRANCE

Email : [email protected]

Linkedin : www.dhirubhai.net/in/mendelsonamir/

Copyright ? 2019,2022?Mendelson Amir

Mooly Beeri

Founder and CEO at BetterSoftware.dev | Revolutionizing Software Excellence | 25+ Years in Software Transformation & DevOps

6 个月

This is a great article, we are on a mission to solve the exact same problem, how to improve over time (which everyone wants) but do it in a quantitative way. Amir, looks like you are focusing on choosing the right KPI for each improvement effort, which I like a lot! we also look at the process of improving and measure its effectiveness. I would consider re-looking at your 'evidence based KPI' with the view of measuring the effectiveness of the process of improvement itself... in any case, happy to see other people invested a similar field of thoughts, thanks for creating this content!

回复

要查看或添加评论,请登录

Mendelson Amir的更多文章

社区洞察

其他会员也浏览了