The Meeting Protocol — Improve Transparency And Safety In Scrum Teams

The Meeting Protocol is a set of behaviors that Scrum teams can self-adopt, regarding meetings. Its intention is to increase psychological safety within the team, and transparency all around.

First, the context in which this protocol is applicable: You work in a Scrum team in a larger organization, possibly together with more Scrum teams around you. The organization is still ‘doing agile’, not yet ‘being agile’, which for our purpose means that there are still many legacy processes, meetings, and hierarchical or social structures ‘on top of’ the Scrum teams. Let’s say your organization is somewhere in the middle of an ‘agile transformation’ (ugh). Individual Scrum team members are still somewhat entrenched in their legacy commitments and structures, apart from their work on the teams product backlog.

How to use meetings then, as a Scrum team in this situation. Let’s be precise; what do we mean by meetings? Well, not the Scrum events, nor water cooler chats, but other than those: any (planned or ad hoc) discussion between people outside the team and any of the team members regarding work. Meeting requests or calendar events coming from outside of the team to any team member. The bi-weekly status update meeting in everyone’s calendar, someone walking into the team area starting a discussion on a technical topic, and so on. Discussions initiated or organized by the team itself apply as well, when they include non-members. This covers almost anything but the Scrum events, on purpose.

On to the protocol. The protocol describes a set of behaviors, to be performed by the team members. The protocol works best if all behaviors are practiced together, not omitting any of them. So here we go.

The Meeting Protocol

All meeting requests must be shared

Team members share any meeting requests they have received from stakeholders or other outsiders, within the team. Upcoming meetings should be brought up by members during the Daily Scrum. The team should try to clarify the purpose of the meetings. A shared calendar in Outlook or Google or similar team software could also help.

Consider not to go at all

Time is precious. The team should consider: What would happen if we declined? Will it impede our sprint goal, if we go, or rather if we don’t go? At minimum, ask the organizer of the meeting to provide the purpose or agenda of the meeting, if it is unclear to the team. As a team you must decide to attend or not, and if so, which members (plural) to send. Meeting requests that do not provide an agenda or purpose up front, should be either clarified or considered to be of low interest.

Always 2 or more members of your team present

This is the most important rule. If the team has decided that they will attend the meeting, never send 1 member only. Again, this is the most important rule. If only one member is able to attend, then DO NOT GO, but excuse yourself. Let there be none, or two, but never one.

Treat every meeting as a refinement session

The Scrum Guide does not identify ‘the refinement session’ as a Scrum event with a fixed frequency and or time-box. It does however mention the activity of ‘backlog refinement’; discussing and clarifying the product backlog items together with the team and stakeholders. The Guide says: “ The Scrum Team decides how and when refinement is done.”

In this protocol, we dial this up to eleven; every and all meetings, as defined earlier, are to be treated (only) as an opportunity to refine your product backlog items.

During the meeting

Now your team is partaking in the meeting, with two or more team members, as always. Start by stating the expectations you have, and explain to the others what you hope to achieve. You must explain the fact that you treat this discussion as an opportunity to refine your teams product backlog, or to discover new items. Detailed behaviors are:

• Check that you have a team member with you, or leave.
• Bring something for taking notes.
• Explain that your note-taking, listening and suggestions should result into backlog items being refined or added. No (new) work will be done by the team, if it’s not on their backlog. The team would like to take away a better backlog from this meeting.
• Do Not reorder any backlog items during the meeting (you are not the team or the Product Owner, and it’s not the right time).
• Never ‘promise’ to do work without modifying or adding a backlog item. You can always say ‘we shall take this back to the team and we will let you know’.

Discuss afterwards with the team

Once the team delegation returns from the meeting to the team, discuss the relevant backlog changes. Any new knowledge that the team delegation has gained from the meeting should be shared immediately or in the next daily scrum at the latest. If there are no changes in the backlog as a result of the meeting or the discussion afterwards, consider these meetings less attractive for next attendance.

What is important is that as a team, you have one opinion on the meeting results, and you share the same (updated) commitments as a result of the meeting. And all newly discovered work must be made visible on the backlog.

This concludes the Meeting Protocol.

How does it work

Disclaimer: the context we have described for this protocol to work in, is actually very narrow, and maybe it’s just were I work, so that’s why it worked.

Nevertheless, the behaviors to be displayed in the protocol are very clear, and very visible, inside the team and out. They are in themselves communicating the no nonsense attitude of the team, when it comes to spending time in meetings, and they show others how to best get things done with the team.

The important one for safety: never send someone alone into foreign territory. Two make better decisions than one, and are less likely to commit (their team) to any work for the wrong reasons. Two team members together have more courage than one, to say no.

Legacy relationships (i.e. managers) will be less able to persuade a person to promise things, when there is a team member with that person. The legacy relationships will learn over time that they can no longer ‘claim’ individual team members to do invisible work.

The team, over time, will come to know exactly which 2 or more of them is in what meeting, making potentially what decisions. The team also demonstrates a way to handle ‘management pressure’ to the other Scrum teams around it.

The organization learns to address the team as a whole team, and to not rely on the expertise of individual members.

Work which was previously invisible, coming from all angles and becoming the burden of individual team members, has been made visible by accepting no work except via the backlog.

Results

In the teams where this experiment was run, (n=1) under the given context, it resulted in actual psychological safety within the team, the hardest thing to come by, and the most rewarding. Team members became less stressed, and relied on each other to take on any meeting and make good decisions there, without feeling pressured by legacy relationships. As a bonus it also annoyed some managers sometimes.

Team members have been able to disentangle from their old structures and commitments, without fear, while supported by their team.

Could you do it?

Please try it for yourself, if you dare. You can start small by mentioning your personal new meeting appointments for the day, in the Daily Scrum, and ask if someone could join, or if they think you should attend at all. Bring your personal legacy meetings, duties, and work to the team, and enlist their help. Encourage the habit in others. Try to make meetings a useful part of your day, as a team, to interact with your stakeholders, looking through refinement glasses all the time.

Hope you enjoyed this post. Please do clap, comment, follow, share or respond! You can also find me on Twitter here.

Do you want to write for Serious Scrum or seriously discuss Scrum?