A one-size-fits-all ritual cadence, in which you hold rituals simply for the sake of holding them, may be detrimental to your team’s progress, but never holding them may be just as damaging. In this post, Senior Product Manager Cristy Stone explores the importance of rituals and their cadence.
The first software company I worked for scheduled only one staff meeting per week. For thirty minutes every Monday, the entire staff would go over our current list of milestones; to schedule more meetings during the course of the week was considered anathema, a waste of everyone’s time.
It was while I was at this company that I first stumbled across agile processes, specifically Scrum. Scrum calls for weekly rituals, or ceremonies (e.g. stand-ups, retro, and planning) but I didn’t dare ask for more meetings. Instead, I casually pulled people together, first on a daily basis, then to look back over the week, and so on. Eventually, after everyone saw the value that each of these get-togethers had for the team, they were folded into every project on which we worked.
I’ve since worked with other companies that are at different stages in their “agile transformation”, and I’ve seen the same struggle. Yes, the rituals are important, but in calendars that are already jam-packed, the rituals can start to lag, and are sometimes dropped altogether. After all, if the point of agile is to be more flexible, how important is it to hold these on a weekly or biweekly basis?
The short answer is this: The rituals themselves are crucial, but the timing can be more flexible.
The Agile Manifesto, published in 2001, sought to revolutionize software development by admitting that it’s a tumultuous process. By valuing “responding to change over following a plan”, the Manifesto recognizes that the previous method of spending months gathering fixed requirements prevented teams from adjusting to new information, leading to software products that nobody wanted to or could use.
But in order to respond, we have to know what we’re responding to.
Around the same time The Agile Manifesto was being drafted, a framework was developed at IBM that addresses the same kind of uncertainty. The Cynefin framework dove deeply into different relationships between cause and effect, mapping them out into (roughly) four potential quadrants:
The complex quadrant—which is, to quote Dave Snowden, a “realm of unknown unknowns”—tends to be most useful in a discussion about software development. Because there is no one clear path through, the best way forward is to “probe-sense-respond”.
It’s like putting your hand in the bath water before you get in: If it’s too hot or too cold, you can still easily and safely adjust.
Typical agile rituals are how we “probe” in order to quickly “sense” and “respond”; each ritual can be interpreted as applying to particular parts of the development ecosystem that contain the customers, stakeholders, and product team.
Some rituals are about determining the state of the customers. When developers and product owners groom, for example, they’re reflecting on what they know about the user’s needs to craft and refine the user stories that then become the pieces of work for the team. Others are about determining the state of the stakeholder system. In particular, planning and demo rituals invite participation from the product owner and any other decision makers through prioritization exercises and feedback loops.
All the rituals create a forum for team members to connect, which is especially helpful as more and more people work from home or from remote locations. Some rituals, however, are specifically about determining the state of the team/work system. This is where regular stand-ups and retrospectives fall, and, to some extent, planning. The commitments and confidence ratings that the team gives the sprint can be leading indicators of internal dissatisfaction or worry.
So, when do these rituals need to happen?
To be truly responsive, rituals are done whenever there seems to be a need. Because we’re human, and because timeboxing can be very effective, regular cadences are often set. These cadences can be good a way to be rigorous and ensure that the team is checking into the system often enough to be responsive. They can also provide a sense of control and predictability.
The downside of cadences is that predictability can lead to boredom and, worse, to rituals being taken for granted or ignored. When that happens, teams start to let some of them slide, rescheduling or sometimes dropping them altogether. Usually, the first one to go is the team retrospective. It can be easy to say that “internal team stuff is being handled”, “it’s not as important”, or “we just did this.”
The danger, however, to letting too much time go between any of these rituals is that you risk heading too far in the wrong direction. As any navigator knows, a shift in course of just three degrees, if followed long enough, can lead to a destination far away from the original goal.
The just-right cadence depends on the team, the project, and the goals. I’ve seen great success with a weekly demo and retro. Feedback came in small enough chunks that progress felt consistent; the ceremonies themselves didn’t take too long; and any adjustments were made and tested the following week. Weekly demos and retros are not always practical, so a good rule of thumb is that they should happen about every two weeks, or, at the very least, monthly. What matters more than any particular duration of time is consistency—making sure these check-ins happen in such a way that the team does them automatically and thoughtfully.
Try playing around with your process to find out what works best for your team, because one size never fits all. Set up some experiments: Take a look at current performance, come up with ideas about how to do better, then figure out what you can measure that will help you determine how successful those ideas are. These measurements don’t have to be a robust set of KPIs; in fact, it helps to pick just one or two metrics that are easily visible so that you can respond more quickly. Give your experiments enough time to prove, gather your data, and adjust course as necessary.
Rinse, lather, repeat.
After all, the name of the game is Agile.