In Newtonian mechanics, the degree of acceleration is proportional to the force and inversely proportional to the mass:
Acceleration = Force / Mass
We talked previously about how software teams that are looking to be agile should shed mass. Our definition of agility is perhaps the inverse of momentum:
Agility = 1 / Mass
Therefore, to increase our agility, we must either decrease our mass, or decrease our velocity. If we do this, it will affect our acceleration accordingly:
Mass = 1 / Agility Acceleration = Force x Agility
Increasing our agility will increase our acceleration under a constant force.
Increasing agility
As we previously discussed, we can wholesale apply many of these concepts usefully to describe the behaviour of teams. Here is our definition of 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.
This can be hard to reduce. One way is to do so is to break teams into smaller units. Another is to remove processes or responsibilities that are no longer needed. Another is to remove team members. But the benefit is that we become more nimble, and will accelerate faster without the need for additional force.
Increasing force
Per our definitions, remember that force is:
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.
From Newtonian mechanics, also recall that:
Work = Force x Distance
Force is how much we are pushing, and the work we do depends on the distance we have to travel while maintaining that force. Work is a form of energy transfer - accumulating work consumes energy, and so it is something we want to minimise. Unnecessary expenditure of energy will exhaust our reserves (of team goodwill, physical resources, and our own physical and mental energy).
Increasing force will accelerate our delivery. But it also is work - and consumes energy. We should only do it when we know that the path we are traveling along is along the shortest path to our goal.
Reducing mass
The rolling stone gathers no moss. But the productive team will accumulate mass over time - like a gravitational well sucking value and detritus in, without any regard for the difference between the two. Teams that are well established for a long time will develop processes and responsibilities for a great many things. To reduce the mass of these teams, you have several options:
Cast unneeded things adrift
Services that are no longer business critical should be suspended. Codebases that are unmaintained should be archived and alerts and monitoring of them disabled. Documentation should be kept slim and free of clutter. Cut back on complexity and you will reduce team mass.
Split into smaller parts
Unlike cruise liners, teams are made of modular parts - systems, people and processes. If you want teams with smaller mass, consider breaking them up. You might pull a few engineers into a single lightweight team who can move quickly without distraction. You might adapt better Team Topologies so that smaller teams are driving towards simpler goals.
Cut the red tape
Processes are mass. Meetings, Jira statuses, review requirements. All these things add mass and inertia to how a team operates. If you want to be Agile, put people before processes and cast them aside.
Conclusions
If our goal is to accelerate our team, we can remove mass (and increase agility) or we can increase force. Which one to choose depends on how well known the path to our target is, and whether we anticipate the need for course corrections en route.
Next time, we will talk about when momentum is a good thing.