In this article, we'll go through the definition of developer velocity, explain how it's measured, and offer tips on improving it.
In the software development world, speed is essential.
Users will turn to your competitors if you can’t make products or offer services quickly enough.
However, you also shouldn’t sacrifice quality while aiming for speed—your users should get value, or, you guessed it, they’ll turn to your competitors.
Developer velocity reflects the amount of work your developers can do in a particular time frame. Improving that can boost your results, as well as customer satisfaction.
Table of contents
Managing technical debt better
When developers aim for a speedy delivery, a frequent consequence is technical debt. How you manage it can significantly impact developer velocity.
The term technical debt, as you probably know, has many definitions, and it’s often used as an umbrella term for everything developers leave behind that needs to be fixed later—legacy code, bugs, missing documentation, etc.
Here’s how Trey Huffine explains it:
In other words, a developer sacrifices writing perfect code to deliver it faster, and someone has to manage the aftermath sooner or later.
And that can impact developer velocity because it wastes a lot of developers’ time.
According to The Developer Coefficient report by Stripe, out of 41 work week hours, developers spend 13,5 hours dealing with technical debt—slightly over 33%.
And it’s difficult to produce quantity and quality when a third of your time is spent on fixing bad coding practices.
The key to managing technical debt is not to let it grow. It’s a good idea that your developers abide by the boy scout rule that Robert C. Martin applied to the world of software development.
Alexandre Omeyer expressed it like this:
That simply means that a developer should deal with a small piece of technical debt when they come across it before it starts to weigh down the code base and impact the velocity of the whole team.
However, over time, some larger technical debt is likely to accumulate. When that happens, you can use software tools like code linters to manage it successfully.
A code linter analyzes your code to check for mistakes and bad code practices and ensures a consistent coding style.
For instance, a good open-source option is CSS Lint. It’s simple, customizable, and works in a browser.
Code linters can also catch bugs, which is undeniably a useful feature.
However, what’s even better is a more robust and automated solution like Shake for dealing with bugs.
Shake is our own product that helps developers reduce time spent on dealing with bugs by providing them with a comprehensive bug report with all the information needed to fix the issue.
When a user notices a bug, they shake the phone, and Shake creates a report, attaches data, images, video, etc., and sends it to a developer.
That way, a developer gets everything at once and doesn’t have to dig for more information. They can get ahead of technical debt and prevent bugs from becoming a part of it.
Developers can be under pressure to deliver the work quickly, even at the price of cutting corners. If you efficiently manage technical debt, that will be much less of a problem.
Retrospectives are one of the integral parts of agile methodology and for a good reason. Among their benefits is also the positive impact they have on developer velocity.
During a retrospective, a team can assess how the sprint went—what was good, what wasn’t, and what they can do to improve for the next.
What does that have to do with developer velocity? Well, the valuable insight the team gathers can significantly improve their work process and practices and, in short, improve the team.
And that means they can deliver higher-quality work in less time.
A report from CA Technologies indicates those benefits of retrospectives—teams that practice them are more consistent and responsive, producing more quality work.
Of course, for a retrospective to have a positive effect like that, it should be structured with purpose and care.
Take a look at the picture below that points out some of the crucial elements.
Let’s examine what those elements you should pay attention to are.
As you can see, there are three main questions at the heart of a good retrospective—how was work, what was good, and what could be improved.
That’s the variation on the questions we mentioned earlier, but the point is still the same.
The important factor is also to set aside enough time for a retrospective and to have every team member present whenever possible.
A good retrospective should result in self-analysis, analysis of the issues during a sprint, and presentation of improvements that can be made.
Experts like Ben Linders, who is an author and tech coach, also describe retrospectives similarly.
You can use software tools to help you conduct retrospectives, especially if your team, or a part of it, is remote.
Retrium is a great tool with several features designed for retrospectives.
For instance, it offers a What Went Well template, which facilitates the method we mentioned earlier—examining the process and brainstorming ideas to improve it.
It also has a feature that Chris Brookins, the former Chief Product Officer and VP of Engineering of HelpScout, described as very helpful for even better retrospectives—while writing their feedback and impressions, employees can’t see what others have written until everyone is finished.
That way, the feedback everyone gives isn’t influenced by others, which contributes to the impact of the retrospective.
Reviewing work is essential for improving developer velocity. You can’t expect someone to be faster and better if they don’t know what to do to improve.
Retrospectives can provide such answers.
Using repeatable processes
Achieving velocity is easier when you have true and tested repeatable processes in place. That way, you can use less time and effort on them and use them when needed.
Think of it this way—when you prepare various solutions for multiple situations, you and your developers can just reach for them and know that they’ll provide results.
There is no reinventing the wheel every time.
You can apply that mindset right from the start of your developers’ journey—the onboarding phase.
An excellent onboarding process can be prepared and repeatedly used for every new developer, and it can greatly impact velocity.
Kristen Buchanan, founder, and CEO of Edify, is straightforward about it:
Many companies realize the importance of onboarding and have repeatable processes ready whenever they hire someone new.
One of them is Canva, a company that built a popular graphic design platform.
They have a highly structured approach to onboarding, ensuring that developers get up to speed quickly and increasing the team’s velocity.
According to Linda Lin, their People Operations Lead, it wasn’t always like that. They had a few ad hoc onboarding sessions that weren’t the same for everyone.
As the company grew, they realized the importance of repeatable processes and how that would improve the efficiency and speed of the team.
Now they have a process that lasts from one month before the first day on the job to 6 months after it.
As you can see, their onboarding process contains clear stages and instructions for each.
Of course, they have a lot of prepared material, like the message they send to mentors every time, along with important documents and reminders.
You can improve developer velocity by creating repeatable processes as Canva did.
If you imagine how long it would take to prepare everything from scratch every time a new hire comes in, it’s clear that with this method, developers can start working at their maximum capacity much sooner.
Another element you can prepare and reuse that can benefit the whole team is product documentation.
Good product documentation for software developers provides them with a central place where they have all the information they need, from style guides to dependencies, testing documents, and anything else.
A great tool like Archbee for creating and storing documentation can make all the difference.
In addition to using it for all kinds of documentation, you can easily edit files, keep them updated, and always have them ready for developers to use.
That can free their time up for more challenging work instead of digging through multiple sources for the needed information.
In conclusion, repeatable processes make it easier for developers to focus on the work and deliver quality results in less time. Investing some time and effort into establishing them can go a long way.
Having product owners
Product owners have responsibilities that, if honored successfully, can considerably contribute to developer velocity.
In simple terms, we can describe the role of a product owner as someone whose job is to prioritize tasks, oversee developers’ work, and ensure that the team does what it needs to do to deliver value and quality.
Here is how ProductPlan envisions a product owner’s responsibilities.
As you can see, a product owner should have the vision and the plan for the product in mind, manage the backlog, define stories and be a communication link between developers and stakeholders.
Because of those responsibilities, product owners have an interest in overseeing and improving developer velocity—a good plan and careful prioritizing can make a lot of difference regarding developers’ results and the team delivering the work on time.
Furthermore, an important part of a product owner’s job is planning and reviewing sprints.
Even one poorly planned sprint can negatively impact developer velocity by giving them unrealistic expectations for a particular time period.
That can lead to issues with a backlog—a list of prioritized tasks that should be completed in the project.
Below, you can see how a backlog contains requirements within sprints.
If a product owner is skilled in planning those, they can improve developer velocity by creating an environment in which developers can succeed.
Organizing a backlog is great for long- and short-term planning by presenting the big picture and the next steps in the schedule.
A product owner can use helpful tools to make that easier for them and the developers.
It organizes the backlog so it’s more user-centric, gives a coherent view across the project, and a product owner can more easily plan what can be released and when.
For a more long-term type of planning, product owners can use roadmaps, a plan of how a product will evolve over time.
A tool like Dragonboat can be very useful for that.
Among its features, there is roadmapping, portfolio planning, auto-tracking, etc.
In other words, solutions like that can improve developer velocity by simplifying the work of a product owner and providing them a better chance of successfully planning time and resources, leading to a better and speedier work process.
Dependencies are inevitable in projects, but they can be limited. If you manage to do that, you can boost developer velocity.
There are many ways dependencies can occur in software development—basically, any time one thing needs to happen before the other, there is a dependency.
For example, when one developer writes a piece of code and another developer tests it, there is a dependency—there is no testing of a code before someone writes it.
Therefore, if you don’t limit dependencies, they can build up and make increasingly complex situations that can result in wasting more time.
According to agile consultant Mike Cottmeyer, that can be especially detrimental to agile teams who value velocity.
It’s not surprising that waiting and time-wasting negatively affect developer velocity. Therefore, to improve it, you should limit dependencies as much as possible.
A great way to do that is to have a cross-functional team.
The fact that they have members with different skill sets is a big benefit, as they can complete a task without waiting for another team to do their part.
As you can see in the diagram above, a cross-functional team can, for example, have developers, testers, and system analysts.
That means they can work quickly because there are two fewer teams in the process and two fewer opportunities for dependencies to occur.
The tech giant Cisco has used cross-functional teams to its advantage since 2001.
They reorganized that year in an attempt to break free of the silo culture, as their former CEO John T. Chambers said.
“Our teams working at different levels are cross-functional in nature. This has lent Cisco speed, scale, flexibility, and rapid replication.”
Your company might not be the size of Cisco, but that doesn’t mean that managing dependencies isn’t vital.
You can make a big difference in results when developer velocity is high.
In doing that, you can use various tools to define and analyze dependencies in order to limit them.
The Connections map pictured above shows how the cards on the Kanban board are related.
There are also icons that, for example, show if the card is blocked from moving because of some external dependency.
Dependencies will happen from time to time, but if you do what it takes to limit them, their influence on developer velocity can be minimized—and that’s worth the effort.
Improving developer velocity is likely the goal of most tech companies, but it’s not easy to achieve.
You should lay the groundwork to provide your developers with the best possible environment in which they can thrive, produce fast, and produce well.
You can do that by managing technical debt, doing retrospectives, establishing repeatable processes, having product owners, and limiting dependencies.
We hope this article helps you with that—it can make a better experience for your developers, your users, and you as well.