If you’re looking for a guide to help you navigate Scrum ceremonies, you’ve come to the right place. They don’t exist. Have a nice day 🙂
Just kidding. Except about the Scrum ceremonies not existing. They really don’t. We know, Googling the term results in many sources offering up tons of information about different Scrum ceremonies and how to use them while transitioning your organization to agile. Our recommendation is not to listen to those sources because Scrum clearly isn’t their expertise.
Instead of giving you a guide about how to conduct events that don’t really exist, we’re going to provide you with a guide that will help weed out the people who claim to know Scrum but don’t.
Red Flag #1: The use of the term “Scrum Ceremonies”
Some Scrum-related websites purport to go beyond the Scrum Guide, explaining that Scrum events are best conceived as “ceremonies” with very specific constraints. Scrum, of course, does specify certain events that are essential to doing it properly. So, you may wonder, what exactly is the problem with calling them ceremonies?
In a nutshell, language matters. The idea of a ceremony likely conjures up some type of ritualistic, faith-based, hierarchical event, the specifics of which can (and should) never change. Conceived in this way, a ceremony is precisely the kind of thing that Scrum is designed to avoid.
Remember: Scrum is an empirically-driven framework for achieving Agile results. Yes, there are specific events that go along with the framework, but a key idea is that you use those events to generate good results in many different circumstances.
The Scrum Events that are essential to the framework are as follows:
- Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Any Scrum practitioner who knows their stuff will understand each of these events, their role in the overall picture, How they support the empirical process on which Scrum is based, and that Scrum ceremonies aren’t a thing. Moreover, flexibility is key in Scrum, so avoid people who reflexively act out rigid, ritualistic Scrum-adjacent events that they learned and carried over from previous jobs or training.
Red Flag #2: Vague Sprints
Sprints are often misunderstood and misused. For example, they are commonly 2-weeks long, but most people have no idea why. So, listen up buttercup, it’s about controlling risk. Shorter Sprints = less risk. Risk of what? Risk of building the wrong thing, wasting money and time, risk of creating designs that don’t make sense, risks of technical problems, etc..
“Sprint” does not mean “run as fast as you can” like a mini-death march. It’s designed to limit the amount of time you have to solve a problem (e.g. two weeks).
The real problem people have with Sprints is breaking down work small enough to deliver valuable solutions. They shape the length of a Sprint to the work. But to control the risk it should be the opposite; break down the work small enough to fit into a risk containing shorter Sprint length.
Grab a pen, write this down- Every large problem is the sum of many micro problems that can be solved. Solving micro problems also solves large problems and also makes you the superhero.
Red Flag #3: “We do Agile.”
Like it or not, Agile is a buzzword. It can be used substantively, but it can also be used in a way that doesn’t really say anything. It can be applied loosely to mean whatever you want it to mean.
In general, the problem is that many people don’t have the ability to separate words from the activities or objects that they refer to. Just because someone uses jargon doesn’t mean they understand the underlying concepts or practices associated with that jargon.
So if somebody says, “We do Agile,” you should prompt them to explain what they mean without invoking the word itself. There are many frameworks, including Scrum, that are designed to achieve Agile results. The processes that undergird and shape different frameworks are really the most important thing for achieving outcomes. Any serious person in this space should be able to articulate those processes in a jargon-free way.
You want to put yourself in a position in which you rely on the knowledge and expertise of people who are not worried about terms (Agile, ceremony, etc.) but are instead focused on the underlying aspects of Scrum that improve the efficacies of your organization. Isn’t that the whole point?
Responsive Advisors embodies this results-focused approach to Scrum and Agile. Our passion is increasing the effectiveness of business practices across industries with a focus on the human side of Agile transformation. We help develop your number one asset–your people–by teaching Professional Scrum and a multitude of complimentary workshops. We also offer Agile coaching directly partnering with teams to aid in Agile development and transformation of organizations
When deciding who is going to help guide you through this process, do you want someone who touts non-existent phrases (e.g. Scrum ceremonies) and wastes a lot of unnecessary post-its? Or, do you want someone who uses their expertise to not only educate your team but also make the process of learning fun?
Tagged with: