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)
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.