Thought I’d pick up a little of that sweet, sweet physics traffic with that title. FYI, you can increase your change in position or decrease your time.
Now that’s out of the way, this is a question that crops up every so often in different forms. I put it in the Scrum form, but it all basically boils down to, “How can I get my developers to move faster?” This is a timeless question that has answers that generally revolve around adding people, forcing overtime, or instituting measures to make sure they aren’t all secretly playing Galaga. I will contend, however, that if you really want more to get done more quickly, you’re asking the wrong question.
When you first start learning to play tennis, they don’t teach you how to hit the ball as hard as possible. You can always tell when your opponent has decided power is the most important thing to the game, because the ball ends up wedged in the fence, over the wall, out of bounds 80% of the time, and generally anywhere on the court except the places that would actually enable them to score points. But, boy, does it get there fast! Tennis Coaching 101 is to teach control and placement. Power follows as a logical consequence of easily and confidently putting the ball where it needs to go. A less powerful player with consistent placement will beat Johnny Randomcannon every single time. The key to greater power is greater consistency.
Instead of asking, “How can we go faster?” start by asking, “What keeps us from performing consistently?” If you don’t have a predictable flow, it’s very hard to know if you’re improving. If speed increases, but it’s unpredictable, who knows why you went faster? Who knows if you’ll be faster next week? Your results don’t mean anything because the variability is high. Although it may sound counter-intuitive or just plain distasteful, it is better to be slow and predictable than fast and unpredictable, at least in terms of getting work done. Obviously, the ultimate goal is to be fast and predictable, but one comes before the other. Just like you wouldn’t focus on power before precision, focusing on speed before predictability can end up with you all over the place except the targets you’re actually trying to hit.
In the first place, most businesses prefer predictability to speed, despite what they say. You can plan around predictability, even if the predictions aren’t what you’d like. You can’t plan off variability no matter how fast you are. If you offered most businesses a choice between a consistent amount of work delivered in a consistent time period versus a completely erratic delivery that could be much faster from time to time, they’ll pick the first one.
In the second place, there’s no way you can meaningfully measure if your improvements are helping if you’re already highly variable. To use a Scrum example (I feel so dirty), let’s say I deliver 5 story points one sprint, 18 the next sprint, and 10 the next sprint. My team decides on an improvement, and the next sprint, we deliver 14 story points. Did our improvement help? You have no freaking idea. If you take that same scenario, but the team’s deliveries were more like 12, 16, and 14, then the next sprint you delivered 18 or 20, the odds are pretty good that your improvement is helping, or at least not hurting.
But how do we reduce variability in software development? Isn’t it extremely variable? Well, yes it is, and I have found the practice of trying to get all deliverables to the same “size” to do more harm than good. It’s better to accept that some things will be big, some things will be small, and most things will gravitate to somewhere in the middle, relatively speaking. You can’t control that. What you can control is flow.
How fast does new work come to your team compared to how fast work gets delivered? How many things is your team trying to finish at one time? How often is something in progress stopped because of roadblocks? How often is something not in progress started because of whiplash priority changes? You can’t control the variability of what you have to deliver, but you do have quite a bit of control over the flow of these deliverables into and out of your team.
If you manage to flow instead of speed, the speed will come.