The mechanics of software engineering teams

This article defines a few terms, borrowed wholly from Newtonian mechanics, to define a framework for thinking about how software engineering teams operate.

Newton’s framework for describing motion in the physical world is an elegant and simple system that can be translated with some ease to more general usage, and I find it a helpful and surprisingly accurate abstraction framework for exploring the behaviour of the complex systems that we call teams.

Just as Newton’s framework is a large scale simplification of processes operating at a much smaller scale (atoms, electrons, and quantum mechanics), so too does this framework entirely hide the underlying small-scale processes of personalities, product backlogs, meetings, bugs, service outages and the like, which at a micro level inform software delivery.

Nonetheless, I still find it a helpful way to think about how my teams operate, and I share it in the hope that others will too.

Mass

The constituent parts of what makes a team. The team members, the processes they adopt, their psychological view of what is and isn’t important, their understanding of the goal, the amount of code they maintain etc.

Direction

What the team is aiming to accomplish, a clearly defined end goal and well mapped-out ways to achieve it.

Distance

The quantity of work accomplished or to be accomplished en route to the destination.

Time

In my system, this means the same thing that it always means - but we will probably measure it in workday days rather than seconds.

Speed

How quickly the team is delivering new features. Defined as distance divided by time. There is no measure of direction in this - and we should remember that a team going very fast in circles is ultimately getting nowhere.

Velocity

How quickly the team is delivering new features aligned to the correct direction.

Acceleration

How quickly the team can change velocity. Note that in Newtonian mechanics, as here, acceleration means slowing down or changing direction, as much as it means increasing speed.

Force

The effort being expended to effect change within a group. How much management (and team members) have to push for something to happen, rather than it happening effortlessly.

Momentum

The mass that the team has, multiplied by its current velocity. Primarily a measure of how difficult acceleration is. Momentum will carry a team forward in the same direction, without the need for force.

These simple definitions give us some interesting relationships which I believe hold true. For example, remember that:

Force = Mass x Acceleration

Or equivalently:

Acceleration = Force / Mass

From this, we see that a team's ability to change velocity will decrease with the size and complexity of the team itself - its mass. Another way of stating this is that a team with little mass requires much less force to change quickly.

I will return to these metaphors in the future, as we examine the concept of momentum within teams - and how it opposes the concept of agility that is often discussed in relation to software engineering practices.