Cadence and Agile
Introduction
I can almost guarantee you that the first time I heard the word “cadence” was back in grade school music class. We were probably rehearsing for one those bi-annual vocal recitals and the word was almost certainly written on the sheet music. It might’ve been one of the Armed Forces hymns, but I digress…
I almost certainly heard it, too, when I started to play the cello in the fourth grade. Part of the gig was reading music and understanding the beat, tempo, etc.
So that’s the musical definition of “cadence.”
I kind of lost track of the word for awhile, though. It didn’t come up again for me until years later in the workplace. People talked about cadence as meaning “how regularly something happens.” For example, “we meet on a two week cadence.” Or, “the cadence of our performance reviews is annual.”
Cadence in Agile
When I was exposed to Agile in 2008, that word “cadence” was there again, even if it wasn’t hitting me over the head. Let’s take a look at where it shows up.
Agile Manifesto
“Cadence” isn’t used anywhere in the Agile Manifesto. But it’s implied in roughly half the principles.
Let’s run through the ones where I think cadence shows up:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
The word “continuous” is the word to me that makes me think of “cadence.” Whether it ends up being an actual, predictable, cadence will obviously vary.
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
This principle portends some sort of conversation happening between the consumers and the makers. It’s quite possible that this conversation happens ad hoc… but it’s also possible it happens on a cadence.
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
The “timescale” concept that’s baked into this principle implies cadence.
“Business people and developers must work together daily throughout the project.”
Again, the frequency with which this principle should take place implies cadence.
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
The phrase “constant pace” implies cadence, as does “sustainable development.”
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
The phase “regular intervals” implies cadence.
I think you get the idea by now. I could make a case for cadence showing up in a few of the other principles, but I won’t belabor the point.
Scrum
Unlike the Agile Manifesto, Scrum outlines an explicit cadence to follow. The events are meant to be followed in order; and that’s for good reason. The outcomes from each event are inputs to the following events. If you miss one, or skip one, or do them out of order, you run the risk of missing out on the ability to inspect and adapt. Cadence is so imbued in Scrum that the word even shows up in the Scrum Guide (in the 2020 version, it’s used in the “Inspection” section to describe Scrum events).
Cadence Outside the Workplace
I have my own personal cadence. I get up in the morning. I go and run a few miles. I eat. And the day continues from there with some amount of variation. But I can be pretty sure that I’m doing a lot of the same stuff every single day at roughly the same times — eating, sleeping, exercising, etc. If I don’t do one of the things that I normally do on a given day around the normal time I do it, I might feel a little out of sync for the rest of the day. I might be able to go back and do the thing I missed, but I might not. (You can’t go back and eat the breakfast you forgot to eat; but you can certainly have breakfast foods for dinner.)
The Connection Between Cadence and Habits
Now that we’ve talked a bit about cadence and the value of having one, I’d like to make the connection between cadence and habits. A habit is something you do regularly. It’s often something that’s hard to give up. Everyone has habits. Some of them are good, and some of them are bad. Many of them just are. One of my habits is running. I enjoy doing it. It helps keep me fit and gets me to go outside (even in the harsh Cleveland winter). If running is my habit, then my cadence is daily. I run every day. And that’s the connection between cadence and habits.
So how does all of this apply to Agile? Well, when we carve out time to do things on a cadence, our habits — whether we like them or not — stand a better chance of success. For example, if I set up a recurring Friday invite for us to get together and take a look at all of the work we accomplished over the past week, it’s safe to assume we’ll end up having this conversation more often than not. Having the invite on the calendar is a forcing function for the conversation to occur. And there’s an invite on our calendar staring right at us every single Friday; reminding us to have this conversation. This is just one example of how cadence can help our Agile habits stick.
Without Cadence, Habits Fail
Now that we understand the connection between cadence and habits, let’s look at an alternate world; one where there’s no concept of cadence. But even without cadence, we have habits we want to develop. We’ll call this the world of “ad hoc.” In this world, things only happen when we think it’s necessary, or when we think they need to happen. In this world, it’s easy to get caught up in whatever grabs our attention and completely forget about the habits we’re trying to cultivate and nurture. Let’s look at a scenario.
A team starts to do some work for an internal customer. They have a “kick off” with the internal customer and talk about how the team will show off their progress to the internal customer to get feedback. The team decides that they will determine when the work is ready to show off. They agree that they will tell the project manager when it’s time to schedule a demonstration. Two months later, the project manager gets an e-mail from the internal customer, asking when the first demonstration will take place. The project manager asks the team, and the team says they aren’t sure when they will be ready. Perhaps next week; after they’re finished with another chunk of really important backlog items.
In this scenario, the team wanted to cultivate an important Agile habit — showing off work to customers for feedback. They lacked the cadence to pull it off, however. Instead of articulating some sort of cadence at the outset — for example, “we’ll show off our progress every other Friday” — the team left it up to the world of the “ad hoc.” And in that world, the tyranny of the “now” often wins.
Cadence Promotes Discipline
If we go back to the musical definition of “cadence,” I can’t help but being struck by the fact that it’s directly related to the beat. The beat of a song is disciplined. Unless you’re talking about some sort of wild prog-rock or free jazz experiment, the beat of most songs doesn’t change all that much. Even if the music changes, the beat is a constant. Beats Per Minute (BPM). It’s cadence, and this cadence promotes discipline.
In the world of Agile, it’s the same story. Having a cadence forces us to do things. It forces us to show off our work, to integrate our work, to reflect on our work. All of these are things that, if we left it to the world of the “ad hoc,” we probably wouldn’t do in a disciplined fashion.
Don’t forget — Agile is a very disciplined way of working. In some respects, it’s the most disciplined way of working. It promotes prioritization, cutting out waste, and doing only what customers want. What could be more disciplined than that?