One of the fundamental tools in Agile and Lean is cadence.  A cadence is a regular, predictable rhythm within a process.  For instance, your staff meeting is held every Monday at 10am, or your website is refreshed every 4th Tuesday. Agile sprints are another example of cadence.

A regular, predictable cadence saves time by reducing time spent scheduling, and by “clumping” work together.  You know when your staff meeting will be, so you hold issues until that meeting and do them all at once, rather than addressing each issue individually with a flurry of emails or a special meeting.

However, a regularly occurring meeting can be too often – or not often enough.  How do you know which cadence is best?

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” – you can’t get it 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 sum of transaction cost plus holding cost. Basically, the 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. When build or test is not fully automated, or manual interpretation of test results is needed, or the check-in process involves manual steps, the transaction cost of each integration is not zero, and it adds up over time. The value of that integration is the conflicts that integration finds, and you don’t want to delay those. But is there enough value in having those results hourly to justify the cost of an hourly integration? Sometimes not.

When the transaction cost far outstrips the holding cost, the best thing to do is to first dial back the cadence. If that creates too much delay in getting useful information, put some serious effort into reducing the transaction cost before going back to a more frequent cadence.

This 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

Once you understand the math, you usually needn’t actually calculate the holding cost and transaction cost.  Simply being able to think about the tradeoffs is often enough to identify when your cadence is far from optimal.