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.
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.
Well, according to scrum.org, Scrum is a framework:
Scrum is not a methodology. Scrum implements the scientific method of empiricism.
Since 2016, The Scrum Guide even included a set of values:
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.
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.
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:
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:
I also ran the same poll on LinkedIn. Here are the results:
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.
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.
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…”
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.
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.
Let us know in the comments and let’s see how your experience stacks up with the agile practitioners in our network.
If you’re commenting for the first time, don’t forget to grab your FREE PDF along the way!
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.
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.
To sum up my view: use the ceremonies that help your team get better at delivering value.
Every team is different.
Every project context has its own nuances.
Use what works. And you can only find what works through active experimentation and honest reflection.
So what does Agile mean to you and which Scrum ceremonies or events do you find to benefit your team? I’d love to hear from you on Twitter or in the comments to this article.
Do your daily “status report” meetings suck? We’ve all been there. So here’s our gift to you – immediate access to a PDF that will improve them.
Originally published Jun 07, 2022 10:21:25 AM, updated June 1 2023.