Recently a Twitter discussion took place about allowing teams to have multiple cadences, for instance by using a different rhythm for planning the work and for learning and improving. Decoupling cadences gives teams room to explore and learn what works best for them; it can lead to more adaptability and autonomy and better outcomes.
The first tweet from Matt Barcomb was:
Barcomb: Protip: if you have a well formed mvp and a way to prioritize work you don’t need to plan sprints (or, obviously, have sprint goals).
Ron Jeffries quoted Barcomb’s tweet and added:
Jeffries: unless you want to improve predictability or reduce cycle time or improve communication ... then a cadence and some planning might help …
In the twitter discussion that followed, Barcomb suggested allowing teams to decouple cadences for planning and improving, whereareas Jeffries questioned why you want to do that:
Barcomb: Of course. I’d typically recommend having a cadence for both planning and for improving. Though I’d usually suggest decoupling them.
Jeffries: why decouple? seems kind of neat to plan regularly and review what was just done at the same time.
Barcomb: What was frustrating to me, was the teams that needed a different cadence for retro but felt (or were told) they weren’t allowed to because that’s not Scrum.
Jeffries: why does someone "need" a different cadence? Was it SLOWER than the Sprint cycle? Why?
Next John Cutler joined the discussion; he mentioned several reasons why you want to have multiple cadences:
Cutler: Customer feedback loops
"Delivery" loops.
Integration loops
Decomposition work
Retrospective loops
Goal setting loops
It _may_ help to do these all on one fixed cadence. But often not. Some just-in-time. Others longer. Others shorter.
Matt Heuser tweeted that he has an example of a company that used different cadences:
Heusser: I can tell you about the success we had at the indiana company next time we’re at Agile&Beyond, Ron, could try to bring some customers. @Hopasaurus
InfoQ interviewed Matt Barcomb, John Cutler, and Matt Heusser, about decoupling cadences and the benefits that it can bring.
InfoQ: What are the advantages and disadvantages of having one cadence for planning and improvement?
Matt Barcomb: To be clear, I don’t think the issue is really about having one cadence for planning and improvement or not, but rather a team being allowed to decouple the cadences of their rituals. Too often I see teams have only one cadence for no better reason than "because Scrum".
The disadvantages of not being allowed to decouple cadences involve removing a team’s sense of autonomy as well as causing non-optimal outcomes to occur. The advantages are obviously just the opposite of that :)
Some of the real-world things I’ve seen happen because teams couldn’t decouple their candence are:
- Doing too much and too many kinds of planning, even for just "sprint level" work.
- Poor planning quality and outcomes.
- Improvement rate not throttled appropriately for the team’s ability to absorb change.
- Forgetting improvement ideas & delaying needed improvements.
- Various roles and levels of improvement not considered.
Of course, there were other factors involved and there are ways to resolve some of the above issues while keeping the cadences coupled. However, allowing a team to decouple cadences lets them explore and learn what works best for them. And, in many cases, it can help achieve better results.
John Cutler: Teams often cite convenience as the key rationale behind coupling improvement and planning cadences. They opt to "get the meetings over with" in one go. Additionally, retrospectives tend to center around the "success" of the planning cycle. By coupling cadences, teams ensure that those learnings are "fresh".
There are a couple potential disadvantages. A team can absorb only so much change in progress/process. Frequent retrospectives become a perceived chore and emotional drain, and lose their oomph. Meanwhile, a two week cadence for planning may be too long for effective sensemaking. The "do it all at once or not at all" mindset makes it impossible to adapt the approach to better fit the team’s unique needs.
Matt Heusser: Advantages of coupling: it’s easy, and improvement has a chance to actually happen. Too many companies are too busy with the busy business of production to take time to reflect at all. Or, if they do reflect and propose things, there is no formal way to get them injected into the next project. For example, one company I worked with was enamored with the idea of ambiguity reviews. The manager of the project managers said something like "from now on, all projects will have ambiguity reviews!" while holding a checklist. That was it. I never actually heard of a single team using it. By having a sprint concept, you have a defined time to start the experiment (next sprint) and a defined time to end the experiment and consider what to do next (the next retrospective).
In the article Customize Your Agile Approach: Select Your Agile Approach That Fits Your Context, Johanna Rothman explores how to customize the agile approach and design a cadence of delivery, planning, and reflection that might work for a product, project, or team:
Every team is unique, so every team needs its own agile approach. Some teams can use an off-the-shelf framework, such as Scrum, XP, or the Kanban Method. However, in my experience, most teams need to customize their agile approach to their circumstances. (...) [Your circumstances] might require a cadence of planning, demos, and releases. However, your team might discover that the same cadence does not work for all three parts of what we think of as agile rituals.
InfoQ: Under which circumstances would you suggest to decouple cadences?
Cutler: I suggest decoupling cadences when I (or the team) senses an energy mismatch and/or bottlenecks in information flow. For example, imagine a retrospective at the tail end of a two week sprint. Things have gone awry, but no one can quite pin down the "cause". Information is missing. Meanwhile, our continuous improvement kanban board has hit its EIP (experiments in progress) limit. All of the ongoing continuous improvement initiatives are still generally applicable, and we’re not ready to do the deep emotional work to revisit those promises.
In this situation we might want to experiment with some decoupling. We might want to 1) shorten the sprint, 2) do "spot" fifteen minute retros on a just-in-time basis when we’re experiencing issues first-hand, and 3) do shorter retros on a biweekly basis and deeper retros on a monthly basis. In a pull system we find an optimal moment to take on additional cognitive load and convert learning to action.
Barcomb: I would recommend allowing a team the flexibility to decouple their cadences in any context. I’ve heard some people claim that teams just starting to work in an agile fashion should couple their cadences (basically "do Scrum"), as if decoupled cadences are some sort of "advanced" technique new agile teams won’t be able to master.
Personally, I have found this not to be the case. When I work with new agile teams I don’t specifically encourage or discourage coupled cadences. Instead, I find it more useful to facilitate a team discussion around what rituals they think they need and what cadences they might find useful for those rituals. I don’t find this to be some mystical, advanced technique. On the contrary, I’ve had teams tell me there were already working this way until someone came and told them "that’s not agile". Frankly, the concept of decoupling cadences is no more difficult than a children’s chore schedule.
Heusser: If improvement is actually happening, and the team is good at designing experiments, there is no need for them to happen at the same pace as planning -- instead it can be just in time or as-needed. The difference in my eyes is that moving toward more real-time decisions at these things requires more skill. For that matter, I prefer a variety of planning windows; a sprint is just one look at things. Consider baseball, where we can plan at the level of an at-bat, an inning, a game, a season, or the next few years for the team.
My general strategy is to add sprints when planning and improvement is chaotic or deceptive, then take them away once the organization is good at conducting experiments and has a predictable delivery flow. I worked with an organization out of Indiana - Matt Barcomb was there before I was; that had long-term, sustained, success. One of our early experiments was Just In Time Retros. We’d put pink cards on the board when we had something worth talking about at Retro, and once we had five cards (or it had been a while), we’d conduct a retrospective. A red card was pulling the chain, to schedule the retrospective as soon as possible.
InfoQ: Which benefits can decoupling cadences bring?
Heusser: Getting things to happen when they should happen, instead of on some artificial schedule, will improve outcomes. That will also require more skill - any complex model that requires judgement will be harder than following a prescription.
Barcomb: Ultimately decoupling cadences brings the benefit of adaptability and autonomy. If a team decided their rituals should have the same cadence because that’s what makes sense to them in their context, great, do it! If a team doesn’t have any better way to start, fine, give it a go! But please don’t mandate that teams always couple cadences because someday, in their context, it might not make sense and the team should be trusted to change how they work for meeting the expectations placed on them.
Cutler: Decoupling cadences can be used to better accommodate cognitive diversity, the working style of the team, the flow of information, our ability to process that information, and the variability inherent in complex work. It is a little naive to think that humans can process different types of work/reflection at exactly the same cadence. I argue the same when folks argue to do everything just-in-time and "flow based". That seems presumptuous as well. What if the humans on your team like to shut off their brain for the weekend?