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.