When thinking about quality vs. speed, it is essential to acknowledge that only in the short term, these two are somehow incompatible. In the long run, the quality helps a lot with speed and, specifically, with momentum. But it is also the other way around; momentum helps a lot with building default quality. The more I think about this, the more I realize that maybe momentum is the only thing that we should consider when thinking about the product, productivity, and teams.

What is momentum? #

I found a couple of article talking about momentum in the productivity context: one, two, three, four. Probably there are many more, but this is what I found on a simple search. While some of them have good recommendations for personal use, I did not find yet one that deeply analyses this from a team perspective.

I propose momentum as one of the essential qualities to watch while thinking about team productivity over the long run.

Defining momentum for team and individuals #

Momentum in the real world #

In physics momentum is defined as:

Momentum, product of the mass of a particle and its velocity . Momentum is a vector quantity; i.e., it has both magnitude and direction.

Yet, for what I am trying to explain here, I like more this definition from Merriam-Webster:

strength or force gained by motion or by a series of events

Scalars and vectors #

Before going into more details, let’s make one difference here between scalars and vector quantity:

A vector has magnitude and direction. Example of vectors in physics: acceleration, momentum
A scalar has the only size. Example of scalars in physics: volume, speed, mass, density

Velocity in physics vs. velocity in agile #

Velocity is defined in physics as “how fast and in what direction a point is moving.” Velocity in physics is a vector, thus providing magnitude and direction.

Velocity in Agile is defined as:

the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity.

In Agile velocity is a scalar. It does not show direction. It is just a magnitude.

One could argue (in Scrum, for example) that the direction is given by the fact that people are working toward building a product increment. I don’t think this holds because people are adding effort associated with completed user stories, but there is no way to understand if that effort is required for a particular user story. So there is no way to assess if the current amount of work done is in a specific direction while in the sprint. Only at the end of the sprint, one can understand if how much from what was done was in the required direction.

Another argument could be that direction is given by early feedback. While this indeed provides an arrow, it is not part of velocity. It is part of some agile processes to guide a team toward a goal with early feedback.

But in practice, one can observe that people count velocity as the total amount of effort spent in a period.

There might be ways to add direction to velocity, but I will try to argue further than focusing on the velocity. It is not a sustainable purpose in the long run, with all the possible corrections for matching the desired outcome.

Momentum is a specific type of vector #

A team having momentum is a team that:

keeps moving toward an outcome they desire
it is visible they are going into that direction
can keep this pacing without mental effort - seems effortless to continue.

In our case, momentum is a specific type of vector for productivity as it is not just a measure of where we are now and where we are going, but it is also a measure of the force that will continuously pull us into that direction.

I think you know this feeling of momentum:

it was that time when you said you are “on a roll.”
it was that time when you kept pushing code to production day after day
it was that series of sprints when you delivered the outcome and the customers where happy
it was that period when you had engaging conversations with your customers, and together you were building a great product without the hassle
it was those daily discussions which created the fantastic architecture/technical breakthrough
it was that time when in 5 minutes you finally wrote that function which took previous days hours to write and delete and then move on to write another one and another one

Why momentum is important #

The case against agile velocity #

As I explained above, velocity in agile implementations is a scalar, it is just a quantity, but this is not the only problem.

The big problem is that velocity is a subjective quantity while trying to appear objective. It does not help inside the team because it cannot be increased or decreased by themselves in any significant way and also cannot be compared with other teams as it is subjective. Change something about the team (structure, organization, technology). This metric will change. You will only see how significant the change is without having anything actionable from this number.

A second argument against measuring speed is that it creates the wrong incentive where any compromise is okay as long as it speeds up development. The wrong here is that people apply this only thinking about the present moment. So it sacrifices quality for speed. And in the future, when your app is bigger with more lines of code and more complex architecture, these compromises - actually technical debt - will act as a break.

There are many hidden forms of velocity #

Try not to let yourself tricked by the fact that people use some other metrics. Most of them are a quantity, and most of them are different forms of measuring a kind of length or speed when time is taken into account.

Here are some examples:

Number of stories implemented
Number of merge requests successfully merged
Number of tests passed
Number of bugs fixed (per area, per classification, per severity, per impact)
Number of releases

Divide by a time quantity (like daily, weekly), and you will get a kind of speed.

I am not saying that these metrics are wrong. I am arguing first that they are not very useful when thinking about creating value for customers/users. And more important that most of the time, they can very quickly become the single focus, thus affecting the decision process. I was too many times in meetings and discussions when one of these metrics, which in the beginning was introduced just as a no-judgment plain number, was taken into consideration as the most important thing.

It is happening when times are hard: something happened with the product/in the market, and suddenly people need to look into what happened and how they can improve the current situation. They remember that they were gathering these metrics (number of X) and start looking at them to usually find data to confirm a decision. This is how developers are usually feeling pushed to do more user stories or testers to execute more tests.

The value of momentum #

I think momentum is genuinely one of the best metrics to measure when thinking about productivity. True, it is hard to measure. Yet it is what makes the difference between a high-performing team and one that seems busy without producing a valuable outcome. For me, #momentum is precisely why the #agile #manifesto was created. To support teams/individuals to gain momentum and be able to make their creation happen.

How to measure momentum? #

Real ways, hard to measure #

Here is the most sincere way to measure momentum: ask the team. If you have a good relationship with the team, then you will know if they have momentum.

You can also watch how the team communicates blockers. If the blockers are inside team reach, then the team does not have momentum. If the blockers are outside team reach and they are a lot, then also the team does not have momentum.

You can also watch the team. Look at interactions, communication, communicating, how they are doing progress.

Other possibilities #

First: I think momentum is best measured when thinking about a team, not about an individual. Because at the individual level is can be very easy to go into focusing on wrong things (time spent while doing X)

Second: I think there should be different metrics based on the team’s particularities. Some teams need more data and react to that very well. Other teams need more guidance about the outcome than about the quantity of x done.

Third: Measuring momentum works only if the work can be split into small chunks. If the work cannot be split into small chunks, then it is tough to track momentum. In general, it is very hard to measure any outcome because there is a long delay between the team starts working and the moment that an outcome or business objective can be asserted.

It is tough to measure momentum. So bear with me while I try to explain how I think about it.

Blockers for momentum #

It is more comfortable to identify blockers for momentum. Here are some examples of blockers:

1. Meetings per day = how many meetings the team has per day. Add an extra weight when the meetings include participants from outside the team. Bigger is worse. I am here defining meeting as being asynchronous meeting where all attendees are required, and they need to be focused from start time to end time.

2. Decision queue = how many work items are waiting for decisions from people outside the team. Bigger is worse here. Having a lot of work items blocked by people outside the time is definitely one of the best ways to not have momentum.

3. The estimated dimension of work items = how long will probably take to implement a work item (requirement, user story, task). Momentum is not working when the progress is defined while taking into account periodicity bigger than days. It seems like splitting things into smaller pieces works wonders. See https://behavioralscientist.org/to-achieve-your-goals-lump-and-slice

4. Pressure to achieve quantities Whenever a team is pressured to achieve a number, they will focus on achieving the number, which creates a kind of mental pressure which kills the desired part of the momentum. One cannot have momentum while doing something they don’t agree with, or they find useless. Want to hear what most of developers or testers think when asked to count items of their work? They DO NOT LIKE this and usually are frustrated by this requirement.

Hints about momentum #

Then let’s thing about signs that you can see in your team, and they hint that maybe your team has momentum:

The flow of ideas = while talking about a specific issue, implementation, architecture, bug work team members are building upon each other ideas.
Focus on delivering = you can see this in many moments when a discussion tends to get too philosophical or too long that the team will correct themselves and focus on “What should we do to deliver this feature?”
Quality is built-in = this is when you see that the team does not need guidance or reminders about quality. They are doing progress and embed quality within.
Delegating anything extra for the future = the team is not rejecting changes or extra things because they are very focused on what they are doing, so no energy can be spent on fighting change. They are just delegating extra things for the future.
High interest in defining work items = While discussing next work items team gives valuable feedback about how to transform it so that it is implemented with good quality and customer satisfaction

Possible there are many many more signs than these. Again teams can differ a lot on how they “look like” when they are high-performing.

Thanks to Ciprian Hodorogea for reading drafts of this and giving me valuable feedback.