My #CoreProtocol Check-in

I’ve spent quite a bit of time reading up on the Core Protocols over the last few months. They have honestly intrigued me. If you haven’t read the Core Protocols and are interested, I would suggest starting with the Core Commitment and then reading the Core Protocols. You can find the Core Commitment here.


There are some great guidelines and ideas within the Core Protocols. But while I find the Core Protocols interesting, I must admit that the I found the structure to be somewhat restrictive. After thinking about it for a while, I think my concerns fall into two general categories.

1) I see the application of the Core Protocols to be more for broken teams that are severely challenged. I don’t believe I would get as much value when I have a team that already has worked together and has trust. I could see the use of the Core Protocols if you have a severely culturally diverse team and are looking for a common set of guidelines that everyone can follow and refer to.

2) For a long time the check-in and check-out protocols and their use troubled me. I couldn’t place my finger on why. Then I realized that what I was struggling with is that the protocols seemed to put the individual and the individual’s emotions above the  team and team mates. (and possibly the client)

For Example:

1) On Check-in I can check in a state that I am sad, glad, mad, or afraid. (Or I can pass) These emotions can be about team mates, clients, or anything in general. If it involves a person, my first thought is whether they have discussed the issue with the other person first. If they haven’t, bringing it up in Check-in only provides safety for the reporting individual. For the other individuals and the psyche of the project? Not so much. Having these check-ins could have some adverse effects that could and should have been handled by one on one conversations.

2) On team mates Check-ins I can’t ask questions or refer to it in my check-ins. Once again this may benefit the reporting individual, but it limits the benefit that the team can get based on interactions and questioning between team members during check-in meetings. I absolutely love the quick discussions that happen during stand-ups that identify common issues between individuals and then create a plan of attack. The efficiency and team work is very energizing.

3) Anybody can check out at any time and physically leave discussions at any time. This can be even at the detriment of the team and the discussion at hand. You can imagine a current discussion about a key factor and perhaps a key architect check outs. So what happens now? We can’t even ask him/her why she has checked out or encourage them to return. Based on the person and the situation, the act of checking out may have created a material issue for the project. (depending when the person decides to check back in) The protocol of Check-out is different from Pass as you physically leave the room, with Pass you are still in the room but have declined to interact.


Like most methods in Agile I know there are some situations, clients, and team that the Core Protocols would probably deliver value.

I think my concerns come from a personal style preference. I would prefer my teams to strive to have individual conversations first when they have issues and to try to place the team’s goals above their own at all times. Perhaps some modification to the protocols would assist this if people needed to seek the team’s permission first before passing or checking out. I’m not sure if this would be acceptable to the Core Protocols.

At the end of the day, I feel these Protocols will probably increase one way communication, but at the expense of two-way communication. And that is where I think the magic happens. I think effort should instead be spent trying to build trust and make people comfortable to maximize the amount of two-way communication instead of implementing a structure that limits two-way communication.

Author: Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

5 thoughts on “My #CoreProtocol Check-in”

  1. Hi Terry,
    Thanks for the post. I’m glad you tried some of the protocols 🙂
    I have a couple of comments from the point of view of someone who’s been using the Core at home and at work for 10 years now. )The Core is a set of iteratively tested interpersonal behaviours that teams who have had demonstrably amazing results agreed were useful. The Core has been put to the test by teams of strangers and teams of old friends and colleagues for over 17 years now. So it’s not one person’s idea, but a crowd-sourced ecosystem of behaviours)

    As you say, adopting the Core can be very helpful for teams that need to recover their mojo – they’re “broken” as you say – or whose members come from diverse backgrounds culturally. It’s great to have a common language and mutual commitments to build on. But like top athletes, you don’t stop training just because you won the last race or you’re feeling good today. The teams we work with aren’t satisfied with just being better than broken, and they keep using the Core even when they’re great. That’s when they really begin to redefine what a great team can be. What does tend to change is the fluency, the flow, of the exchanges. And that happens because the tools become second nature.

    Your second comment is an interesting one, and I’d like to offer a different perspective. You are troubled by the Core putting the individual and his or her emotions “above” the team. What we’ve found is that teams in which individuals look after themselves as well as their teammates and the product, are more healthy and resilient, and less reliant on external intervention, than those who hide or suppress individual needs and wants. In fact, one of the big issues on most teams is trust. Revealing one’s self to others, by revealing one’s wants, thoughts, and feelings, is taking a position of vulnerability, which encourages reciprocal support. Also it’s important to remember that every person on the team is choosing this approach. If it were one person on the team putting himself above others, yes, there would be a problem. But a team which mutually agrees to use these tools can achieve a creative integrity and a healthy complexity of interactions.

    On your comments about Check In, I do have to comment about your concern that one could strike out against someone in a Check In without ever resolving it one-to-one. If you reread the Protocol itself, it specifically says, the person Checking In must not refer to or blame another person in their Check In. Terry, if you have experienced someone doing that to you or someone else in their Check In, I hope you Protocol Checked them. Protocol Check is quality control by the team to ensure safety – the kind of safety you seem to be concerned with. Check In is about revealing an emotional state so others don’t have to worry about it. And if the person actually wants to get help with it, they can ask for help after Checking In.

    Checking Out is the very best thing for a team if the person checking out would no longer be able to keep the Commitments. There is no value in the architect staying in the room if he has stopped listening, if he’s emotionally overwhelmed with anger or fear, or if he can see that the team is being unproductive and he could be better employed elsewhere. Again, everyone can check out, and are careful to be self-aware enough to use Check Out to save the team the trouble of their own presence 🙂 You could always go to the architect later and ask him your unanswered questions.

    The key with the protocols is to create a team environment in which we are each responsible to ask for help when we need it, to be transparent to our teammates, and to communicate efficiently. Thos individual conversations you want the team to have can happen just as well on a team using the Core, and in my experience, happen much more naturally and with less drama and delay. It’s simply a system of tools great teams use to be even better and I hope you’ll keep using them!

    Thanks for sharing your experience, Terry!


  2. Thanks for the comment Vicki. I really like your comments and clarification.

    I think my concerns with the Protocols are more about how I would prefer to structure team dynamics, so I don’t want to imply it is the only way. I can see situations where they would be very beneficial.

    Perhaps I need to use them more. I am still troubled by the check out protocol. I do understand that the architect may feel that he can no longer abide by the protocols and add value, but I see that trigger as a trigger for a group discussion as opposed to an exit from the situation? It may turn out that while he/she felt he/she wasn’t adding value, everyone else thought differently.

    The Check out just seems so final. I’d love for it to start a conversation like:

    ‘Hey guys, I’m not sure about the direction of the discussion/solution. Can I suggest we change the discussion in the following way?”



  3. Terry, yes I understand your concern about Check Out. It’s common in our workplaces to feel anxious when not everyone is in the room at the same time, and we’ve been taught we should all be “team players” and just talk things through. What we’ve learned, though, is that if the architect has the freedom to leave, and the team trusts him or her to do what’s best for him/her and the team, and not everyone has to be in the room at the same time, sometimes some really cool things happen: the architect is able to walk away from the conversation and get some distance, and that can allow for insights that weren’t possible in the group setting, insights that might just be breakthroughs for the whole team; the architect goes to someone else to ask for help with whatever is making him/her unable to participate, and that means that future discussions go much more smoothly; the rest of the team realizes they don’t need to have the architect in the room to move forward and that other work can take place, and they stop blaming their slow delivery on the bottleneck of a single person; the team is more productive without the architect’s inarticulate emotional radiation (fuming, incoherent anger, sarcasm, grandstanding, whatever etc) taking up the team’s time and energy.

    The first time I was on a team where someone checked out, there was a moment of shock, and then we all heaved a sigh of relief! It was better without that black hole of energy in the room. We got on with an idea we’d been deferring because he wanted to talk about other things. He went away and looked after himself and came back refreshed and with an entirely new idea which fitted perfectly with what we had been working on while he was away (one of the amazing things that happens on a team in a state of shared-vision) and we all realized how useful that one action had been for us all.

    Over the years I’ve seen the same kind of results over and over, and in fact, having seen how much wasted energy it saves the team, I look for a Check Out much earlier than I did in the beginning. Sooner Checked Out, sooner Checked back In!

    I’d love to hear more about your experiences with the protocols and commitments!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: