Hi Zhanara,

I have read the article, and it remembers me several years ago. Yet, I have never been Scrum Master, and although I had my own teams, always felt that some of these approach were wrong. It took me years to realize what was wrong and correct it.

My feeling about many of the metrics presented are not about agile but more about Scrum (ex: Agile is not about Sprints), and about how some non developers perceive development.

Some of the red flags for me are things like the Bug/Development ratio. It seems like that you correlate innovation with bugs, but often is the contrary: keeping the code straight on the old path creates more bugs than solves. For example, in one of my most appreciated stories, I describe how I fixed 1,000 bugs, and it was innovating. And since then, more than 10 years ago, I have seen this path repeating once and once again. With that red flag also comes the red flag of time allocation, that is nonsense. Bugs have two main origins: 1) businesses did not understand the consequences of what they asked, or 2) developers have created the wrong code design. The third, small mistakes, are corrected quickly without much effort, so we can dismiss them.

But what I miss more about this article is talking about real research-based metrics. You show numbers and graphs, and I have no doubt that you have made serious research on the topics that you expose, and that you have used retrospectives extensively to test new theories and came with new ideas. Yet, that cannot compare with some research out there.

For example, in software development —not just "Agile"— there are four key metrics, powerful enough that can steer any development and improve them. I presented them in my article, and although they came from the Accelerate Book —by Nicole Forsgren— based on research over more than 50.000 companies, I add some of the insights that authors explain in talks and other forums. And that research came with just the four key metrics, and their discoveries about other many metrics that were not as effective as the main four.

Another red flag is that most of the metrics seem more focused on the capacity of reporting of the developers, rather than their actual work. Most of them are based on Jira, and they would only work if the developers diligently update them. So, a simple metric can be improved by just improving the report. Instead, the four key metrics can be calculated with the results of what the developers do. There is no need for them to report anything, because it leverages on the same existing automations that help developers to deliver. If you google for the four key metrics, you fill find a page from google explaining how to extract those metrics. They even have the SQL queries.

I have no experience as Scrum Master. My vision of Agile is not the one that Scrum defines. I focus too much on what the developers do. Sometimes things are not as easy as I pose. Yet, the four key metrics, year after year, have demonstrated to solve most of the problems.

Maybe I have a bias towards those metrics, maybe it is my position, maybe it is what I faced in the past, but I believe that we cannot speak about metrics in any kind of software development, if the four metrics are not part of them.