Professional Development
Lightning Talk: Tracking Your Professional Life
Summarized using AI

Lightning Talk: Tracking Your Professional Life

by Tobias Schulz-Hess

Summary of "Lightning Talk: Tracking Your Professional Life"

The video features Tobias Schulz-Hess discussing how professionals can effectively track their performance in software development, drawing on research findings from the "State of DevOps Report". The talk emphasizes the importance of measuring specific metrics to better understand both individual and team performance within the tech industry.

Key Points Discussed:

  • Tracking Fitness vs. Professional Life: Schulz-Hess starts by contrasting the common habit of tracking fitness activities, like steps, with the lesser tendency to monitor professional performance.
  • Challenges in Measurement: He highlights the difficulty in finding effective metrics in software development, noting that traditional inventory methods do not apply due to the "invisible" nature of software outputs.
  • Key Metrics Identified in the Study:
    • Deployment Frequency: Measures how often code is deployed, reflecting the capability and readiness of the development team.
    • Lead Time: The duration from completing code to its deployment, indicating the efficiency of processes in place.
    • Change Failure Percentage: Tracks the rate of deploying faulty code, which indicates overall process quality.
    • Mean Time to Recover: The time taken to recover from a problematic deployment, relevant to code complexity.
  • Interconnectivity of Metrics: Schulz-Hess explains how these metrics are interrelated—improving one can positively impact the others, thus enhancing overall team performance.
  • Overcoming the Trade-Off Myth: The talk rebuffs the idea that improving performance requires sacrificing stability or quality, showing that advancements can occur in both areas simultaneously.
  • Use of Tools for Metrics Tracking: Schulz-Hess shares his experience with utilizing existing tools to gather and analyze these metrics, enabling better visibility into team effectiveness without needing drastic process changes.

Conclusion:

In conclusion, the main takeaway from Tobias Schulz-Hess's presentation is the critical importance of utilizing specific metrics to assess and enhance team performance in software development. By implementing these metrics, teams can improve communication, streamline processes, and achieve better stability and quality in their work.

This insightful discussion encourages professionals to adopt a data-driven approach to track and enhance their performance, making them more effective in their roles.

00:00:02.939 Let's go.
00:00:05.110 Hello! Today, I brought you a gift.
00:00:10.030 The gift of knowledge.
00:00:12.570 The gift to know how good you and your team actually are. So, who among you is tracking your fitness or steps? Hands up!
00:00:19.800 Quite a number of people. Now, how many of you are tracking your performance in your professional life?
00:00:23.160 Well, that's a few people. But why don't you do it? Why don't you track your performance in your professional life? One of the reasons is that it's hard. There's hardly any metrics in software development that are really effective.
00:00:37.860 Usually, when you merge something, you look at the inventory—what's coming in and what's going out. However, in software development, the inventory is invisible, and it doesn't make sense to count it until now. Nicole Forsgren and Jez Humble conducted a study over four years. They collected about twenty-three thousand responses from developers all over the world, from more than two thousand different companies.
00:01:06.530 They worked on the data, and the study they performed is called the "State of DevOps Report," which is available in the book "Accelerate." Among other things, they found four key metrics that are actually good ways to measure team performance. These metrics support each other, so let me go over them.
00:01:34.890 The first one is deployment frequency, which is essentially how often we deploy. Why is this a good metric? Well, you can deploy often if you have good developers who can produce features that are actually deployable. If you also have good testing in place, you will be confident that what you deploy won't break the code. Additionally, if you have good team communication, you prevent someone in the team from accidentally committing bad code. Therefore, deployment frequency is a good indirect measure of team health.
00:02:03.540 The next metric is lead time, which measures the time from writing the last line of code until it is actually shipped to production. Again, lead time is a good indirect measure of the effectiveness of your deployment process. The third metric is change failure percentage, which indicates how often you deploy bad code to production. This is a good indication of the quality of the overall development process and is closely related to the next metric: mean time to recover.
00:02:44.660 Mean time to recover is the time it takes for you to recover from a bad deployment to production. It serves as an indirect measure of code complexity. All these metrics support each other well. To improve lead time, you need to focus on writing clean code and the work that matters. Once you've accomplished this, you'll deploy more often because you'll have a more effective process.
00:03:11.870 If you deploy more often, you might want to improve your automation, which includes having automated tests, a deployment pipeline, and so on. By doing this, you'll also reduce your mean time to recover. To improve mean time to recover, enhance your monitoring systems to detect defects early on, perhaps even in your pre-production environment.
00:03:48.200 This will ultimately help you reduce the change failure percentage. Moreover, to further improve this percentage, you need to enhance communication within your team. This leads to reduced lead time as well.
00:04:19.200 Another additional benefit is that there is a common belief that a trade-off exists between improving performance and achieving higher levels of stability and quality. However, this study proves that wrong; you can do better in all of these measures.
00:04:39.430 From my perspective, I found it easy to gather these metrics from the tools we already have in place. My team and I use a key metrics framework to track our progress. We haven't changed the processes we already have, but now we can see how effectively we are doing with the things we discuss in our retrospectives.
00:05:01.630 My name is Tobias Schulz-Hess. Feel free to connect with me if you want to know more.
00:05:10.950 Thank you very much. Thank you! So, the next talk is about Price Explorer.
Explore all talks recorded at Ruby Unconf 2019
+17