Have you ever felt that your team wasn't reaching its full potential? That pushing features into production led to many bugs the next week or that your pull requests were always hanging for days? Do you feel that changing practices in your team might worsen its state? As an engineer, you know that objective observations and factual metrics are the only way to see if you are better now than before. Look no further; I will show you how you can leverage metrics like DORA and others to bring changes and experiment with new practices in your team.
The pain
Humans change when the impact of changing is less frustrating than not changing. Humans follow this basic rule of entropy. We tend to be in the state that requires the least energy, and software development teams are no different. With that in mind, why would a team change its engineering practices? Let's take a look at some classic pain points that push teams to change:
Working on bugs is no fun; no one should be happy to let bugs loose every time they add a feature. Have you wasted an entire day on a stupid bug that could have been caught with a good review or some basic testing? In my experience, it's always the most obvious that takes the most time to find.
Deploying manually is a tedious and time-consuming task. Waiting for files to transfer or download, following a procedure written two years ago for the 100th time. Deploying by hand is just not a fun task to do, and it wastes so much time. If deploying takes your team 30 minutes every week, it means that you could take 20 hours to figure out a way to do it automatically, and it would cost less over a year and you and your team doesn't have to think about it anymore.
Are your pull requests getting stuck in your Git repository for weeks on end? When you finally receive the review you've been waiting for, do you find yourself struggling to remember what you did? And then, to make matters worse, your colleague asks you to practically redo everything you've done. This can be one of the most frustrating situations. You thought you were done with the task, only to find yourself back at square one. After redoing the work, you'll still need to pick up where you left off on the next task.
All those pain points could cause you and your team to change their practices so you no longer have to re-live those situations. Here is where metrics help you determine which pain is the most present and if your changes is actually improving the situation. For those who do not have those kinds of problems, you should still consider measuring your team performance so you can prevent deterioration in your team practices.
Metrics
Let's start with some of the most basic metrics. The DORA metrics. Those metrics came from DevOps Research and Assessment. This is an organization created by Google to assess the difference between an elite team and a low-performing team in the industry. The four principal metrics are as follow:
Yes, there is now a fifth metric, reliability, but this metric is primarily an extension of time to restore service and is more difficult to measure.
The DORA metrics are great for evaluating your team's performance, but they could be better when trying to figure out what your team's problems are. That is why most analytics services come with other metrics like
- Time investment (How much time do you invest in bug vs. story vs. Refactoring)
- Cycle time (How much time does an item pass in progress vs. in QA vs. in Staging)
- Throughput (Number of items done / week)
- Service level expectation (Time it takes for a single item to be done)
- Work in progress (average of items in progress at the same time)
- Self-reviewed pull requests (this one is pretty obvious)
Those metrics could point you toward some of the problems your team may experience.
Finally, let's talk about another key set of metrics: how your team feels. This aspect of the process is often less considered because it can be difficult to measure. However, some metric services can help you keep track of your team's morale. This is important because change can create stress and uncertainty in teams, and if you want to successfully improve your team, you will need their help and collaboration. Therefore, you will need to make sure they are not stressed, motivated, and that they feel included in the team.
Now what
Now that you have the metrics and have found a way to obtain them, it's time to use them to analyze and improve your team's performance. What can you do to improve your team? My suggestion, take a moment with your team, take a look at the metrics, and find out what is wrong. Maybe your work in progress is five times bigger then your team, meaning that each and every one of you is juggling five issues at a time. Ask yourself, is this normal? Does it have a consequence on something else? I can't say whether having a work in progress that is five times larger than your team is good or bad for your team, but you and your team are in the best position to assess the situation and understand the true meaning of the metrics (Five times is probably too much tho). By discussing with your team, you may agree that juggling five issues at a time lead to poor code quality, which is why your change failure rate is so high. Maybe you have five issues open at a time because no one wants to review them. Maybe no one wants to review because your pull requests are too big. In short, looking at your metrics will start discussions that will benefit everyone.
The most important thing about those discussions is that you need to set objectives and plan how to make the change you need. What is really cool with metrics is that you will be able to follow your progression with them. However, do not fall into the trap of setting hard goals. What I mean is, if you want to be an elite team in deployment frequency, you could just deploy something every day, but if each deployment leads to bugs, it doesn't make you an elite team in change failure rate. In your journey through measuring performance, you will sooner or later realize that improving in some categories may cause your team to worsen in others. The important thing is to keep in mind that you are measuring yourself to avoid the pain points I mentioned above. In other words, your team needs to find a process that requires the least energy to maintain. In other words, you need to follow the basic principle of entropy!
You can get in touch with me via Linkedin!
Feel free to comment about your experience!
Top comments (0)