When fortnightly forums feel like a fail
When a squad looks to establish an iterative delivery pattern, regardless of whether they follow the Scrum framework or not, the typical ‘default’ cadence is to operate on a two-week cycle. For many teams, especially in the early phases, this feels like the right balance of ‘doing’ and ‘inspecting’ and forces a lot of positive conversations about how best to self-organise quickly.
However, after a few cycles there is a chance that those forteen days feels ‘off’, somehow. It could be that your standups are not adding value when the work isn’t flowing on a daily basis. It could even be that your team has moved on from events that occurred even a week prior, listing that as ‘old news’. If you feel like your sprints are running too fast, or too slow, you want to change and adapt.
But how do you go about the task of cadence adjustment without causing too much disruption throughout the experimentation process? Is there a guiding principle that can help us make informed choices early on? Thankfully, there is, and of all places we have electrical engineering to thank.
Summon science to secure success in your squad
Switching gears for a second, imagine the sound made by a bird as it chirps out in the wild. If you wanted to represent that signal on paper you’d probably use a frequency chart, measuring the sound waves over time. Now imagine we want to convert that bird’s call into a sound we can store on our computer, digitally. To do so we would need to ‘sample’ the bird’s call a certain number of times per second to get a semi-realistic portrayal of the original sound.
To know how many times we want to take said sample we want to follow Nyquist’s Theorem, which states that in order to reliably reconstruct an analog signal (i.e. the bird’s call) into a digital format we must sample at a rate greater than twice the highest frequency of that original signal.
In other words, if the bird’s call had a frequency of 1 seconds (or it took 1 seconds for the bird to repeat itself), then we want to sample the signal every 0.499 seconds at least, if not faster to make a faithful representation of the original bird call. In a perfect system we would want to take samples as often as we can (think infinitely quickly), however this would be inefficient as we know the exercise of sample collection takes energy. Therefore we want to find an economical balance between speed and energy.
The practice of pivoting to a positive permutation
Taking us back to our real-world example of the squad, instead of audio signals from a bird we are instead focusing on the amount of change that occurs in our system of work. In other words, how frequently do we release new features, or provide services to our customers?
If, on average, you expect to make a release every month then you want to have held at least two or three check-ins (or samples) to ensure we have a clear idea of our trajectory and ensure we’ve identified the amount of change that has occurred. This equates to our original fortnightly cadence, as we started with, and funnily enough aligns closely to the ideal scenario provided by many agile frameworks.
However, if you find you release your work (or complete a cycle of change) over a longer time horizon then you suddenly have a basis upon which to adjust your cadences. Working with hardware and infrastructure, for example, might only see change occur every 3 months, in which case a cadence of 6 weeks might feel more appropriate. On the other side of the scale, a help desk that triages defects on a weekly cadence might shorten their cycle to a couple of days, providing that doesn’t cost too much effort on the team.
In closing
Although the default tempo for most agile squads is on a two-week cycle, the context and nature of your work might mean that this speed might not suit the needs of the team. By following Nyquist’s Theorem and identifying how often you expect change to occur in your system of work, you can safely calibrate your cycle to align to the needs of your customers and find harmony in your delivery patterns once more.
