Software engineering velocity is a metric that measures the amount of work a team completes during a sprint. But what do you do when you notice a development velocity problem at your company? I'll share my experiences in this post below.
You've implemented and have been following all of the “agile best practices”. You're doing retrospectives, daily standups, and sprint planning. Your engineers are spectacular, and you're using all the top-notch tools.
Despite this, you and your team often find yourself stuck in a project that takes too long to complete.
What may be the root cause of this?
You may not want to hear it, but here it goes: there's a high chance the fault is not to be found in a single source. It's not your engineers. Or your tools. It's definitely not in the remote nature of your company.
Instead, it's a set of interconnected elements that may be contributing to the slowness of your team or the quality of your products.
In this story, I'll try to share a few tips on how to get a better and more consistent velocity from your engineering team without overworking them.
As a CTO with years of experience managing teams of engineers, I have found that the issues I'll mention in the text are the most common when working on a development project. I'll share my experience of how we have handled these types of issues in our company.
Table of contents
Why Should We Care About Software Engineering Velocity?
Team leaders (or CTOs and Engineering Managers) should care about engineering team velocity because it's a perfect planning method. It can make delivery dates more predictable and allow the company to prioritize projects and milestones, and set customer/end-user expectations.
You can see velocity as a unit of work/time. The higher the number, the more milestones you can reach in a given amount of time.
Software engineering velocity is also an effective tool for detecting organizational inefficiencies. However, it's best if you don't use it as a sole tool for measuring overall engineering efficiency.
How Can We Detect a Velocity Problem?
The best way to identify engineering velocity issues is to look at the entire organization. Ask yourself the following questions:
- Are you getting plenty of interruptions, such as meetings, helping engineers, urgent code reviews, etc.?
- Do you often need to revisit requirements for more clarification (undefined edge cases, unexpected design issues, missing requirements, scope creep?)
- Are you missing any resources that can speed up development, such as documentation, clean code, better architecture, better tools, faster machines, etc.?
- Do you often have to delay progress due to another team or department?
- Are there any challenges that stem from a lack of consensus within your team? (loose or undefined architectural guidelines, not everyone on the same page, or conflicts about how something should be done?)
- Does the organization handicap engineering? (years-long backlog of tech debt, no time allotted to keep dependencies, unable to use new components/architecture, imbalance where too many juniors require more attention from few seniors/leads?)
- Can you notice a lack of motivation and engagement from engineers in your meetings?
- Does the team want to see the impact of their work?
What Can You Do?
Set Expectations
If engineers don't understand the scope of the work.
You expect everyone on the team to understand the big picture and what good code looks like. Failing to do so might result in burning cycles on unnecessary or useful work.
So, make sure you set expectations right with your engineers in terms of the scope and features of the project. Once everyone on the team has a clear understanding of the problem, they'll be better equipped to build the right thing, in the right way.
Test Rigorously
If you are faced with regular code errors.
For many strong companies, automated testing is a cornerstone of engineering processes. Engineering teams rely heavily on automated checks to inspect whether the software they're building meets the quality level that's expected by customers and stakeholders.
Automated testing can be regarded as an investment in preventing future unwanted and unexpected costs. By utilizing automated tests on every move, your team will be able to catch bugs and get rid of them before the software goes into production.
Even better, your engineers will finally have the mental room to focus on more important decisions than catching bugs.
Set Up a Fast Recovery Process
If bugs find their way into production.
The sad truth is that even if you have the best test suites in place, issues will inevitably find their way into production.
As there's a significant difference between mitigating an outage in five or fifty minutes, you and your team must be prepared for this scenario beforehand.
Having a fast recovery process in place is one of the most effective strategies for dealing with a broken software application or system.
In fact, many of the best companies such as Dropbox, Facebook, and Google have well-defined recovery processes such as assigning on-call engineers and runbooks.
One study conducted by Stripe found that many of these companies follow similar incident response processes. They decide to mitigate before they resolve.
Meaning, when an incident occurs, the on-call engineers mitigate the impact the incident is having on internal and external clients without even root-causing. Once the incident is mitigated, the engineers work to determine the root causes and then work on a solution.
Debugging is time-consuming, and it can be costly. Mitigating reduces the impact of the incident and saves the company a great deal of money.
Help Engineers See the Impact of Their Work
If engineers are unmotivated.
Software engineers want to do meaningful work. If they don't see the impact of their work, they may, in turn, become detached and disengaged.
If you want to motivate your team to give their 100%, you should lead in a way that helps them see the meaning of the value you're delivering.
For example, some companies have their engineers sit in a tech support chair to support customers. This can help developers understand how the product gets used by customers.
Even if it's just for a few weeks, seeing how people are using the product they've developed can be a huge boost to morale and motivation to do even better.
Organize Engineers Into Functional Teams
If there are regular conflicts.
In my experience, smaller sized teams of 4 to 7 members is the ideal team structure. If you're a larger company, hire the number of engineers you need and divide them into several small cross-functional teams led by a team lead.
It's more productive to have an independent team of five developers than a dysfunctional team of 10 that doesn't have context into what others are doing.
Each team can attend daily standups where they will share their work and discuss any existent conflicts.
Make Smaller Pull Requests
If engineers are bothered by complicated processes.
Break your work into smaller pieces to speed up your review time. Smaller pull requests are faster to review, push, and they can speed up the product development process.
On the other hand, large pull requests take longer to be reviewed and can demotivate the reviewer. Also, the larger the pull request, the less chance it will pass the initial code review, meaning it will need to go through several code reviews.
There's also the risk that the requirements will change before the code is released or halt other stories in the sprint and mess up the schedule.
This will cost plenty of money.
With that being said, a good pull request should not have more than 250 lines of code, although the number can vary from one team to another.
Find your team's optimal pull request size by doing experiments and keeping track of the changes in your velocity.
Key Takeaways
When project speed at your company goes slow, the easiest way is to blame it on the software engineers.
In reality, it's not that simple.
There can be a number of factors contributing to your slow velocity, starting from disengagement and unclear expectations to large pull requests and dysfunctional teams.
The first thing you want to do is get to the root cause of the problem. Once you find what's blocking your progress, you can continue implementing the needed measures to speed up your software engineering velocity.
You may be required to divide your sizable dysfunctional team of 10 into two teams of five engineers or implement more rigorous testing. In some cases, you may also need to establish a fast and reliable recovery process in place.
Hopefully, this post gave you clear and straightforward instructions on how to boost your team engineering velocity and ultimately manage to ship software with precision, speed, and quality.
