Improving your team’s engineering velocity might seem like a daunting task. Velocity can be impacted by numerous non-obvious factors, many of which will relate to your developers’ workflows. The best way to get the full picture is by conducting regular, well-designed developer surveys. Finding and fixing these issues is a collaborative process: once you can identify what’s blocking your developers, you can discuss what processes and tooling might make their jobs easier.
How do you improve engineering velocity?
DevEx itself isn’t a direct measure of engineering velocity. However, there is a strong and studied correlation between good developer experience and high development velocity. The core tenets of DevEx promote productivity and efficiency, while reducing burnout. If you can maintain developer happiness and keep blockers at a minimum, you’ll start to notice shorter development lead times.
The short answer: focusing on DevEx is a key way to improve engineering velocity while simultaneously improving developers' quality of life.
How do I measure my team’s development velocity?
The de-facto way to measure your engineering org’s efficiency is by using DORA Metrics. DORA offers a relatively complete assessment: it can help you estimate your org’s overall stability with only four key metrics.
DORA relies on deployment data. You’ll pull data points from your source code management (SCM) provider and your incident management tools to estimate both velocity and reliability. It’s best to measure this data over several intervals, seeing if you can identify any major trends.
To get an extra quick estimate, you can plot your team’s story points against time intervals. This isn’t the most reliable way to measure velocity, but can suffice until you have a DORA measurement system in place.
How do I assess my org’s current DevEx?
In 2023, DX launched the DevEx framework. This framework is designed to help teams assess their org’s developer experience in both quantitative and qualitative terms. Getting this data helps you determine what needs to change in order to get better velocity and productivity, without the burnout.
The DevEx framework is a great, complete system for measuring developer experience. Part of what makes it so unique is that it directly targets DevEx itself, instead of adjacent factors or results of DevEx. The authors recommend orgs start measuring DevEx right away, even before landing on a formal assessment system/framework.
There are a couple of other effective ways to approximate DevEx (although less direct than DX’s):
Surveying your developers
Unlike engineering velocity, DevEx can’t really be determined through system data alone. Measuring DevEx is a collaborative process — after all, your developers need to reflect on their own workflows in order to provide useful information. Once they do that, together, you can identify what’s blocking them.
Setting DevEx and velocity benchmarks
Once you find a framework or measurement system that works for your team, you can start setting goals. It can be helpful to look at this from two sides: DevEx and development velocity. Since these can have a cause and effect relationship, it often makes sense to set velocity benchmarks first (see DORA). From there, you can work backwards to find where and how to finetune your DevEx. For many orgs, development velocity data will help illuminate any obvious DevEx gaps.
How do I improve my org’s DevEx?
Improving developer experience doesn’t have to be a huge undertaking. When taking the lead on DevEx, you can look at your devs’ biggest blockers (from your survey data) and start there. Chances are, there will be some achievable combination of technology and process changes for your org.
Keep meetings to a minimum
Meetings, while often necessary, aren’t conducive to developer productivity. For many devs, meetings are a serious interruption to flow — they divert focus and force devs to context switch.
When limiting meetings to only those that are value-add (e.g. planning, support, design, etc.), developers spend more time focusing on their deliverables. And when uninterrupted, developers are more likely to enter flow state, which might result in shorter lead times and higher quality code.
Good DevEx not only means fewer meetings, but also keeping meetings within designated time periods. Meetings should fall at the beginning or end of each workday in order to maximize uninterrupted working blocks.
Improve your documentation
When done right, your internal documentation should be a primary resource for developers, answering any of their major questions. Good documentation means that developers have the context they need to develop a feature efficiently and independently. DORA found that good internal docs have a direct link to organizational performance.
The hardest part of writing documentation is staying consistent. Since internal docs aren’t directly product-related, many dev teams end up putting doc writing/maintaining on the back burner. Docs are best written when a topic is top-of-mind, meaning that good docs are written during (or shortly after) development.
Assessing your current internal docs is a good way to find the weak points. DORA’s 2023 report offers a few statements to help assess the quality of your docs:
- I can rely on our technical documentation when I need to use or work with the services or applications I work on
- It is easy to find the right technical document when I need to understand something about the services or applications I work on
- Technical documentation is updated as changes are made
- When there’s an incident or problem that needs troubleshooting, I reach for the documentation
Invest in self-service infrastructure
Developers can better maintain their productivity when they’re enabled. When developers are blocked by other team members, they have to context switch, which can instantly kill their momentum. Instead, consider looking at your developer tooling and see if you can find any immediate pain points.
- Do developers have ownership of testing and CI/CD pipelines?
- Can developers deploy to ephemeral, testing, or staging environments?
- Do developers have access to all necessary microservices in your stack?
Developers should be able to do the majority of feature development independently (of course, this varies between orgs), keeping ops interventions at a minimum. Most importantly, developers should be able to test and deploy their code to a production-like environment on their own. Team members are only looped in when necessary: at code/design/product review checkpoints.
Survey your developers (again)
Just as you’ve conducted an initial DevEx assessment, it’s worth conducting that same survey on a monthly or quarterly basis. This way, you can track DevEx perceptions over time. Ideally, your DevEx improvement efforts should help this trend positive. And if it’s not hitting your benchmarks, you can check in with devs and get more specific feedback. Improving DevEx is a continuous effort and will take some trial and error to get results.
Atlassian offers some helpful tips for customizing a survey to your org.
Happy developers == quality software
We believe that improving software delivery starts with improving DevEx. You’ll see a positive trend in your DORA metrics when you start unblocking your engineers.
Giving developers access to self-service infrastructure is one of the easiest ways to boost velocity and shorten lead times. DevEx-centered tooling can keep developers in the inner loop longer — leading to better productivity and code quality.
With a tool like Shipyard, developers can provision full-stack environments for every branch and pull request. They can test and preview features on the spot, and see how their code changes might fare in production. Instead of dealing with bottlenecks and staging delays, developers can debug and iterate continuously until a feature is ready to ship.
Ask your developers how ephemeral environments might improve their workflows.
