The 4 Agile ceremonies explained & ranked by professionals

Personally, I think the ceremonies define “Agile”. At least, that is the prevailing sentiment among those working in software development teams trying to adhere to agile principles.

Origins of Agile Software Development (A Short History Lesson)

But before we dig into Agile ceremonies and their benefits, let’s take a little step back. When we talk about Agile (with a capital “A”) today, a common view seems to be that we must adhere to some version of Scrum.

First off, Agile is not synonymous with Scrum. They’re not the same thing. At least, they’re not meant to be.

In fact, working in an agile manner sometimes might mean adopting a waterfall approach. If we subscribe to and demonstrate an agile mindset, we’ll endeavour to solve problems in the most effective way possible. We want to deliver value and reduce waste. It doesn’t mean we have to be working in sprints, for example.

As it happens, sprints can be really powerful, but we’ll come back to them later.

So What is Scrum?

Well, according to scrum.org, Scrum is a framework:

Sounds good!

Since 2016, The Scrum Guide even included a set of values:

• Courage
• Focus
• Commitment
• Respect
• Openness

So is Scrum a philosophy or what? Well, it’s still a framework. The values are important, but I would argue those values are embedded in the original Agile Manifesto, which Scrum has built upon.

Scrum is highly prescriptive and explicit in how it states things should happen. It is useful for helping teams move away from a more rigid approach to product development. Can teams outgrow Scrum? Absolutely.

The broad perspective of Agile

Agile is, on the other hand, a broad approach. The Agile Manifesto is a statement of intent and a set of principles (twelve to be exact).

There are no ceremonies specified in the Agile Manifesto, despite some of the principles seemingly aligning with some of the Agile ceremonies we might be familiar with today.

For example, take the third principle:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Agile Manifesto principles

There is nothing rigid here. Agile is a general principle of delivering working software more regularly and in increments, rather than in a waterfall approach which typically relies on a “big bang” approach at the end.

Scrum, on the other hand, defines some strict rules around this principle and we are presented with “Scrum sprints”. In Scrum, sprints must be between 1-4 weeks or “one month or less”. That’s the rule. Scrum is a framework, after all, and it is telling you what you need to do. 

If your iterations are 6 weeks long, then you’re not doing Scrum. Might you still be agile, though? Of course.

The value of Agile ceremonies

I recently asked the following question on Twitter:

“If you had to convince someone of the benefits of Agile, which ceremony would you highlight first, and why?”

Interestingly, nobody said “there are no ceremonies in Agile”. It might technically be more accurate to refer to them as Scrum ceremonies (or events) because the Scrum framework has made them explicit whereas the Agile Manifesto was always more high level.

Here are the results of the Twitter poll:

• Daily standup: 39%
• Sprint retro: 21%
• Sprint planning: 39%
• Sprint review: 0%

With 33 votes, this isn’t the largest sample, but it was interesting to gauge the sentiment of those who responded.

I was personally surprised that out of all sprint ceremonies, Sprint Planning was rated so highly.

For me, Retrospectives and Daily Standups embody the ethos of working in an agile manner in that they foster ongoing improvement and radical transparency.

Some of the replies to my tweet agreed:

• “Definitely retro. Create feedback loops.”
• “Retro because it leads to improvement.”
• “Quick 15min daily standup because it helps everyone check in & identify any blockers – especially in a remote setting!”
• “I am very new to Agile and thought daily standup meetings would be an annoying encumbrance. I quickly found it an effective way to… help stakeholders understand impediments, and be able to both receive and provide help.”

I also ran the same poll on LinkedIn. Here are the results:

• Daily standup: 43%
• Sprint retro: 29%
• Sprint planning: 14%
• Sprint review: 14%

This resulted in an even smaller sample size than on Twitter and a mixed set of replies. 

That said, Daily Standups ranked highly across both polls.

The top Scrum ceremonies, ranked by professionals

1. Daily Standup

So how do daily meetings foster an agile approach to working?

Well, firstly: standups aren’t “meetings”! Well, they shouldn’t be anyway. If you’re having 1-hour long Scrum meetings every day and calling them standups, chances are nobody is particularly happy about them!

What does the Agile Manifesto have to say about all of this? Here’s the fourth principle:

Business people and developers must work together daily throughout the project.

Agile Manifesto principles

This sounds reasonable, right? Collaboration on a daily basis should in theory reduce the risk of misunderstandings and improve the ability of the team to collaborate on difficult problems.

Daily standups, as defined by Scrum, aim to help address this goal of daily collaboration. 

This is where I find the Scrum framework particularly useful because it states that daily standups (or scrums) should last no longer than 15 minutes.

According to the Scrum Guide:

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint.

The Scrum Guide

The aim of daily standups is to “improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings”.

The standup should be short and focused. It is not a status update. It is not a “meeting”. Standups shouldn’t get in the way of moving forward. If a team member is stuck on something, this should be raised in the standup as a “blocker”. A self-organising, agile team will want to help remove that blocker.

Do all standups need to happen synchronously and for 15 minutes? Well, effective teams can quickly outgrow Scrum. They might dispense with scheduled standups and have asynchronous daily check-ins via instant messaging, for example. 

But the Agile principle of daily communication remains.

2. Retrospectives

Another Agile ceremony (or Scrum event) is the sprint retrospective, or “retro”. Why do we have them?

The final principle from the Agile Manifesto states the following:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Manifesto principles

That’s the principle. The implementation within the Scrum framework is:

“The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.”

Again, the Agile Manifesto states the general principle, whereas Scrum makes it explicit.

Why are retrospectives useful?

As one person on Twitter put it in response to my poll, retrospectives provide “an opportunity to improve things. Otherwise people don’t even think about what went wrong and what we can do to improve it…”

3. Release planning in Agile

In professional circles, planning is closely behind standups and retrospectives in terms of popularity. If you’d like to learn more about why this might be the case, we’ve covered it extensively in one of our previous articles.

4. Sprint reviews

If you’re working with an agile agency, sprint reviews will be your favourite. I can see why developers might not be so fond of them. Having a review with stakeholders is still crucial in agile, though.

Remember the fourth principle?

“Business people and developers must work together daily throughout the project.”

On a sprint review, the Scrum team shows stakeholders a demo of the progress. This helps evaluate where we are compared to our sprint goal, and whether priorities need to shift.

Sprint review is probably the most informal agile ceremony. It’s different every single time, and it’s heavily dictated by our progress as a team. There are some rules, though. The team can’t afford to be distracted by a review, so it’s best not to turn it into a 4-hour feedback session where we tear every feature apart.

But a review is the best moment to communicate a change of priorities, whether influenced by the demo or not.

If you’ve read our article about release planning, part of the sprint review has the same purpose, just on a smaller scale. This is where stakeholders set the direction for the next iteration.

Is Agile always Agile?

In a recent issue of his Nimble Geek newsletter, my friend Jonas highlighted how Scrum might definitely not be the approach to choose for your team. It is unfortunately common that “companies run scrum and claim to ‘work agile’ when they are operating in environments where they would be better off without it.“

I also like how the Agnostic Agile website puts it in their eleventh principle (yep, another set of principles!) where it states that we need to “recognise that there is more to Agile than Agile”.

There should always be a rationale behind using a tool. The same goes for frameworks like Scrum and the associated events or ceremonies.

Doing all of the things that Scrum says we should do does not solve all of our problems!

In fact, trying to adhere to a framework like Scrum without some level of appreciation for agility and agile thinking could do more harm than good.

Communication is key

What do all the Agile ceremonies (or Scrum events) have in common? Well, they are certainly all designed to try and improve communication and transparency of working.

Arie Van Bennekum, a co-signatory of the Agile Manifesto – and a supporter of Agnostic Agile, as it happens – is a great advocate of focusing on the power of synchronous communication which reduces the risk of the inevitable misinterpretation that occurs when “documents” (designs, specifications, and whatever else) are passed back and forth, ad nauseum. 

Rather appropriately, one of the original twelve principles in the Agile Manifesto is:

Working together on a problem, collaboratively, in a shared space, whether physical or virtual, dramatically speeds up decision making and achieving consensus.

Incidentally, if you can catch one of Arie’s talks, I would wholeheartedly recommend taking the time out to do so.