3 steps to make your development team more productive
How often have you invested in optimizations or tools to help out your ability to ship high-quality code faster? Are you able to calculate the ROI of these improvements? Do you know which metrics to observe to validate these gains in speed and quality?
To answer these questions we must understand how code development impacts the DevOps cycle. For example, adding automated tests can slow the delivery pipeline if done incorrectly thus hindering developers’ productivity.
This article proposes 3 steps to ensure changes to your development pipeline produce gains in productivity.
Adopt Trunk-Based Development
To start seeing gains in productivity, your team needs to put in place Trunk-Based Development which allows you to ship from the main branch at any time. Some goals of this approach are to avoid maintaining multiple branches, ease the integration of new features and if done properly, provide teams with the flexibility of choosing which changes to release.
Yes, shipping faster also means your quality discipline needs to mature otherwise you’re stacking technical debt faster. Thankfully, breaking down the size of your releases not only increases your release speed but since the changes to review are now smaller, it eases the review load on developers whilst allowing them to inject quality more efficiently. Capital One’s Focusing on the DevOps Pipeline goes a bit more in-depth on the types of DevOps pipelines.
Now, if your team is already accustomed to the principles of TBD then skip to Measure Productivity Improvement Investments. If not, you can ask these questions to your team to understand what impacts their ability to ship code from the main branch:
- How often do you push local code to your remote repository?
- What is your typical commit size, in lines of code?
- How many atomic commits do you push in each Pull Request?
- How often do you merge your changes to the main branch?
- Are you satisfied with your ability to push code to the main branch?
- What aspects of the development cycle impact your ability to push code to the main branch?
- Which aspects of the development cycle should be improved first to help you push code to the main branch?
These questions will help determine your teams’ pain points to push code to the trunk and also help prioritize which solutions to implement. The twist is that you need to gather data first to know which pain point is real and ensuring the solution’s ROI can be determined.
Measure Productivity Improvement Investments
Now that you have provided the ability to developers to quickly ship code you need to start measuring the healthiness of your DevOps pipeline. To guide you in this journey you need to wonder if you are currently able to quantitatively measure the average wait time before a pull request gets its first review? Or the number of bugs your tests didn’t catch? If not, do you still resort to increasing the number of repositories since you want to break down your monoliths? Or because there are bugs still being found in production the consensus in your team is to add more tests?
Do you see the irony? Adding more of something that hasn’t been proven to work won’t solve your problems. Therefore, how can you increase productivity if you don’t measure the ROI of the efforts spent on your process to make it ship high-quality changes fast?
First, you need to position yourself on the performer’s table.
Let’s assume you are a medium performer and want to transition to the elite group and that you need to increase your lead time to get there. How do you go about figuring out which part of the development journey to improve? By surveying the team. This way you’ll know where your team wishes to invest and where they feel the most pain.
For example, your company enforces the use of a specific IDE, and this, in turn, makes developers unhappy since it does not integrate well with third-party code versioning tools. How do you prove to the company that it may be worth adopting different tools? By backing the arguments with data.
This is where I say invest in data gathering before implementing solutions that impact productivity. Recently, a framework was suggested to help gather this type of data. SPACE is a framework built by researchers who focused on increasing productivity for big-tech companies. Below is an example of how SPACE was used to identify metrics that helped measure the productivity of performing code reviews:
Create a continuous improvement loop driven by metrics
With the DORA4 and SPACE metrics, you can now define metrics corresponding to a development activity to monitor their productivity. Furthermore, you can use these metrics to identify if an effort to improve the DevOps pipeline increased productivity or not.
One approach to monitoring more efficiently the health of the DevOps pipeline is to set thresholds after understanding the data presented. You can also color-code or create a heatmap to make metrics actionable. In other words, it is easy for a team to know which metric is unhealthy and proactively improve it whilst getting direct feedback about how their changes impacted productivity.
Needless to say, if the team being considered for those productivity improvements is too busy to make those changes happen, it is recommended to create a Developer Productivity Engineering team that will act as a service, provide tooling, etc. Think of it as an SRE team but for productivity. This team can monitor the aforementioned metrics and jump in to help the teams that require attention.
Changing the culture in a team is difficult even if it’s for their benefit. By surveying first to surface pain points and then gathering its respective productivity metrics, you can continuously improve your development journey all the while calculating the ROI of new productivity improvements.