 Hi, everyone. On this session, I'm going to talk about depth team metrics that matter. We're going to learn what are they, why they are important, and how we can use them, and how we can optimize our process after monitoring them. My name is Avishag, but all my friends call me Vichy because it's easier to pronounce and it's shorter to write. I started my tech career on 2013. I was working as a BI developer for the military of Israel. A couple of years later, I moved to all scripts. I started working there as a BI developer as well, but quickly I moved to the R&D team as a software engineer. I worked for all scripts for almost four years, and after that I joined Cisco. In Cisco, I was working a software engineer as well in the cloud security department. I developed features for Cisco umbrella specifically for the SWG solutions. In the middle of 2021, I started working for Linerbi. I worked there as a software engineer as well as team leader. In Linerbi, we are developing delivery intelligence platform and other solutions to help R&D groups and teams to optimize their processes. Other than that, as you can hear, my main language is Hebrew, and I did my studies in the Ben-Gurion University of the Negev. This is in south Israel. Now, I live in Tel Aviv, and on my free time, I enjoy dancing and hanging out with my friends. But enough about me, and let's dive in right to the session. A few days ago, I met friends from the university. When you meet friends that are working as developers as well, there's always this question of how things at work, how is your job, and the answer is binary most of the time. It's either you are very, very happy or you are very, very sad. What I like to call the happy developer and the sad developer. The happy developer is coding most of the time, especially new features. He manages to deliver fast and in high quality. He also feels the impact on his company's customers, and he basically has the time of his life at work. On the other hand, we have the sad developer. The sad developer is very, very sad, and not because of the company's benefits. He struggles. He's working very slow, with lots of context switch, and most of the time is not even coding. He handles many conflicts and rarely develop new features, and he is very, very not satisfied with this current position and current situation. Now I want to talk a little bit about Dora metrics and how they are related to this specific situation. Dora metrics develops research and assessment metrics, a group of four metrics that was defined by Google after years and years of research. This group of metrics measures your team's performance and help you to understand whether you perform well or not, and how healthy your development pipeline is really. Dora metrics can be divided into two categories. The first category is speed, and the other category is quality. I want you to start thinking about it as roads construction and vehicles that use the road that you are building. Your dev pipeline is represented by the roads while the code changes are represented by the vehicles. When you think about the roads, you have many kinds of roads. Some of the roads can be made by different materials. You also have highways, carriageways, cityways. You have many kinds of ways. So when it comes to your speed in the road, you have many factors that can affect on your speed. The obvious one is the road itself. You can drive faster on a highway rather than a cityway, but not all the vehicles share the same speed. Motorcycles can be a lot faster than tracks, for example, which lead me to the second factor, the type of vehicle. Roads quality can be measured in the long run as well as in the short run. If the road was built in a high quality, you will meet that in the field. You will probably have less cracks on the road itself and less accidents, and driving there will be a lot smoother and safer. You can also measure your quality when you meet an accident. If you are able to recover and fix it quick, it indicates that the road is stable and safe for the future and also has the right qualities for fast recovery. Let's see now what are the specific metrics you want to start to measure and how we can do it. Cycle time, our first metric. How quickly your code moves from coding state to deployed state? Think about moving your car from point A to point B. If you'll be able to do it fast, it indicates that your speed is high. Some applies to the coding delivery. If you are able to move your code from coding state to production, you are actually delivering in high speed, regardless the type of vehicles you are using. But our roads are not always straight, and sometimes we need to have stops in the way. Each team might calculate their cycle time in a different way. For example, in our R&D group, we calculate our cycle time as a sum of four stages. You start with coding time from the first commit you do when you are walking on a new branch till the moment you open a pull request that is actually ready for a review. Then you move your code changes into what we call pick-up stage. The moment you open a PR till someone in the team is start reviewing it. After that comes the review stage. From the very first comment that PR gets till it's good to go is being approved and gets merged. This is the review stage. Finally, we have the deploy time. We have the deploy stage. From the moment you merge your pull request till the code changes are actually in production. In our R&D group, we are calculating it by tax creation. These whole stages together are representing the whole cycle time, and the summary of the times together gives us the cycle time itself. When the cycle time is low, you are performing well, but when the cycle time is not low, you are performing not that well. Another way to measure speed is deployment frequency. How often your work is deployed to production and customers actually use it. Here, I want you to think about a circle road and a Formula 1 car. We are given a limited time of one hour to drive this road. The more laps you finish, the faster you are. This applies to deployment time as well. The more deploys you manage to do, the faster you deliver. Both cycle time and deployment time together are indicators of your team's speed. Moving to quality. CFR, change failure rate. How often your deploys results an issue or a bug. This is our long run test for our road construction. This is something we meet only after deployments, sometimes only after customers meet the feature. Reducing CFR will indicate that you are delivering in high quality and also that your pipeline is strong and stable for deliveries. The next metric that measures quality is MTTR. Mean time to restore. When and if you have an issue in production, you want to measure how quickly you recover from it. As for the road and the cars, when you have an accident, you want to measure how quickly you can recover the road itself and handle the involved cars. Doing it fast implies that your road has the right qualities for recovery and also that you as constructors, you have the right skills to fix it quick. Some applies to the coding world. Fixing an issue quick can be achieved when your code base is good and has high quality. Also, these fast fixes can be achieved when you have a stable pipeline to deliver the fixes very fast. Being able to do it quick and immediately indicates that you perform in high quality. Starting measuring this group of four metrics will help you to get a sense of how your team is performing. You will also know whether if your developers are overloaded or not. And this will help you to also understand what changes you need to do in order to create a better workspace and pipeline for your team. Another metric worth mentioning is PR size, pull request size. Till now, we discussed mostly about the road. Now we'll give more focus on the car that uses the road, the type of vehicles that use the road you just created for them. The vehicles are actually the code changes you want to deliver to production. The driver is a developer. Sometimes you have more than one developer that is responsible for the ride. And the number of code changes the PR size is like the car size. So you have many kinds of sizes and types of cars. You have mini cars and you have vans. You have motorcycles and trucks. You have bicycles and buses and endless variety of vehicles. The size can affect both quality and speed. Think about who can be faster in traffic, motorcycle or a truck. Think about when you have an accident, for example, which one will be a lot smaller, which accident will be smaller, the one of the motorcycle or the truck. PR size has a major impact on your speed and quality, especially when you want to deliver fast. In linear B, we did some research regarding to PR size based on our customer's data, and we discovered many interesting things. We wanted to see the relation between pull request size and its life cycle duration. We discovered that PRs under 200 changes will get merged much faster, even twice as fast. And why is that? It's because small PRs are just more attractive. You will pick them up faster. You will be able to review them much faster. You will also review them much better because they are easier to review. And that will also impact your quality. With that, you'll be able to merge them a lot quicker and deliver the code a lot faster to production. Another interesting thing we discovered is that working and delivering small pull requests will also increase your deployment frequency, meaning that if you'll be able to split your work into smaller pieces, into small chunks, naturally, you'll deploy more releases. And in general, teams that are maintaining small pull request delivering approach has very low cycle time, which means they are performing in high speed. They are reaching to production faster and more frequently. Therefore, their developers has more impact on their customers all the time, which maintain their happiness as well. Now, how can you know what is your performance? You will have to start measuring these metrics. If you'll be able to measure them, you will also know whether you perform well or not. And you also know many more insights as well. Is your team suffers from bottlenecks? Is your team overloaded with tasks maybe? Are you planning your tasks properly and give the right estimated time for each task? These are crucial things for you to know because you want to maintain happy development pipeline in order to maintain happy developers and happy teams. In Linear B, we use our own product for measuring all these metrics, but you can always measure these using external plugins and APIs of your product tools that you are using, and you can always use spreadsheet and other tools instead. Now, let's say you already started measuring these metrics, and now you want to know what can you do in order to improve the process itself. Now, let's talk about the common delivery process. The typical development process, most of the dev teams and organizations share. You start by coding. You do your coding. You do your things there. You do some tests and unit tests. You have some checks in dev environments and your local environments, code formatting, and so on and so on. And after that, you are done. You open a pull request and wait for your review. This process might take a little while. You get comments. You resolve the comments. You fix some things and so on and so on. When you are done with the review process, you are able to merge your PR. Now, we are getting into the integration part, where you integrate your changes with the rest of the system. Sometimes you have integration phase before the merging, and sometimes you have it after the merging. And sometimes you even have the integration tests and process in both before the merging and after the merging. When you are done with this integration phase, you move to the deployment phase. You are now deploying your code changes to the real production environment, and you are done with the cycle. I know that there are many practices of the process and not all companies work the exact same way, but let's consider it as the most common delivery process. Let's get back to our metrics. Cycle time metric meets us along the whole process from the very first commit to the code is actually in production. There are many companies that have even more stages in their processes. For example, QA stage or beta stage, and there are far more many other stages there. So make sure you do these adjustments while you are measuring your cycle time. Other metrics are taking into consideration in other parts of the process, but how can we really speed up the whole process? One of our main goals is adding the group and development team is also to provide our teams and ourselves with the best development experience. We can achieve that by CINCD automated processes. CIN stands for continuous integration and CD stands for continuous deployment. CINCD approach made a revolution in the dev world years ago. For some of us, CINCD were a given concept for our very first job, but seniors developer in the crowd here can tell us they were not there always. CINCD created the integration and the deployment process into automated processes. If in the past we had to copy manually as the files from one server to another, now we are able to do it automatically. These processes not only increased our speed dramatically, but the lack of human mistakes and misconfiguration also improved the quality as well and makes it a lot safer to do these processes. If you haven't engaged any kind of tool for your CINCD, you should. There are many available tools for it in the market. For example, drone, Jenkins, CircleCI, GitHub actions and more. The thing is that they are not covering the whole process, the whole delivering process. There is still a gap, a gap that developers are suffering from in the beginning of the delivery process. If we'll zoom in into that part, the beginning of the process, we'll see the combination of that phase. Data shows that most of the time there, the most of the part of it, is actually counts as idle time. The time where the code changes are just waiting for a review, or the review already started, but it gets into a long loop of virtual discussion with you and your team members. This wasted time is happening mostly because of context switching, and it costs a lot of time as well as destruction. Even if you're working with small PRs, you might suffer from it. The developer suffers from idle time, and it's not always dependent on them. If we could add some automation layer for that part, the beginning of the process there, we could increase and speed up the whole process. The idea here is to understand that not all code changes you want to merge are the same. Not all pull requests act the same. You have PRs with only readme file changes. You have PRs that are considered as security label of the project changes. You have PRs of only images changes. Every PR has its own personality and can act differently when it comes to merging it. The continuous merge approach talks about categorize your PRs and give a route for every PR. Now, when you have this pull request categorization, you'll be able to add relevant automation, for example, auto merge or auto approve or even auto assign for a review and more and more. This automated layer will cover the beginning of the process and will increase the speed of your team. This is what we call CM, continuous merge, and with CIMCD will have the whole process covered. Continuous merge, it refers to the pull request life cycle of the software release delivery process and you can engage it in two ways. The first way is to get your PR more attractive in an automated way. You can send personal casting notification to the reviewers and you can also add more context into it. For example, estimated review time. The second way is to automatically categorize your PRs and add actions of automation after that. In our R&D group, we are doing dogfooding, so we are using our own product for that. We are able to get notifications as soon as the developer assigns us as reviewers. We also get more context. We get the estimated time this review might take us. In addition, if the PR is small enough, we can even approve it right away from Slack. So we don't have to do this context switch between multi-platforms. This whole thing helps us to reduce the middle part of the process. The review time is being reduced dramatically. And with that, we are managed to speed up the whole process of delivering. And in scale, if you are working with a group of developers, a big group of developers, it can save a lot of time there. In the market, there are many other tools for that as well and many plugins that you can use and engage to your pipeline. As for PR automation, we are using GitStream Platform for automated PR categorization. We are defining our reprovals in SCM file, and with that, we are able to define and automate actions that we want to perform on different kinds of PR. And all of these together along CINCD tools allow us to have a stable and healthy and happy pipeline, and provides us to focus more on coding and less on other things. Remember, when your development pipeline is happy, your developers are just happier. If you have any questions, feel free to send a direct message to me. I'm Evel Bel, also on LinkedIn. Thank you for listening to this session and have an awesome summit and a nice day. Bye, everyone.