Being really busy and working really hard = providing maximum value to the team, right? Well… While this obviously can be true, it can also be a comforting lie we tell ourselves without even realising it.
If you’re working flat out all week but not completing any deliverables (whether they’re for a client or to another member of your team), then you have a high speed, but you have a low velocity.
In scientific terms, the difference between speed and velocity is that speed is how fast something is moving, and velocity is how fast something is moving in a particular direction. So if an object is going round in circles, it doesn’t matter how great its speed is, its net velocity is still 0.
The same is true when we talk about speed and velocity in terms of workplace productivity. Being really busy with meetings, taking on too many small unimportant tasks or spending all day doing a triage of our email inboxes can lead you to feel like you’re being a lot more productive than you really are. This can as true for teams as it is for individuals (especially when it comes to meetings!).
So, how can we as agile teams, ensure that we’re optimising for velocity and not simply turning up the speed?
As my colleague Lee wrote in his piece ‘Agility over agile,’ Agile works best in situations of change. We should always be looking to improve our agile practices and tweak our agile rhythm to improve the flow of work, rather than staying wedded to one particular Agile methodology.
This state of constant agile experimentation and tinkering needs to have meritocratic outputs. Otherwise, we get trapped in the same problem of choosing the agile practices that make us feel the most productive (high speed) rather than those that truly make us the most productive (high velocity). This can be achieved by starting to quantify our agile practice.
If your team practices time-tracking then you already have some data to work with, and if you’re estimating time to completion for each task, then even better. As well as enabling better planning, estimation & time-tracking lets you compare perceived size of task with the actual time taken. This means teams and individuals can identify the areas of work that are taking longer than expected, allowing them to react accordingly by introducing a new way of working or changing the way another is done.
Many of the tools we use to communicate with our team also have metrics we can track. When using an instant messenger such as Slack or MS Teams it can be useful to monitor the percentage of messages sent via open public channels with those sent through private channels or via direct messages. This allows you to quantify a team’s openness, emotional safety and commitment to generating ambient awareness. Using a bot to broadcast this metric to the team is a great reminder
There are also several different ways of measuring velocity itself, when working with a Kanban system we can divide completed tasks by time spent to get a rough figure, this can be made more precise by breaking our tasks down into their smallest component parts. At the end of the day, the exact method you chose to measure isn’t the key thing, measuring consistently, and using that data to identify weak spots in your team’s agile practice is what really matters.
Calculating velocity and quantifying work done are two of the topics covered in today’s links, along with an exploration into what makes estimation for agile teams fundamentally difficult, and some tips for improving personal velocity.
- Agility over agile – the case for letting your agile system grow and change.
- How the abstraction of story points can improve your agile estimation.
- Measuring the velocity of an agile team.
- The problem with agile estimation, and how the factory model can help us. [Video]
- How saying ‘No,’ can improve your personal velocity.