When working in the software industry it is very common to not know exactly what the finished product or feature should entail. Requirements might be fuzzy when starting out, the initial idea might turn out to be suboptimal and when dealing with clients… Well, clients change their minds about what they want all the freaking time! This inherent uncertainty gave way to the practices that we today call Agile. The gospel of agile has spread so much that every major software company is agile (or at least they say the are). Scrum, with its sprints, standups and scrum boards, seems to have become the de facto way of developing software today.1
One thing that I have been thinking a lot about lately though is the misuse of the word velocity. When most companies and teams say that they are measuring velocity they actually mean speed. This revelation was given to be when watching Kevlin Henney delivering his talk Agility ≠ Speed at Brewing Agile2 this fall. In this talk, Kevlin jokes about having a degree in physics and that Speed in normal terms is the same thing as Velocity, but in reality it is NOT the same thing. Velocity has a direction, speed does not. Using a linear system to measure progress, such as story points, means that you are measuring Speed. Not Velocity.
“It turns out, direction matters.”- Kevlin Henney
It turns out, direction matters. No, that was not a copy-paste error. In my mind this is one of the most important statements to keep in mind when creating a business, creating a piece of software, in product development or in any other field where people talk a lot about speed and time to market. Yes, if you are running late to a meeting speed is important. But if you are driving at 200 km/h in the wrong direction, you won't reach your destination any quicker than someone doing 100 km/h in the right direction. So, as it turns out, direction matters.
But what do you do when you don't have a clear destination? In the example with the meeting probably have the address, the floor the meeting is on and in some cases even the name of the conference room. As discussed in the beginning of this article this is usually not the case in software development. And when creating a business, particularly a business with an innovative business model, there are usually too many unknowns to say for certain where the company is going to end up.
What you need to achieve a high velocity in these areas is the ability to change direction quickly. The ability to set a short term goal, rush towards that goal and then stop to get your bearings. Once you have your bearings you set a new goal and rush towards that goal.
This is what the sprints in Scrum are supposed help the team with.3 At the beginning of the sprint, you set a goal, pull in work that will help you achieve this goal and then you sprint (work) for 2-4 weeks to in order to complete all the work that is supposed to get your team to achieve this goal and ultimately get you closer to the Big Goal (often world domination).
What I often see happening though is that the review part only deals with looking at what has been produced and not so much looking at how close we are to the Big Goal. And when the next sprint starts, the top tickets in the backlog mindlessly gets pulled into the sprint. The team looks at the velocity graph (which actually measures the speed) to get an understanding of how much work they are likely to get done in the sprint, but the sense of direction is often lost.
So why do we focus so little on the actual velocity and so much on the speed. Well… This is where it becomes a bit tricky. Speed is actually a key component. You have to move fast to be first to market. Facebook famously championed this idea with their old mantra, “Move fast and break things”. Even though the literal interpretation of this is too violent for my taste, this mantra still holds some wisdom. In my mind it's all about experimentation. Trying things to figure out what works and what doesn't and doing this so quickly that, occasionally, things break.
Experiment to move faster
Moving fast and breaking things through experimentation meant that Facebook could figure out the lay of the land quicker than their competitors and eventually achieve world domination. This does not mean that they were running at full speed at all times. That would just have had them running of a cliff faster than their competitors.4 What it really meant was that they could turn really quickly. The could try something and discard it if it didn't work.
Running a lot of experiments quickly also meant that they could take faster decisions. If something was not known they could run an experiment instead of assigning someone to investigate the idea before trying to build it. If it turned out to not give the results they were expecting they could shut it down. If it was a success, they could refine the idea and keep building on it.
In summary, the notion of making decisions quickly is where it all comes together for me. And in particular the ability to re-make or undo the decision quickly. In my mind this, together with a general speed, is the key to all successful people and companies. But it's not easy.
First and foremost it takes guts. You have to lay your fears of failing aside and realize that going in the wrong direction for a while is not an actual failure as long as you learn something from it and act on what you have learned. And you need to have guts to act now rather than waiting for the perfect plan to appear.
It also takes discipline. It's tempting to keep building on what you have just to get it done and hard to stop halfway through to throw it away if you realize you are building the wrong thing.
Finally it takes some creativity to realize that you are not necessarily choosing between A and B, but there could also be an option C that could be worth exploring with an experiment.
Rounding off this article I would like to talk a bit about why I chose to include General Patton and the F-16 in the opening question. Well, the discussion about making decisions brings to mind the following quote by General Patton:
“A good plan violently executed right now is far better than a perfect plan executed next week.”
The military has studied the art of decision making for ages, since standing still waiting for a decision literally is a question of life and death. The longer you wait, the more likely it is that the enemy will find you.
And what about the F-16? This one is actually quite easy. The F-16 was built with agility in mind and the reason for it being so successful in combat is not that it is bigger, faster and more heavily armed than its competitors. It is its ability to quickly change directions. Its (at the time) revolutionary design and fly-by-wire system meant that an F-16 pilot could change directions two times before the opponent's MiG had completed its first turn.
And there you have it! I hope the things in this article can make you think about how you make decisions and how you can turn quicker, be it in your scrum team, as a company leader or as a business developer.
This is entirely anecdotal and based on my own experiences as a consultant, consultant manager and owner of a consultant company. If you have any actual numbers on this, please send them to me at viktor (at) devies (dot) se. ↩
Brewing Agile is an annual two day Agile conference in Gothenburg. Disclosure: I am a former organizer and my company is still listed as an organizer. ↩
There are of course other motivations behind the sprints, but I'm keeping it short here to avoid turning this into a new Scrum Guide. ↩
Some would argue that this is precisely what they have done now, with their over optimized feed and the Cambridge Analytica scandal. ↩
After over a decade of building apps, teams and companies, I've now started coaching founders and CTOs through something that I call Nyblom-as-a-Service.
If this is something that would be interesting to you feel free to schedule a free discovery call to see if we are a good match for each other.