.svg){kind=icon}
.svg){kind=icon}
.svg){kind=icon}
Get your free ebook
To begin, it’s important to distinguish between velocity and performance in the context of software development. They are similar, but not the same.
Velocity is primarily concerned with the amount of work that can be done per sprint, while performance focuses on doing said work faster, more efficiently.
However, it is team velocity that makes or breaks the success of your product.
High performance often contributes greatly to high velocity, but it doesn’t guarantee it. If you have too many tasks to deliver in a sprint, yet you do deliver them after all, your quality will likely suffer, since you’re going to have to work faster to complete them.
Velocity is all about providing the value without sacrificing the quality—good planning and good delivery. If speed comes with lower quality, is it really worth it? No, it’s not.
That is why in this article, we’ll focus on velocity over performance; quality over speed.
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:
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:
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:
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:
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.
Of course, we would be remiss not to consider the dire financial situation the global economy currently finds itself in. We may be in the middle of the greatest crisis of this millennium, but you still have software to develop, don’t you?
So, the million-dollar question here is: what should you be focusing on the most if you’re running out of money? After all, optimizing your budget doesn’t automatically mean optimizing your velocity—or at least it doesn’t have to.
This is what I would recommend:
If they were to change jobs now, it would hurt you. Badly.
This cannot be stressed enough, especially now, when going in the right direction with your development is imperative. It’s also possible a business pivot lies ahead for you, in which case you’ll be lost without a PO.
You’ll be working with a much smaller budget for a while. Suspend all inessential investments. Squeeze as much as you can out of what you have. Work only on the priorities. Drop all nice-to-haves.
With the way things are going, nobody knows what the world will be like a month from now. Prepare for the worst. Use situational context in your planning all the time. Know for sure what you want to build and focus on just that.
Remember what we said about giving and getting feedback? Normally, you do it face to face, at your office. You may not be able to meet your developers in person right now, but that doesn’t mean the feedback should stop. Offer value the same way you were offering value before, even if you have to rely on substitutes. Every gesture counts, no matter how small. Don’t forget we’re all in this together.
One last thing I’d like to mention is that you can’t improve what you don’t measure. Work on hard data and use specific criteria to assess how your team is doing today. Then compare the results with how you’d want them to be doing in the future.
Once you do that, you’ll have the complete picture of your current software development velocity—and what you should do to increase it. After reading this article, you should also know how to go about it.
If you’d like, we can help you with that by conducting discovery workshops or adding new members to your team quickly and reliably. We can even build your whole product for you if that’s what you need.
.png)
.png){kind=small}