4 Steps to Improve Velocity and Happiness

Velocity is the speed with which you're able to deliver value to your customers. While at first glance it might seem that this is a constant factor related to velocity of each engineer and the number of engineers, velocity can in fact increase or decrease for many reasons.

Good engineering teams track their velocity and work to increase it. These four steps helped us identify forces working for and against our velocity — we call them headwinds and tailwinds, respectively — and take actions to encourage the former and reduce the latter. As a bonus, many of the actions we took made our lives easier and reduced the time we had to spend on less interesting work.

  1. Track your time.

    No one likes tracking their time. It adds overhead and feels annoying. But it also provides value: you can see where your time goes, and decide whether it is going to the right purposes.

    We all do this naturally to some extent, but we may forget things or misperceive how long we actually spend on a task. So now and then, try tracking your time over an entire day for several days. Record when you start working on each task you do and when you switch to something else. You'll learn something.

    When I did that this spring, we identified a number of tasks we were performing that were not contributing to velocity. Some of them were necessary and could not be eliminated, but at least we had the chance to discuss them and get consensus on this. Others could be eliminated, which brings us to step 2.

  2. Identify and eliminate headwinds.

    Headwinds are forces working against your velocity. For example, we identified certain alerts from our automated logging tools as distractions that took up time and slowed velicty.

    Alerts are important and necessary for ops work, but it's not always easy to set their thresholds at the right level to eliminate all false positives yet not introduce any false negatives. We err on the side of caution, so we're always going to see some false positives. It's not apparent whether alerts are false positives when we receive them, so time goes into investigating them and evaluating whether they are a cause for concern or not -- time not spent working on new features.

    We found certain kinds of alerts were causing false positives repeatedly. It took some upfront work to identify and address the root causes, which also took away from velocity, but now that they're fixed and we never need to investigate them again, that time has effectively paid for itself.

    This had the additional benefit of reducing the risk of alarm fatigue, a condition in which too many alarms leads to them all being ignored, regardless of urgency or severity.

    By tracking your time, you'll identify headwinds, and once you do, share them with your team to get ideas on how to eliminate them. Then make it happen!

  3. Identify and encourage tailwinds.

    Tailwinds help us increase our velocity. For example, automation can be a tailwind. When you need to do something three or more times, consider automating it. Once or twice should usually be done manually, but after that, the cost of setting up the automation may be amortized enough that it becomes worth automating.

    We used to trigger our test suites manually before opening a pull request. It was too easy to forget to run the tests, or to forget to run the style checks as well. We started to use Travis CI, which has a hook to run the test suites automatically when a pull request is opened or a branch is merged to master. Travis never forgets.

    (Automating also has additional benefits: our machines were freed from the not insignificant memory and CPU burdens of running the test suite, and mentally, we were freed from wondering whether the tests had finished yet.)

    Tailwinds can be harder to identify than headwinds. Ask your team to think about them for a week, then discuss and decide which ones to adopt.

  4. Establish quarterly goals that include ways to improve our velocity.

    Velocity has forces working for and against it over time. Engineers become more knowledgeable and familiar with the code and their tools, but turnover can shake things up. reduce this. Bugs get fixed making persistent issues go away, but new code will inevitably introduce new bugs.

    Make the work of measuring and improving velocity visible. Get buy-in from everyone on the team. This will keep everyone aware of the issues so they can look out for opportunities to eliiminate headwinds and develop tailwinds.

    And it gives you a regular chance to re-evaluate how you're spending your time, identify headwinds and tailwinds, and decide what to do about them. It also provides a sense of accomplishment (and perhaps relief!) when you look back at the last quarter and think of the headwinds that are now gone and how much happier you are without them.