This article is the second in a series applying this framework to thinking about how software engineering teams operate and deliver.
One of the classic balancing acts that engineering leaders have to perform is that between building and maintaining momentum in team delivery, and maximising ability to change and innovate.
This article uses the framework, borrowed from Newtonian mechanics, that I previously outlined to describing the mechanics of software engineering teams.
Momentum is not speed
In physics, momentum is defined as the mass of something (how much of it there is) multiplied by its velocity (how fast it is moving in a given direction). When we think about engineering teams, we can apply this principle to the work that is being done and the outcomes that are being delivered.
If we take the analogy of a boat on water, we can understand that the larger the boat (the more team members and work items in flight), the more time and energy it can take to build up speed. If you strap a single motor onto a cruise liner, and another onto two-seater rowing boat, after a few minutes you will have very different speeds - but you will have the same momentum.
For a large mass of engineering (very large projects with many engineers and work streams), building up speed means building a lot of momentum. This takes a lot of time, a lot of energy, or both. And equally (and oppositely), same is true to bring things back to a halt.
It takes the same time and effort to lose momentum as it does to gain it.
Agility is about changing velocity
How can we define agility? If we think about our analogy of a boat, you might think of it as our ability to change direction quickly. But I would argue that it is instead best thought of as the ability to change velocity quickly - changing direction while maintaining speed. After all, changing direction without moving is essentially the same as doing nothing.
If we think of agility as our ability to quickly alter our velocity, we can see the application when thinking of engineering teams. Our ability to quickly change the short term or long term goal of a team, without sacrificing time or energy on reducing momentum, enables us to adapt quickly to a changing environment. That change might be one of many things:
- Navigating previously unseen obstacles
- Changing the path to respond to shifting terrain
- Or even changing our destination altogether.
By the way, in physics, change in velocity is better known by another term - acceleration.
Agility is our ability to accelerate.
To increase agility, reduce mass
Are you a Saturn V rocket? If, as a team, your goal is to fly in as straight a line as possible, along a pre-defined trajectory, to get to the Moon, in a closed system with no chance of external interference, then you have no need for agility. The best way you can spend your energy is in building as much momentum as needed to get you there.
But if there is any chance that the external world might change around you (competitive landscape), that you have imperfect knowledge of your path (research and experimentation) or that your destination might change (product development) then you will need agility.
Acceleration, remember, is force divided by mass. If you find yourself on a project where you can’t change velocity quickly, there are only two ways out:
- Massively increase the force that you apply, putting strain on your engine and risking burning it out.
- Reduce the mass that you are trying to shift, allowing the same force to result in greater acceleration.
Only one of these is sustainable.
To increase a team’s agility, you have to reduce its mass.
In my next article in this series, we will explore how teams can reduce mass.