Working smarter is better than working harder - How to increase velocity

"Why is progress slow? Why does everything have to take so freakin' long? You have to push harder! Work more."

This is something that I've heard a lot, especially from certain types of managers. Let’s look at this more closely, and what it means, and what it is an expression of.

I think it is reasonable to assume that it’s not a matter of the manager actually wanting people to work harder, faster or more just for the sake of doing so. No, instead I think (I might be naive ;-)) that it indicates the manager’s wish to have stuff done sooner. "Stuff done sooner", that is key here. Can this really be done without having people work harder/more? Yes! If you work smarter!

The time that something takes to complete (from its very start, to the time that it is ready) is called “Cycle Time”. You can learn a lot more about this if you study Lean Software Development, I won’t go much further into details here.

Let's investigate what factors affect Cycle Time. How “hard” people work is one factor, yes absolutely. At least up to the point where negative stress kicks in and its consequences appear; defects and demoralization, lacks in communication, loss of cooperation and team synergy effects, and many other ugly things.

At this point I could dive into Value Stream analysis, talk about Value Stream Maps and discuss how to apply the Lean Software Development tools supplied by Mary and Tom Poppendieck et al. But I won’t do that now. In this blog post I will limit myself to only the “implementation part” of the development process. You should know that there is a lot more room for shortening “Cycle Time” than what I will talk about below. With Lean and its tools you should go far beyond only the sprints and observe the steps before and after implementation and focus on the whole chain – the entire “value stream” that flows through your business.

So, back to the subject. In Scrum we continuously measure at least a part of the Cycle Time: We measure velocity. The velocity is the speed with which the team finish things, according to your Definition of Done. Velocity is measured in “Story Points”. You can observe it over a sprint (SP/sprint) or over man-days (SP/manday), or variations of this sort. The point is that you measure the velocity in a consistent way, and you record your findings (in something that I call “the Velocity Log”).

If you say you want to shorten your Cycle Time, i.e. shorten the time it takes to finish something, then what you really want to do is increase your velocity. The bitch here is that the velocity is not something that you can tune by itself. It’s not a knob that you crank up and voila stuff goes faster. The velocity is a result of the environment in which you work. By changing the work environment you will change the velocity. It doesn’t work the other way around. Sorry.

I think we generally need to be much more focused on “helping” the velocity up. It is easy to stare oneself blind on a deadline and all the stuff that has to be done by then, dig in and spend all energy on completing those stories. during such times I think we often forget, or at least seriously underestimate, the power of improving the work environment and the effect it would have on the velocity. This is what "Continuous Improvement" is all about.

Now, what does “work environment” mean?

Unplanned items. They happen all the time, during your sprint and are typically part of your work environment. These are the things which you for some reason just have to do, but that you really shouldn’t (because the team’s job is really to work on the sprint backlog). These are those “negative additions/changes” to your sprint. They affect your team’s ability to focus on the sprint commitment. What you want to do is record your unplanned stuff by putting a note in your “Unplanned”-section on the Scrum Board, for everyone to see. Then you need to work on removing the source of those unplanned items. In my opinion, unplanned items is the number 1 opportunity to increase velocity. Find the root-cause of every unplanned item, and consider if you can’t insert a task into your Impediment Backlog about removing that root-cause. Either way, it is the Scrum Master’s and the Scrum Product Owner’s number one priority to shield the team from these things so that the team is allowed to focus 100% on the sprint backlog.

Concentration breakers: Email. What can I say. As a communication tool it is great, but the way email has been integrated into our daily life is not. If you get a “You’ve got mail!” dialog every time you receive one then your concentration will be broken as many times a day as the number of emails you get. Some days I get hundreds of emails. Jeez! If I was a developer today I would consider not checking my email more than once or twice during the day, and have the client shut down in between. In a Scrum team we rely on face-to-face communication more than written stuff anyway, so believe me, the really important stuff will reach you anyway without you automatically checking your email every minute. And get used to the fact that if you want someone something, then you need to walk over to them and speak to them face to face instead of writing an email.

Concentration breakers: Skype. It is indeed a great tool. In our company we rely a lot on short-lived Skype group chats that we create for various purposes, and we use it a lot for internal communication. It’s a great way of communicating and cooperating. But it can also be a huge concentration breaker. Skype announces new messages by popping up a new window (in the background), with a system tray popup and/or by coloring the chat window taskbar button orange. So every time you receive a message (personal or in a group chat) your concentration will be broken. I guess you learn how to ignore this after a while, but I’m pretty sure that ability is individual. My advice: be careful if you’re using Skype. I suggest killing it altogether and rely on face-to-face communication instead. If you decide to go that route though, make sure it’s a team decision and not enforced as a policy or company rule.

Concentration breakers: Background noise. We work in an open office landscape with very few closed offices. Most of the people sit next to each other in that landscape in order to promote cooperation and communication. The clear drawback with an open office landscape is the noise level from people talking, writing, from computers buzzing and so on. If you’re a manager reading this: don’t be a cheap moron. Invest in sound absorbing cubicle dividers, even if they are more expensive than regular ones (or compared to not buying any dividers at all). If there’s one thing that directly affects the concentration of every single person in the open office landscape – all day, every day! – it is the background noise level. Yes, we can always ask everyone to talk quietly and step into a meeting room for those longer discussions. But also consider: how much are you crippling freedom of communication (and cooperation) by not buying those sound absorbing dividers? It is a low cost for ensuring optimal work environment! While on the subject: seriously consider installing roof- and wall-mounted sound absorbents too.

Unnecessary manual work. Stop and reflect: are there any tasks/actions that you perform often which could be partially or completely automated? Even if the effort of automating it is somewhat large (maybe several days or even weeks of work to build automation or refine tools), it might be worth it in the end. Is it only you that have to do this manual task every time? Maybe it is every developer. 5 minutes a day, for every developer in a 25 person organization, equals 45 man-hours every month. Consider automating many of those manual tasks, and optimize the efficiency of those that you can’t completely automate. If you think about it I’m sure you can come up with a bunch of things. Have a workshop. List stuff and prioritize. I’m sure your Scrum Product Owner will listen if you run the numbers. If you have tips on tasks that can be automated, please feel free and add them as comments to this blog post!

Technical debt. The higher technical debt you have the longer things will take. The system is more complex, harder to test, things are harder to implement, and so on. Addressing technical debt is a subject on its own, which I will come back to in later blog posts. For now I'll just advise you to keep in mind that it directly affects your velocity. You should do what you can to (at the very least) immediately stop increasing your technical debt even further, by letting it take longer to do things "right". It is a short term investment for a long term gain. The bad approach is to do it the quick and dirty way. Remember: the dirty remains long after the quick has been forgotten.


So, if you think progress is too slow, consider working smarter instead of harder. It has a much bigger impact on your cycle time than crunch and overtime has. I really hate crunch. And in so does everyone. Trying to continuously improve the work environment and thereby increasing velocity should be way up high on your agenda! That is how you get things finished sooner, without killing yourself and without sacrificing quality.

I would appriciate comments on your tips and tricks and experiences regarding how to increase velocity!