How to Increase Your Software Development Velocity—Even During an Economic Slowdown

Velocity doesn’t happen in a vacuum. It’s a result of a number of factors you need to have in place beforehand. This is especially true for repeatable processes.

Without rock-solid, tried-and-tested, ready-made solutions, you won’t be able to build a high-velocity development team.

Just to name a few examples, such practices include:

• employee onboarding and offboarding,
• knowledge transfer,
• responsibility handover.

Developer turnover is one of the biggest challenges businesses on the IT market face today. Before a newly hired engineer becomes an integral part of your team and gets a good sense of the work you’re doing, you might lose too much time to meet your deadlines—and you never know when the next one will leave.

Codified processes prepared ahead of time are a great way to cut down the time spent on rotation. Have as many of them as you can and use them whenever possible. Here are several examples:

• switch out your developers in stages to give yourself ample time for knowledge transfer;
• pay attention to product documentation;
• record your product demos and training sessions,
• don’t neglect unit testing, since it’s the best way to document your project;
• automate your deployment using Docker or containers to avoid wasting time on environment setup when the exiting developer is still on the project and their knowledge can be used otherwise.

Balanced team composition is an essential step to improving your software development velocity. Without balance, your productivity will suffer.

If your team is too “strong”—meaning, if you have too many senior developers on it—you will end up with endless debates over whose approach is the right one and solutions that are too complex for simple problems.

Conversely, a team that is too “weak,” with a majority of junior developers, won’t get much done, because they’ll lack the skills necessary to solve the many inevitable problems along the way.

Also, having just regular developers on your team isn’t a good approach either, since they may not have what it takes to overcome some of the challenges that require a senior touch.

What is the most optimal team composition, then? If your goal is to have six developers on your team, we recommend picking two seniors, two regulars, and two juniors.

Regardless of the exact nature of your project, your sprints will include various tasks at various levels of difficulty—and all those tasks will need to get done. Some of them will be too easy for seniors, but perfect for juniors; others will be so complex that only seniors will be able to handle them.

A mixed team keeps all members engaged in the work and gives them equal opportunities to grow. The underrated side effect of this is that it keeps your turnover rates low.

Distributed team composition also gives seniors a chance to share their expertise with juniors and teach them new things. This helps the seniors practice and retain their skills, while also giving them deeper satisfaction than simply getting tasks done. In the process, morale of the whole team goes up. When your team members can learn from each other, everyone is better off for it.

Feedback is a great tool for improving team velocity, but only if it’s done right. Giving or receiving both positive and negative feedback is actually much harder than it may seem.

The main problem is honesty. Feedback is only helpful if it’s honest. Concealing your true feelings, using euphemisms, and worst of all outright lying about what you think will likely backfire and hurt you instead of helping you.

False feedback can often be a direct consequence of a nation’s culture. We see this often, especially with businesses from the UK, where politeness is greatly valued.

Let’s say your team commits to a number of tasks in a sprint. They don’t meet their own commitment, deliver only 60% of the tasks, and offer up some lame excuse why that is the case, without even putting in the effort to explain themselves.

Say your reaction to that is, “Oh, that’s fine, guys, great job all the same, I’m sure you’ll do better next time!” Do you honestly believe you’re doing them or yourself a favor, when deep down you’re furious about burning time and money for nothing?

Business isn’t about being nice. Business is about getting results. Software development is no exception.

Of course, you shouldn’t do the opposite and be mean or abusive toward your team members. But good feedback isn’t always good feedback. You need to be honest about how you feel, even if that means disappointment or anxiety. Sometimes, you need to shake up an underperforming team by reminding them of their responsibilities.

One good practice is to be upfront about your expectations from the start. Let your team get to know the real you on day one: this is me, this is what I want to see, these are my values, my work ethic, how I operate. You know the “carrot and stick” approach? Well, there’s a reason it’s both, not just one or the other.

Remember that being open about feedback is a challenge in itself. It requires emotional intelligence, effort, empathy. It’s a skill you constantly need to work on, not a box to check on a to-do list. Also, make sure you ask for feedback as often as you give it. This is a two-way street. It doesn’t work otherwise.

Development and deployment are not two separate stages of getting your product to the market. Don’t devote too much attention to one and not enough to the other.

The two need to work hand in hand to ensure your product finds its way to production as quickly as possible. One week of really fast development won’t mean a thing if it takes a month to deliver the code and a full quarter to deploy it.

Delivering value to the end users is one of the greatest software development challenges these days. That is why DevOps is the key to high velocity. Continuous integration and deployment are the make-it-or-break-it factors in how fast you can use the work your team has already completed.

Here are some good practices:

• use trunk-based development to avoid merge hell,
• rely on automated processes that you keep improving with people,
• deploy often and in small chunks,
• treat fixing broken builds as your top priority,
• automate your unit testing dependably.

Good Product Owners offer you real business value. Having one on your development team is a must—even at the expense of one of your developers—if you want to increase your velocity.

Above all else, Product Owners are the guardians of two of the most important rules of software development:

1. Good is good enough. Done is better than perfect.
2. It doesn’t matter how fast you’re going, if you’re going in the wrong direction.

Like we said before, velocity isn’t about speed. It’s not about closing as many tasks as possible within a single sprint. Rather, it’s about focusing on doing the tasks that actually need to get done.

A dedicated Product Owner takes care of the backlog, makes sure the expectations are clear, and serves as the single point of contact between you and your team. After each sprint, you’ll learn what works and what doesn’t, saving time and money in the process.

The Product Owner’s work is the key to high velocity, and even a single poorly planned sprint will result in setbacks. Your Product Owner will filter priorities, assign tasks in the order of importance, and realistically plan out what should be done and what could be done.

If you’re only at the beginning of your software development journey, consider building an MVP before taking a deep dive into end-to-end development of your whole product.

Over my many years of managing service delivery, I’ve found that end users typically use only around 20% of any product. It makes sense, then, to plan your workload so that you develop that 20% first.

With proper roadmapping coordinated by a skilled Product Owner, combined with diligent business analysis, you will cut down your time to market significantly by getting 100% work done on the 20% product. But that’s not the end of the story.

One of the key benefits of building an MVP is that you get to perfect your product vision and verify the market potential of your product. You also get to estimate the development costs accurately and specify your core target audience.

In order to achieve those goals and more, I strongly recommend going through discovery workshops.

The discovery approach will help you understand the challenges ahead of you, build a robust roadmap, and define the MVP to get the best results.

Regular discovery session catch-ups are also a smart practice to implement once you move past the MVP and onto developing your project fully, so that you can compare and contrast the performance of your product with your business expectations. To make sure you’re on the right track, repeating the sessions quarterly is a good benchmark.

Excessive dependencies always have a negative impact on your software development velocity.

These days, large businesses often work with multiple teams from multiple countries, each team developing a separate part of their product. While this doesn’t necessarily have to pose a problem in itself, the downside is that these teams usually depend on one another to deliver their commitments, sometimes sprint to sprint. When one team falls behind schedule, the others soon follow, slowing the entire development down.

Again, this doesn’t have to be a deal-breaker if time is not of the essence to you. But how many companies can honestly afford such a luxury? Few at best.

With tasks distributed all over the world, deployment on schedule may not be possible. The best way to avoid such delays is to limit the number of task dependencies.

Even though we’re a software house ourselves, we’re not going to pretend we don’t know that vendors often cause dependencies. If you have constant access to the same talent in-house, it might work better for you.

But if you choose a reliable software house, they will do everything in their power to keep your project moving, because your success is their success.