Are We Going Fast Enough?

How do we know how fast we should be able to go? After all, given the current circumstances, we’re going at exactly the right speed. That’s a tautology. But is there some small thing that’s holding us back, something that’s within our control?

When tracking progress over a significant period of time, it’s naive to think that the rate of accomplishment will remain constant. The only way that’s likely to happen is if someone is managing the data to make it look constant because they think that it will reflect better on them. (See ​Hiding Reality​.) Things change. People and teams of people cycle through better times and tougher times. On something as hard to measure as software development, even the measurement is unlikely to remain consistent over time. Expect uncertainty and learn to live with it.

In spite of the uncertainty, you can use this information to guide your exploration of what may be happening. Ask not only how fast have you been going, but how that rate has been changing. Look for trends and patterns. Don’t jump to assumptions about the competence, motivation, or individual performance of people. The more likely causes are systemic effects.

What are the components that affect changes in velocity? These lists are surely not complete, but they are some of the common contributors that I’ve seen.

Slowing Down

When the data tells you that work is slowing down, the first thing you should look for is bottlenecks in the process. Are work items building up at some stage in the process? A ​Cumulative Flow Diagram​ can make such a buildup obvious. Watching the flow of work items in a visual management tool can reveal bottlenecks just as well, if you look for them.

Also, check if the pressure to deliver is driving teams to leave technical debt in the code:

• The code diverges from clearly expressing the problem domain.

• Small messes get left behind for “someday” when there’s time to clean them up.

• Code gets more and more complex, and therefore harder and harder to expand and enhance.

• Duplication grows when there are areas that people are afraid to touch, or can’t easily know about as they’re writing code.

• Code gets harder to read, and therefore it takes longer to find where to change it and how the change should happen.

One of the key telltales of this situation is a rising bug count. If you have an honest relationship with the programmers, though, they can likely tell you about this. Some programmers may not be aware of techniques of keeping code well-factored with lots of easily rearranged modules instead of a few rigid ones.

As the bug reports come in, at some point effort needs to be spent addressing them. This points out hidden undoneness of the functionality that’s been shipped so far. It wasn’t really completed as it didn’t do everything expected of it. You might not have discovered these deficiencies at the time, so you congratulated yourself on completing the functionality. Now, going back to complete it is taking away from your capacity to implement new functionality. If you’re not careful, this can lead to a runaway spiral of less and less completion plus more and more bugs.

Maybe the work environment has become less conducive to working together. There may be increased friction in communicating information and ideas between people. Or unrelated noise is distracting people. Perhaps an increase in the number of people working on the project has increased the number of relationships and communication paths beyond what can be handled. Maybe the communication has become more point-to-point rather than many-to-many among the group.

Could it be that changes in the oversight or evaluation of the group is causing them to do more overhead work at the expense of development? Are there more reports? Is there more fear of blame, resulting in more CYA documentation that eats away at the team capacity? Is micromanagement interrupting the flow of work?

Perhaps you’ve been doing the easier work to make a good show of progress and have deferred the harder or riskier work until now. Or maybe you’re just counting your progress in larger units of work. Maybe you’re estimating more optimistically? It could be that your unit of measurement has changed more than your rate of doing work.

Speeding Up

If things seem to be speeding up, perhaps you’re getting better at what you’re doing. It’s relatively rare that you get better at programming in a time short enough to be a noticeable productivity boost, but it’s possible. Maybe you’ve all learned some clever techniques from each other and that’s boosted your output. Or you’ve become better at working together as a group, gaining synergy from the best skills of each person combining into a group effort.

Sometimes teams start off with a lot of speculative framework development. If they guessed right about their needs, then maybe it’s paying off now. Conversely, perhaps they’ve started postponing the hard work until later, creating a false sense of progress. Could they be taking shortcuts that will later show up as technical debt, unfinished functionality, and bugs?

Or maybe it’s an illusion of measurement. It could be the team has gotten better at splitting User Stories, and are counting smaller units of work. Or maybe, having been burned before, they’re now estimating more pessimistically. This is especially likely to be true if there is pressure to increase velocity.

Oscillating

If rate of accomplishment seems to be alternately speeding up and slowing down, then it could be that the development team is correcting based on feedback that is delayed. Systems engineering shows that delays in a feedback loop result in a late start to correction and subsequent overcorrection, causing oscillations. The delay in feedback can be external, or it can be created within the team’s work system. For example, if the work items take longer than the measurement interval, the feedback on accomplishments gets delayed until the next measurement interval. Reducing the size of the work items will help the data reflect reality more clearly.

It could also be that the division of work is inconsistent in sizing. Or that estimation is haphazard. Either would affect your data measurement. It might also be that there is noise in the collection of the data. Or that frequent perturbations in the team makeup or environment make a steady pace impossible.

None of these patterns are necessarily indicators of a problem, but it’s definitely good to notice the variability of velocity if you’re projecting it into the future.