It’s Wednesday, so welcome to the second post discussing the McCarthy Protocols! This is going to be quite a bit longer than the standard post, but welcome anyhow. I mentioned in Part 1 that my Game Project class used a variation of Scrum known as Scrum-ban with these protocols to organize our teams. Scrum-ban was the method in which we framed our work, and The Core [aka McCarthy] protocols were how we framed ourselves.
It may feel silly in the early stages, but using this method, you may soon find yourself being much, much more productive. So let’s dig into the first sets. Remember: The protocols are actions, and the commitments are the reasons and promises to the team upon which those actions are predicated. If you’re feeling a little lost reading this so far, or want to see the full list (it’s not long!) of the protocols and commitments, click here to read the introduction post.
Otherwise, read on…!
Pass / Unpass
The Pass and Unpass protocols go together, so I’ve grouped them as such. They’re likely to be among the more common of the protocols being used consistently. The Pass is done, simply, to decline to participate in something (usually some sort of activity). Like the majority of these protocols, it’s meant simply to create effective, efficient, and open communication. You can pass/unpass at any time by simply saying “I pass” or “I unpass” when you decide to or not to participate. You are never obligated to disclose your reasons for doing this, and never have to defend those reasons for passing.
By using The Core commitments/protocols as a group, you must always keep in mind that everything is done for the benefit of the project, so it is actually against the spirit of teamwork to hassle, shame, or otherwise judge people who pass, even if they do so without an apparent or “good” reason. Everyone on the team should be aware of the commitments, and one of them is “to neither harm – nor tolerate the harming of – anyone for his or her fidelity to these commitments.” In other words, if someone believes it is in the best interest to pass, then you should understand that it is for the good of the project and not inconvenience them in any way for doing so. With that said, you do not want to pass most of the time – this protocol is not offered as an excuse to not do work – you still have to keep to the project and work .
The Check In is most often used to begin meetings. Checking In is very simple: the speaker first announces how he/she is feeling (using either “Mad”, “Glad”, “Sad”, or “Afraid”) by literally saying “I feel <emotion>.” and may provide a brief explanation for it (“I feel glad because we completed our last sprint successfully!”). Remember – an individual can pass at any time. The speaker ends the check in by saying “I’m in.” which signifies that he or she intends to behave according to those core commitments. The members of the group respond with “Welcome.” Like “I’m in”, the group literally welcoming the speaker to the group signifies that the team acknowledges your commitment to the team.
This is why the system works: It is understood by everyone on the team that the commitments are held by everyone at all times and should be aware of their obligations to the team. Stating your feelings (one of the four above adjectives) without qualifications, only as they pertain to yourself, allows the team to quickly be aware of the state of their team members. For example, if a team member is glad, they are willing, ready, and able to work – they are approachable. Conversely, if they are afraid, it might be wise to avoid tasking them with additional stories or tasks to complete, using the Investigate protocol to find out why. In the context of the Core Protocols, the entire spectrum of emotions are expressed as combinations of Mad, Sad, Glad, and Afraid, so you can express “excitement” as Glad and Afraid, for example, but it’s always important to use these four because it keeps things clear. As an aside, diminishing these basic emotional states is discouraged (ie: “afraid” is preferred to “just a little afraid”). As with the Pass, you are expected to always remain aware of the commitments, which entails not interrupting another persons check in, or referring to their disclosures without permission. Respect for your teammates is the key to many of these protocols.
Along with checking in, in the context the Core Protocols, your physical presence must always signify and reflect upon your engagement in the task at hand. So the check out is very important: If you become aware that you cannot maintain those Commitments, then you must “Check Out.” Simply say “I’m checking out” and physically leave the group until you are ready to check in again. You have to leave the group because one of those core commitments is to commit to engage when present. As with the pass, those who are present for the Check Out do not need to be explicitly informed why the person checking out is doing so, nor should they follow him or her or hassle them for any reason. Of course, as with the Pass, this is not an excuse to simply shirk your duties at work. You should return as soon as you are able to keep to those commitments again.
So there you have it. The first few of protocols defined. It’s sometimes a little bit weird talking about teamwork in such a dry sense, but it’s an extremely self-aware way of diving into the subject matter of teamwork. Teamwork takes a lot of mutual respect and understanding. I’ll not soon forget how a small group of students in my graduating senior class constantly checked out or passed on things all the time – almost always choosing to remain uninvolved. It took a while, but I finally realized that it didn’t mean anything to me whether or not they passed or checked out for undisclosed reasons: They simply had they right to, they could, and their work progress on their game was not compromised, so other than the fact that they did not force themselves to contribute when they could not efficiently or effectively do so, nothing was changed.
Through these first three protocols, in the classroom, myself and my teammates also learned that the Check Out had a second use – creating small meetings (remember! Scrum/Agile development is all about being quickly able to iterate production: More meetings = Less product), which we found were the most efficient way to work. Conducting a group meeting of seven sound designers once took upwards of three hours – but conducting three small, simultaneous meetings of people who were engaging with the subject matter of their respective meetings could be completed in a half hour – with much more time devoted to being able to actually produce our product.
So here’s a few quick takeaways. Feel free to comment below and add your own if you find any additional usages:
- Check out if you’re not being a productive part of the meeting.
- Check out if you’ve got more pressing concerns at the moment to work on.
- Check out if your emotional state is making work impossible and check back in when you’re ready to go.
- Keep your meetings as small and concise as possible
- Be productive at all times – checking out or passing is not an excuse to not work.
Looking back, even today, it still feels silly saying “I’m checking out” or “I feel afraid. I’m in.” and hearing “Welcome” at the beginning of each and every meeting but in the context of working in a team environment, these sorts of almost ritualistic protocols offered an efficient, clear, and productive way of communicating with the rest of the team. It feels silly at first, and it was indeed difficult for me originally to grasp their usefulness, but there’s a reason that many of the Fortune-500 companies use these protocols! They work!
Hope you stick around!