Hans Ulrich Obrist once said that “everything I do is somehow connected to velocity”. We couldn’t agree more. As is in most companies, there’s always something affecting your team’s velocity, whether that’s a new work from home routine, a change in budget, or a variety of other reasons. So many influences are out of your control- how do you make sure that your devs are working at optimal velocity?
We did some research into the topic, reaching out to a few of our clients. We found out that they experience five significant causes to their drop in developer velocity. While many might seem commonplace, I assure you they are just as critical and should be taken care of as soon as possible in order to ensure your team is only moving up in terms of productivity and efficiency.
The stress of needing to meet deadlines is one known all too well. Getting deliverables in on time is no mean feat, and depending on the circumstances, can be near impossible. Whether you’re dealing with managing a remote team, personnel cuts, financial cuts, or a variety of other roadblocks, the stress is real.
Take it one step further, and who can think of improving velocity when they’re so focused on simply maintaining it? When your sole goal is to meet deadlines, figuring out ways to go above and beyond is far from top of mind.
So what’s the solution? Well, for starters, you need to pinpoint where exactly your team is wasting the most of their time. We recommend starting by asking your devs where their biggest time wasters are and then moving forward. Once you’ve dug deep and found the source of the pain, it’s time to find the right tools to fix it.
For example, one of our clients found that they were wasting a lot of time when debugging. Their devs were going through the whole deployment process over and over, waiting to set log lines, and then waiting to get the information they needed, hoping it was the right information in order to fix the bug that they were working on. Once they tended to this painfully repetitive process, their time to market accelerated dramatically.
Have you ever had that nightmare where someone is chasing you but you can only run away in slow motion? Well, sometimes developing software feels like that. Well, the stuck in slow motion part, not the crazy axe-murderer part. Nothing is more frustrating than feeling like you’re going nowhere fast, in terms of velocity. It’s even worse when it’s caused by slow-moving processes within the company.
Software development cycles can get quite lengthy. Whether you’re waiting for code approval, having to go through yet another CI/CD cycle (*yawn*), hit a deployment bottleneck, or a variety of other roadblocks, it can be agonizingly slow. Take deployments, for example. The more deployments you need, the more you find yourself stuck waiting for the deployment bottleneck to free up. So you sit back, sipping your coffee, waiting for your bottleneck to free up and wonder why these cycles sometimes take longer than writing the actual code in the first place.
Our clients wondered the same thing. They found that when they were troubleshooting their code it depended on adding log lines and waiting for several cycles or rebuild-test-redeploy. It was an extremely long process to go through every time they needed to troubleshoot and wasted a significant amount of their devs’ time.
It really doesn’t have to be this way, though. And no, we don’t mean that in the way they say it in cheesy rom-coms. Seriously. You can save yourself, and your devs, from being stuck in slow-moving cycles by separating the processes you need to move on from the rest of the development cycle. Imagine a world in which you can skip straight from setting breakpoints to getting the data you need to fix the issue you’re working on.
Sometimes, you’ll find that as a dev manager you’re working with limited firepower. No matter the circumstances, having the right devs, and enough of them, are critical to your team’s success. Yet, you can find yourself stuck in a difficult situation. If you need to hire new people in order to get more done, that means needing to onboard a ton of people, which necessitates a lot of time and resources that you don’t really have. And if you don’t hire the new people, well, it means trying to meet your goals with very limited firepower. Obviously, neither situation is ideal.
As one of our clients mentioned to us, they had realized that they weren’t utilizing their resources to maximum efficiency and that a significant amount of their developer’s time was spent researching production issues. They found a tool that helped their devs debug in production and ended up saving them about an hour or more on each bug, letting them focus instead on value-creating tasks.
Do what our clients did and avoid the choice altogether by doing more with less. Find the tools and methods that allow you to maximize the resources that you already have at your disposal, especially your developers. Some such tools are ones that help you to automate or reduce complexities in your code. Rather than having to figure out an onboarding process or attempt to work with limited resources, take full advantage of the tools you do have to ensure you don’t need to decide between either of those options.
Another cause for a reduction in velocity is the time and resources spent fixing bugs. You’ll find that much of your devs’ time is spent working on a bug instead of working on their new code or on creating new features. Debugging is essential to the well-oiled machine that is your software. However, it completely drains your developers time- 60%, to be exact- and thus reduces their velocity.
As anyone who has spent countless hours debugging, it’s not over even when you think it’s over. This can be seen with the definition of done, which states that being done is “when all conditions, or acceptance criteria, that a software product must satisfy are met and ready to be accepted by a user, customer, team, or consuming team”. No matter how you implement it, it means meeting every and all requirements in place by everyone using the software- no matter which end of it they find themselves on- to really be considered done. However, obtaining this level of finished product can require a massive investment of time, keeping your developers from focusing on other aspects of the product that need their attention as well.
So what can be done? Do you choose between a well-done product or let it become medium-rare in order to keep progressing? Instead, we recommend finding the tools and methods that get you the data you need, as soon as possible, in order to resolve bugs and reduce bug time to resolution. By freeing up your developers time spent working on bugs, they’ll have more time for everything else, including making sure your software is cooked to perfection.
A client of ours mentioned that they lacked suitable Lambda debugging tools. This was significantly slowing their development time for new features and extending the time required to push new fixes. They understood that they needed to find a way to help their devs debug - no matter what.
Data makes the world go ‘round. But often, your devs can be buried under the sheer amount of it. Data is needed in virtually every aspect of software development. Yet, that desperate need for it every step of the way causes devs to accumulate an overabundance of data that mainly creates noise and distraction in their code.
Oftentimes, as one of our clients found out, this excess of data can be generated by a phenomenon called Logging FOMO. This stands for the fear of missing out on log lines and the data they comprise. Your devs are so fearful of missing something that they set too many log lines in the hopes that one of them will bring them the data they need. However, these logs generate too much noise in the system, as well as high overhead costs to maintain the sheer number of logs they have set.
On the flipside, sometimes devs don’t write enough loglines, thus preventing them from getting the data point they need in order to move on and fix their problems. It’s a catch 22- but there’s a solution! Tools that help you to either shoot for the exact log needed, or let you log things after the fact, make the issue of too much data a non-issue.
While the going may be tough, it doesn’t mean that the tough need to get going. No matter the circumstances affecting your team’s velocity, there are a variety of solutions at the ready to help them improve their velocity. All of the above pains can be a mere memory with the right tools and methods. At Rookout, for example, we built a machine that allows developers to debug effortlessly, get the data they need instantly, and log anything anytime - even in prod. Identify your team’s soft spot and take the frustration away. There’s an app for that.