Velocity = Speed + Direction
One of the concepts I love about Agile is the idea of velocity.
When it comes to process improvement, I’m completely jealous of operations. They’re focused on creating a product that is almost always the same. To find ways to improve, they map the process and just start looking for bottlenecks. Experimentation is easy, look for small ways to test different approaches (you may have to try it on the full process, but you can test for a day or two and then change). Measurement is a matter of just looking at how many widgets get created, with even one or two percent improvements easy to detect.
Unfortunately, in project management each project is unique and generally 3-12 months. To start with, how do you focus on the right problems? When teams only design once every three months, how can you tell if they are taking the time to find innovative solutions or just spinning in circles? How do you experiment when the cycles are that long and different people on every team? And how do you measure a 10% change, much less 1%?
It’s one of the reasons I got excited about velocity in Agile. To start with instead of having one project that lasts 3 months, you break the project into smaller periods, which last 1-4 weeks called sprints. Instead of focusing on each phase of the project, you break projects into smaller tasks that can be delivered as a finished product.
That doesn’t fit all projects. I’m not going to build one square foot of a house from foundation to roof, and then start on the next square foot. However, it does work well for many projects in software, marketing, organizational design, or training. For example, creating marketing presentations, I might focus on finishing one slide, or in software, adding one feature.
But of the projects it does work on, the beauty of breaking a project up is that when you start to work on each of the pieces, those pieces follow the same steps. Instead of doing one big piece every six months, you start doing smaller pieces several times a month, and at times several times a week. That means your project starts to look like operations where you get to repeat. Each piece isn’t the same, but it’s far more similar than the full project.
To make things even more like that production line, Agile encourages having fixed teams. For example, if I have a software product (or a group of products), instead of changing out the team every time there is a request, I can see the work, and put one stable team together that handles all of these types of requests.
The advantage of smaller tasks and a fixed team include:
- Repetition helps teams get into a rhythm, so the team finds better ways to do each step of the task.
- There’s opportunity for experimentation. With similar tasks and teams, you don’t have to wait months to try something new and wonder if it worked or not.
- It provides a way to measure, as tasks start to look similar whatever project you’re on.
With a stable team and smaller tasks, velocity is a tool that lets teams measure what they’re doing. There are two options for putting it in place. The first is somewhat complex. You assign numbers to each task using a Fibonacci sequence. For example a small story could be a 1 for tiny, 2 for extra small and 3 for small. A medium might be a 5 or 8, and a large could be a 13, and then each sprint you add the total points for your sprint velocity.
Did I lose you? Like I said, it can get complex. Good news though. There’s a simpler method that captures about 90% of the benefit, and with a faction of the effort. You just keep tasks similar sizes, and then count how many you do in a sprint (yea, that’s it).
Either way, having work broken down and a way to measure it provides teams a way look for opportunities, experiment, and then measure. If they can get the work in front of an end user or audience, they can then measure not just how much work got done, but if it’s having the right impact (hence the speed and direction).
Just like any other metrics, you have to be very careful. The goal should be providing the team with a way to measure and improve how well they are working, not to help management punish teams (which will quickly breed issues) or try to compete between teams (stories generally will look different and you can focus on counting stories instead of delivering value).
The process isn’t perfect. The tasks will never be as similar as production and they will never be exactly the same size. But it’s close. Between the repetition and the ability to generally measure, it does provide teams with something most of us crave, a way to measure progress and focus on continual improvement.