One of the challenges that organizations who are new to agile often face is a perceived loss of insight into their teams’ progress. After all, if an agile approach asks teams to forego the creation of a detailed upfront plan then how will that organization know if their teams are on track?
For many of these organizations, the obvious answer seems to be putting the focus on their teams’ velocity, also known as the number of story points completed each iteration. And why wouldn’t they do this? On the surface, velocity seems to be a perfect choice. It can serve as a proxy for the amount of work a team has completed in previous iterations, which at a high level, can serve as a rough approximation of the amount of work the team is likely to complete in future iterations.
However, there are two important caveats that organizations who are focused on velocity should bear in mind. The first is that velocity is, at best, a proxy for the amount of work a team has completed, not a direct measure of it. This is because velocity is a function of the total number of story points completed in an iteration. When used most effectively, story points are a representation of the estimated complexity involved in delivering a story, not an estimate of how long it will take to deliver that story. This means that velocity is more accurately described as the amount of complexity a team delivered in the previous iteration rather than the amount of work they performed.
The second caveat is to remember that software development is inherently a team sport, and therefore, velocity is most useful when it is considered at the team level versus the individual level. Sometimes organizations fall into the trap of attempting to measure the individual velocity of each member of the team in an attempt to gain insight into how each individual is performing. Not only does this approach tend to create perverse incentives across your team, such as pitting the members of your team against one another in an unending battle for points, but it also undermines one of the key traits often found in a high-performing team: collaboration.
Delivering a successful software product requires the efforts of the entire team as each member of the team is likely to bring different skills to the table. Since anything of significant value is very difficult to deliver without the efforts of the entire team it only makes sense to measure velocity at the team level.
But as much attention as velocity gets, it’s not the most important metric for an agile team. What’s more important than how fast your team can deliver value, you ask? It’s how predictably your team can deliver value.
A team that can deliver value quickly is ultimately only valuable if they can maintain that pace indefinitely. Conversely, a team who posts a high velocity one iteration, only to fall dramatically below that velocity over the next few iterations before suddenly returning to their previous pace, provides much less value for their organization since it becomes so difficult for their organization to know what to expect.
Higher velocities aren’t valuable if your team is unable to sustain them. For this reason, much of the emphasis of agile development is focused on increasing your team’s predictability, rather than their speed. The more predictable a team is, the more effectively that team’s organization can plan for the future. This improved ability to plan results in more realistic product strategies and enables more intelligent risk taking.
A great way to measure your team’s predictability is with the use of Hit Rate, which is simply the number of points your team delivered during the previous iteration divided by the number of points they forecasted. While some volatility is expected any time a new team comes together, or even when an existing team takes on a new project that’s significantly different than what they’ve worked on before, over time, you should expect to see a team’s Hit Rate stabilize to 1. By plotting this metric over time, you can see whether your team is becoming more predictable, or if they still have an opportunity to improve in this area.
Rather than focusing on velocity, teams should instead be focusing on improving their predictability.
The path to predictability never looks the same for any two teams, however, there are two traits that many teams who have achieved a high rate of predictability have in common. These traits are mature agile practices combined with stable and balanced teams. Let’s take each of these traits in turn.
It should come as no surprise, but most high-functioning predictable teams have developed a mature agile process within which they work. Whether it be Scrum, Kanban, or something in between, predictable teams have found the agile process that best enables them to work effectively while still providing plenty of room for innovation and experimentation. But rather than stop there, these teams also continually invest in improving their process to ensure that each iteration is better than the last. The result is a team who is not only delivering value in a repeatable manner, but one who is constantly improving their way of working as they do so.
Another trait often shared by predictable teams is a dedication to balanced and stable teams. These teams not only have all of the skills on the team necessary to deliver value, lessening their dependence on other teams, but they also are empowered to decide both the approach, and often the strategy, that’s most likely to deliver value to their customers. But the most important aspect of team composition that these teams share is that once these teams have found the composition that works for them, they’re permitted to maintain that composition for an indefinite amount of time. This increased stability allows the team to double down on their winning structure and make the most of their winning composition, compared to teams whose composition and resulting dynamics may change frequently.
By slowly incorporating the traits above any team can begin to remove the unknown that’s lurking in their delivery process. And by slowly removing that unknown, they will eventually achieve a higher, but more sustainable velocity. Because rather than focusing on velocity, if a team first focuses on predictability than eventually velocity will come.
Category: Productivity Updates Community
