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.

#Agile means never saying never and always saying maybe – #Agile #Inertia

Recently at a few Agile discussions I have noticed people saying things like:

“You should never provide estimates”

“You should never start to code without automated tests”

“You never need Business Analysts or Testers”

“You should never create requirement documents”

To me, Agile at its heart is always seeking to understand first. Many of these absolutes are diverging from seeking to understand. They even remind me a little of the waterfall method and the absolute rules that were in place that defined the mandatory deliverables that needed to be in place.

Now while I would agree that most of these statements are true most of the time, if you are not modifying your approach with each and every situation and client, I would suggest you are not Agile. If you are executing iterations and you can’t respond to a request from the client on how you execute iterations, then you probably aren’t Agile. If you read the book of Agile and can’t respond to a client request to have requirement traceability, then you probably aren’t Agile. Remember that Agile is being able to deliver the most value to the client and the client defines that value. Not you, not the Agile Manifesto, not bloggers, and especially not me. 🙂 defines Agile as “quick and well-coordinated in movement”. The antonym of Movement is Inertia. If you have Inertia to move, change, customize, or adapt Agile methods, then I would suggest you are not Agile. To be Agile, you need to be without Inertia. Is Agile Inertia better than waterfall Inertia? Of course it is. But it is still Inertia and it is preventing you from delivering maximum value to your client.

Without Inertia means you are able to move between situations based on what fits that situation. Perhaps that is why I have problems with Scrum and the Core Protocols. I don’t think either provide the freedom to allow people to be truly Agile to tailor the approach to best fit the client and deliver the most value to the client.

If you have been delivering multiple Agile projects using the same methods and procedures then I have some bad news for you. You may have developed an acute case of Agile Inertia. In fact if you have been delivering subsequent iterations using the same methods and processes then you probably have a mild case of Agile Inertia.

Sadly there is only one cure for Agile Inertia. Never say never and always say maybe.