Do not deify Agile in ceremonies
Focus instead on activities which enable good agility
Around the relics stood the Circle,
All robed in black, but for one in blue, and one in red,
And the one in red intoned the numbers of truth,
And these numbers were one, two, three, five, eight and thirteen,
‘Eight’ called the hooded circle in unison,
‘Nay, let it not be so’ said the one in blue,
A pause,
‘Five’ affirmed the circle,
‘Five is good’ echoed the one in red,
And the ritual was ended pleasingly.
In some of my own circles, I have been a bit of a broken record. ‘Stop calling it a ceremony’ I would say, clearly with such vehemence that it now has a similar response to electro-aversion therapy. My dearest colleagues shudder as if in pain when the mere allusion to the word would be hinted at as they speak. Ooops, too far, sorry team!
But why do I, and many, many, others feel this way? And so strongly.
Ceremony means ritual
Ceremony, noun
the ritual observances and procedures required or performed at grand and formal occasions.
Ceremony is a signal that procedure and process matters more than the substance of the conversation, discussion or debate. Ceremony has weight, an order of proceedings that should be followed. Shhhh, keep your voice down, we do not want to disrupt the Master of Scrum reading from The Guide.
When we call something a Ceremony we are saying that we expect certain things to happen, in a certain way. When people attend a Ceremony, they expect to be told to act, behave and think in a certain way. It was commanded from up high to attend. Their freedom of choice is reduced or removed. Do not challenge the norm.
This is the antithesis of good agility.
Don’t call them meetings (or events) either
I met a colleague the other day to talk through the interactions she could expect to have on a regular cadence when working with several teams. We talked about regular backlog prioritisation as a team of Product Owners; release of value planning; reviewing what has been done and learned; and a forum for stakeholders to express their preferences to a team of Product Owners. ‘So do I now need to put all of these meetings into my calendar?’ she asked, clearly looking at an existing very full calendar with a heavy heart.
These are activities, not meetings. Certain activities are important to enable empiricism, and to build reinforcing build-measure-learn feedback loops. When you start by saying that there should be a meeting for it we are typically implying that there is a 30, 60, 90 minute or longer block of time that will get filled for this purpose. Someone is typically expected to facilitate that meeting. And like goldfish growing to the size of the bowl, we will use every minute of that time.
Focus on the activity
Instead let’s focus our attention on the activity. Take just one example: backlog prioritisation between a team of Product Owners in an organisation of connected teams, each with their own product backlog. What matters in this activity is that everybody aligns to a shared understanding of what is valuable for the upcoming sprint or increment of work; any known connection points or dependencies are mutually recognized; and the team of Product Owners can move forwards in an agreed direction.
This might need a meeting, that is the decision of the collective group on how to have the conversation. It might be satisfied through daily interactions of the team and not need a formal meeting. It could be done over a cup of coffee.
There may well be a meeting in your calendar today that would be a good place for that activity to occur. Perhaps multiple activities might be accomplished in a single existing meeting.
Context matters, so start with the activity first, discuss how that activity can be accomplished effectively and who should participate. Then let form follow function.
