In Agile development, and in Rapid Learning Cycles, the cadence is the heartbeat of the project. A regular cadence keeps the team moving forward together, just like the drummers keep a marching band in step.
Faster isn’t always better. A piece of music may have been written with a particular cadence in mind, but if the musicians are missing notes, the piece will sound better at a slower cadence. How do you know which cadence is best for you?
Every time a meeting or event happens, there is a fixed cost, known as the transaction cost. For instance, sprint-end activities are part of the transaction cost of a sprint. This transaction cost is incurred again for every sprint, so it adds up over time. A faster cadence (or shorter sprint) means more total transaction cost.
However, there is also a cost to not having the meeting or event. This is called the holding cost: the cost of holding back information or product and not getting any benefit from it. A longer sprint means that feedback from customer demos is “held”. The value doesn’t arrive until the sprint ends. A slower cadence costs the business money, by creating feedback, rework, and lost opportunity.
So fast costs money, and slow costs money… where’s the sweet spot? The least expensive cadence is the cadence with the lowest total cost. That’s the sum of the transaction cost plus the holding cost. The optimal cadence is just fast enough but not any faster. The fastest cadence may not be the least expensive!
This is particularly obvious in the case of continuous integration in software. Each integration requires multiple build and test steps. If those are not fully automated, or test results must be interpreted manually, the transaction cost of each integration is significant. That can add up over time. On the other hand, the value of each integration lies in the conflicts and errors found by that integration. Delaying delivery of that information increases the holding cost. As the cadence increases, at at some point the total transaction cost will exceed the holding cost. An even faster cadence will simply make things worse. Continuous isn’t always the optimal answer.
When the transaction cost far outstrips the holding cost, the first thing to do is dial back the cadence. If that raises the holding cost unacceptably – for instance, useful information is delayed too much – then the team’s only option is to reduce the transaction cost. This might take some significant work. Musicians must practice and practice in order to play well at a faster cadence. A software team may need to put some significant time into automating test or build steps in order to reduce their transaction cost enough to increase their cadence.
This trade-off between holding cost and transaction cost can be modeled mathematically, and it’s pretty easy to follow with a few diagrams. If you’d like to see the math, you’ll probably like this post: Cadence in Agile Projects: Sprint Length, Integration Frequency, and Other Matters of Rhythm