Category: Reposts

In a long tradition of consultants imposing cookie-cutter solutions, McKinsey introduced a framework to measure developer productivity, which has triggered strong reactions in the software community (from Dan North, Kent Beck, or Gergely Orosz).

The problem with productivity is not measuring it, but why we measure it in the first place. When we decide to measure something, it is because we have recognized a gap of knowledge we need to fill to improve our chances of making the business numbers. Halve the bad, double the good, the lean mantra goes. Reduce the number of bugs by half, reduce the delivery lead time by half, double the number of zero bug features, double the number of experts in the team, double the positive customer feedback, and so on. Productivity only measures how fast and efficient we are at learning and improving to reach those ambitious goals.

Flavian Hautbois

https://blog.buildtosell.org/productivity-in-software-development-the-lean-perspective/

Flavian discusses the topic of productivity in software development from a lean perspective. He criticizes McKinsey’s approach of measuring productivity and introduces three key insights from lean thinking that can lead to developing exceptional software developers.

The first insight emphasizes that measuring productivity should focus on the team’s learning curve and improvement, rather than using it as a reporting or command-and-control tool. Lean productivity measurement considers the number of value units delivered to clients per full-time equivalent per day.

The second insight highlights the importance of team productivity over individual productivity. Lean thinking values teamwork, collaboration, and continuous improvement fostered by a team leader. It discourages measuring individual productivity, which can create a culture of competition and hinder teamwork.

The third insight focuses on the role of managers as coaches to team leaders. The lean approach believes that improving team performance involves working on product quality and creating favorable work conditions. Managers should trust individuals and teams, provide support, and encourage them to suggest and implement process improvements.

DORA Metrics: the Right Answer to measuring engineering team performance

“What metrics should I use to measure my engineering team’s performance?”

I get asked this question often enough to be worth an FAQ.

You might expect my answer to be “it depends” but no: I believe there’s a single right answer! More precisely, there’s an established set of metrics that are so good, so widely applicable, that they should be your starting point.

Jacob aka @jacobian

The DORA metrics mentioned in the article – Deployment Frequency (DF), Lead Time For Changes (LT), Change Failure Rate (CFR), and Mean Time To Recovery (MTTR) – are indeed a great starting point for measuring the performance of an engineering team. These metrics have been extensively researched and found to correlate with successful, high-performing teams.

However, it is important to note that these metrics should not be treated as rigid targets from the outset. It is suggested to measure and monitor these metrics for a period of time before deciding what is considered “good” for your specific team. Prematurely setting targets can lead to Goodhart’s Law, where the measure becomes a target and loses its effectiveness as a measure.

Furthermore, it is crucial to carefully define ancillary terms associated with these metrics. Terms such as “failure,” “recovery,” “change,” and others should be clearly defined to ensure consistency in measurement. Take the time to define how these values will be measured within your team.

The article also provides real examples of how different types of teams can apply the DORA metrics. For example, a feature team may measure DF by counting deploys per day, LT by measuring the time from when an issue is moved to “In Progress” to when it is closed, CFR by determining the percentage of deploys causing a failure, and MTTR by calculating the time to resolve incidents or bugs.

Similarly, a security engineering team may measure DF indirectly by looking at the teams they are embedded in, LT by monitoring their own changes, CFR by tracking security issues introduced during their involvement, and MTTR by measuring the time between initial discovery and final remediation.

An SRE team, on the other hand, may monitor DF and CFR for each component team they support and measure MTTR on an organization-wide basis.

Are you an Elite DevOps performer? Find out with the Four Keys Project explores the four key metrics that organizations can use to evaluate their DevOps practices and drive continuous improvement. I found it to be a valuable resource for anyone interested in enhancing their DevOps performance.

Overall, adopting the DORA metrics requires skill and understanding of the subtleties involved. While these metrics provide a solid foundation, it is also essential to consider additional metrics specific to your team’s goals and objectives. Regular monitoring, root cause analysis, and adjustment based on the relative change in performance can contribute to continuous improvement and align team efforts towards success.