The Core Protocols, an Experience Report - Part 1
Yves Hanoulle, www.hanoulle.be
Somewhere in a bar at a European Agile conference.
Yves turned his head to the voice, but did not answer back.
She continued, "I played your leadership game a few years ago."
Yves who, had run the session at a dozen agile conferences, frowned in an effort to remember her name.
"At that moment you were about to leave for a McCarthy BootCamp. You were both excited and afraid of doing so."
Yves kept silent for a second.
"Will you spend some time with me and share your experience?" she asked firmly.
Yves replied, "Hi Allison, glad to see you back. I'm delighted you remember that. Yes, I will!"
After a little pause, Yves continued, "The week after we talked, I went to a Core Protocols BootCamp in the US. Before I share my experiences of that week, and of using the Core with teams in the five years since, let me start with a little history of the Core. Where you in the session yesterday about high performing teams?"
Allison: "yes, as a CEO I want to know how I can turn my company into a high performance company."
"High performing teams have been a big buzzword in IT over the last 20 years," he reminded her. "Although everybody talks about this, there is limited experience in how to create such high performance, results-oriented, successful teams. Luckily for us, Jim & Michele McCarthy created an experiential workshop in 1996 to learn about it. Over the last 14 years, they have recorded communication patterns (they call these the Core Protocols), that help create high performance teams."
Allison turned silent for a second, but she kept looking at Yves. Interest had sparked in her eyes. Something else, not so nice, also. "That is quite a strong statement," she merely said.
"Yes, it is," Yves answered. "And I had my doubts when I first read about these patterns," he quickly added.
"So is it the silver bullet they claim it to be?" She might have been cynical, but there was no trace of it in her voice.
"Mmm," Yves mumbled. "I don't believe in silver bullets, but I do believe in tools and techniques that I can use to help teams. When I first read about these patterns, although I liked them, I found all sorts of excuses not to use them," he remembered. While she looked away, as if she was now in some other universe, Allison said, "That reminds me of the people I encounter who are afraid to use or start using agile." As this was exactly what he was trying to say, Yves knew they were connected. He continued, "When I realized that, I said to myself it was time to get outside of my comfort zone. As some of these patterns were so different from what I was used to, I needed to have a safe place to experience them. I was too scared to try them out in a team, or even talk about them." She smiled again as she teased him, "So that's why you did not want to answer my question back then."
She was right and he knew it. "Yes. That's why I'm really happy you have asked me this question again. Let me see, where should I start?"
"Yesterday, Jeffrey said that teams needed a shared vision. Do you agree with him?" she tried to link what she already knew and this new stuff. "
Great question," Yves felt the adrenaline, and he continued, "Indeed, a lot of management books talk about having a shared vision for a team. Often people (like Jeffrey) make the mistake of thinking of such a vision as a vision or mission statement."
Surprised by his answer, Allison asked, "You don't think the exercise where Jeffrey told us to create a vision statement helps to focus a team?"
Yves remembered his resistance for the exercise, "That's correct, for me a shared vision is about a state, not a statement. And having management creating a statement for a team is even worse."
"Shared vision is a state, not a statement," she tasted the sentence in her head. Yes, it felt right. Yves continued, "What I learned from BootCamp is that a true shared vision is the state where a team all thinks in a direction, sharing a picture of a desired future."
"People thinking the same; don't you want diversity in your team?" she asked.
"No, no, thinking in the same direction is not thinking the same," he replied quickly. "Let me tell you a story to clarify this." He knew this was hard to understand. "When I organized a BootCamp in Europe, I arranged an interview with the trainers and a business magazine. As I walked into the interview room, I told Paul and Vickie (the trainers) that my most scary idea would be to ask Benny (the reporter) to join us on Friday when the team had to deliver their BootCamp results. Halfway through the interview, I got a phone call from the team (that was out on an adventure), 'Yves, will you ask the reporter if he wants to join us on Friday...' That is an example of being in a state of shared vision. This particular shared vision was created by working together over the course of three days."
"Three days, gee, they must have been lucky," Allison thought skeptically.
As if he knew what she was thinking Yves added, "I have seen examples of a shared vision state in all the BootCamps in which I have participated."
"Creating a shared vision state in a repeatable way?" Allison could hardly believe what she was hearing. "Wow, that sounds powerful. Tell me how this is done."
Yves, who knew how unrealistic this might sound to people who did not have the same experience, felt it was time to get to more practical examples. "Patience my dear Watson. Before I can do that, we have to look at the basics. The behavior patterns (called Protocols) of the Core."
"Then, let's find some seats," said Allison. "I'm tired of standing up with my drink in my hand, and something tells me I want to sit down for what you've got to say next!" After her initial talk with Yves, she had tried to read 'Software for your head' and although she had given up, she somehow felt she would like the Core.
"As a coach, I give feedback to teams and individuals all the time, and as I currently see the Perfection Game as the most powerful way to give feedback, the Perfection Game is the pattern I use most."
Allison, who had been reading his blog, said, "Yes, I've noticed you use it a lot."
Yves, surprised that she knew the Perfection Game, saw that as an opportunity to do a little experiment. "Let's try it out right now. Will you perfect this conversation?"
This unexpected shift made Allison catch her breath. She looked down. She had read his posts, even printed out the Perfection Game, but she had never actually done one. And now this expert was asking her to perfect this conversation. She hadn't even had time to think about the conversation. Hey, they were only talking for five minutes.
Yves waited, he knew it was quite a challenge for someone who had never done this. Especially because he had not repeated the pattern of the game with her. He had done that on purpose, so he would be able to see what parts she understood and what parts were still unclear.
She looked up. She came to the conference to get out of her comfort zone. Yves seemed like a nice guy, and he seemed to be determined to have her do this...
"I'm giving this conversation a 6 out of 10. What I like about it is:
-you are taking time to talk to me,
-you seem to have become even more passionate about the Core as I saw before,
-you are making links between the Core and the agile stuff I know,"(Allison felt it was going well)
"To make it a 10:
-we should take time to talk about all the core protocols,
-I want this conversation to be fun,
-I want to see links with Scrum,
-I don't like the military name BootCamp."
Yves interrupted her, "Protocol check." Allison facial expression showed she never heard of that before.
Without missing a beat Yves continued, "In a Perfection Game, you are only allowed to say what you want to have, not what you don't want."
"Damn, I knew that." Allison's mind raced fast, "OK, let me rephrase that last sentence. I want to understand why it's called a BootCamp."
Yves felt happy. "Cool, you seem to get that one. Any questions?"
That remark annoyed Allison. "Aren't you going to reply to my remarks?"
Yves realized that he had gone too fast. "No, these are your ideas. Even if I don't agree with something, they are still true for you. They help me when I create a new version of what I asked you to perfect. In this case, I will in the next parts of the conversation remember what you said and use some of your ideas."
Now Allison really was not happy. "Some, not all of them?"
He tried to ignore her mood; and replied monotone, "No, not all of them. When I don't like an idea, or don't know how to apply that, I leave it out." He paused.
That seemed to have calmed her down a bit. "Please say more."
Yves felt an example might do the trick. "For example your idea of Scrum. I prefer not to link Scrum and the Core protocols."
Allison started to mirror Yves' teasing style. "Why not - they don't work together?"
Yves was clearly amused by her remark. "Haha, no they do. I see them as different tools in my toolbox. When I explain one, I leave the other out as I think it will confuse my audience."
Allison felt both happy and sad. Yves seemed to have an answer to everything. She said (as calmly as possible), "OK, that's fair."
For Yves that was a sign to push her further. "Will you tell me, why did you rate it a 6?"
"Isn't that obvious, I had 4 ideas: 10 minus 4 is 6," she said, surprised by his question.
"That was what I was afraid of," Yves quickly replied.
"What did I do wrong?" Allison's voice sounded upset.
Yves ignored her emotion and told her, "The number you subtract, should be about the value that your ideas have to you."
"I can't do that!" Allison's voice now sounded shrill.
Yves: "Why not?"
You could hardly hear her voice when she said, "That number is too high."
Not surprised by her answer he asked, "So you are telling me, you can't give me a low number?"
A little louder she said, "Yes."
Clearly amused, Yves asked again, "Why not?"
"Why not? Is he laughing with me? I avoid humiliating him and he laughs with me." Allison was really confused now. "I liked the conversation so far, giving a low number would give the wrong impression."
"Aha!" Yves slapped his hand on the table, "That is another misconception about the Perfection Game. The Perfection Game is not an evaluation. It's a feedback tool. A feedback tool to communicate ideas."
Surprised she said, "So you won't feel bad when I give you a low number?"
Yves smiled. "That's correct. Please tell me what your ideas are worth to you."
I hope he means it, she thought as she said, "Then I give this conversation a 2 out of 10."
Yves' smile doubled. "Wow, that's nice."
Allison turned away, "you see, you feel hurt."
"No!" Yves said firmly, "I said: that is nice."
Allison replied, "Yeah right, we both know that was sarcasm."
Yves refuted, "No it was not. I'm really happy you gave me ideas that for you are worth 8 out of 10."
Allison looked at him as if he was from Mars. "Boy, you really are strange."
Yves agreed, "Thank you. Let me go over the format."
"As you noticed, there are three major parts in a Perfection Game:
-a score from 1 to 10,
-things you like; what you liked about the thing you are perfecting,
Allison: "Why is perfect a goal?"
Yves: "Great question. It's not. Although the name seems to insinuate we strive for perfection, the game is more for finding idea's to make things better. I would have preferred the greatness game."
Allison wondered, "That score: how do you deal with that with people that have no experience with this?"
"You mean what to do with people who still feel they are evaluated as a person?" Yves asked.
"Yes," she nodded.
Yves: "As a coach I usually start with a score of 7 out of 10. That is, I am aiming to give improvements worth 3 out of 10. When I'm listing my improvements and I feel my improvements are not worth 3 out of 10, I adjust my score. At XP days Benelux, the Perfection Game is used in its original form, to improve the proposed sessions for the conference. A lot of speakers appreciate this kind of feedback. I have seen the Perfection Game being adopted as a kind of evaluation. That does not work. The Perfection Game was intended for improvement and not for evaluation. Mixing these two does not work. That is also why the third part is improvements, and not things we don't like. It's very easy to come up with a long list of things we don't like about everything. To come up with a small list of improvements is a different thing." Yves paused for a moment to make her think about that last message. Then he added a last remark, "That is why for me, using the Perfection Game is a serious engagement."
While she ordered some more drinks, Allison asked about emotions. "I spend eight hours a day at the office. That is at least the same amount of time I spend with my family. Some people claim we should leave our emotions outside the office and behave professionally. I can't do this. And when I try, I lose all of my creativity."
Yves could not agree more. "You are right, that is impossible to do. For a long time I have been puzzled about using my emotions in a smart way inside the corporate world. And then I learned about check in, and a new world opened. Let me now start with an example:
I’m checking in:
I’m glad you asked me to talk about the Core protocols,
I’m mad, sad, afraid I might be in my bed late again,
I'm sad I miss my family,
I'm mad I forgot to call my kids today,
Yves turned to her and asked, "So, how do you feel when you hear something like this?" Yves waited a minute or two to let her reflect, then he continued, "Let me tell you about my first reaction. My first reaction when I learned about this was 'Wow, that is powerful'. My second, 'This won’t work with me for …'."
Allison nodded. "Yes, it won't work in -"
Yves interrupted her. "My team, my company, my country. Give me any reason  why it won’t work in your team, your company, your country: I had them all. Let me tell you about a chat I had with Michele. At that time I was already convinced it would be a good way to communicate with people, it might even work with children, but not yet with my children; I considered them too young. Michele McCarthy told me to try it, and then we could talk again. (For her it had no sense, that I would say, 'No, it does not work', without trying it.) I’m not sure what I thought at that moment, not even sure if I wanted to try at that moment. The very next day, Joppe, three years old, came home with a self made card. On that card were listed the four basic feelings (mad, glad, sad, afraid). Joppe had learned something like check in at school. That day, I realized that I was blocking myself from using a powerful tool with my kids. Since that moment, I check in with my kids, when I put them in bed."
Allison moved by the story, wondered how it would have been to check in with her father. "Tell me about the format of the pattern."
"The first part, 'I’m checking in'," Yves explained, "that sentence asks for attention, telling you I’m going to disclose my feelings, please pay attention. An alternative that is used in a team setting is 'Let’s check in'. Here you check in, but you also ask everyone else present to do the same."
Allison asked, "Why are only four feelings allowed? I have more then four feelings!"
"Great question," Yves answered. "You are correct; only four feelings are allowed. More complex feelings are actually a combination of these four. Yes, it is harder when you are limited to only four feelings. You won’t hear me say the Core Protocols are easy. They are simple, not easy."
Allison tried if she could fit her complex emotions into these four basic emotions.
"That last sentence, 'I’m in', tells the people that I’m finished." Yves added, "The response to this is 'Welcome'."
"'Welcome'? That makes me think of AA or therapeutic groups I saw in movies," she complained.
Yves looked at her and said, "Get over that. When you do this, you will realize that it feels really nice to be welcome in a group. I guess that is why they do that in these groups."
Allison wondered, "Isn’t it scary to do this at work?"
Yves honestly told her, "Yes, it is scary to check in at work, especially as a coach with a new team and yet the only advice I can give, is to try it."
Allison - still not convinced: "The format seems rather rigid. Do I have to use it like that?"
Yves reminded her about a rule that works great for all agile methodologies and tools." I advise people to start using these patterns as described, then when you are good at it, you can be more flexible. When things get tough (as they always do), you should be stricter again." You could feel Allison was already more convinced as she asked, "When do you check in?"
"That's easy," Yves replied, "Every time you feel the need. In a well running team, people check in multiple times a day."
"If there is a check in, is there also a check out?" Allison wondered.
Much to her surprise, Yves said, "Yes, there is. My partner introduced me to check out, 13 years ago. When we had a discussion that became too heated, she left my house to go for a walk. I was very frustrated with that at the time. It took me a few years to understand I was not frustrated that she left the conversation; I was frustrated that we did not restart the conversation when things cooled down." Yves was now really in a flow. "A check out goes like this: Whenever you feel you are not capable of adding something valuable, you say 'I'm checking out' and you leave the room. There could be all kinds of reasons for this: like being ill, or being too angry..."
Allison added, "This would be good for those companies that focus on being present and not enough on being productive." Yves agreed. "I prefer that everybody being present is a person I can count on, over counting on everyone being present. I like the visual management of being able to count on the people that are present." After nipping from his drink, Yves continued. "I use check out personally as a kind of personal time out (you know the kind of time-out I ask my kids to take when they behave badly). I know coaches who use this when they feel that their body is not OK (migraine etc).
In those companies where being present is more important than working, I see people going to cigarette breaks, or the healthier long toilet visits to have a check out. It's much nicer if people can do this officially.
Allison said, "But what if something has to be done?"
Yves replied, "Well, if people are able to do that, they will. If not, forcing them to stay won't help. (It will actually make things worse as the people not checking out will limit the result of the people that would be able to do the work.) On top of that, a five-minute break can make people 35 times more productive than if they would not take that break. It is a good practice when you check out - that you mention when you intend to come back (if you know). When you check out, you should leave the room immediately.
"Like the law of two feet in Open Space technology?"
"Actually, I think its law of two feet and check out are completely the same. During one of my BootCamps, I needed to finish a report about another training. I did not want to miss anything so I wrote the paper in my team room. That was a big mistake, I should have checked out. I was not productive for my team, and I gave them the message that integrity was not important.
Allison looked astonished. "I'm surprised to hear that, I saw you leave multiple sessions this conference."
Yves: "Yes, that was something I learned at that BootCamp, I have been much more productive since then."
Allison wanted to get moving. "What other patterns are there to learn?"
Yves: "Let's talk about ask for help. In the daily standup of a Scrum, we answer three questions. The last one is 'are you blocked'. I tell the teams I'm coaching, it's really 'where do you need help?'"
Allison: "Does it really matter? Most teams don't even bother about that last question." Yves: "I'm not surprised that most team members don't answer this question. In school we learn to do everything on our own. (Working together in school is called cheating.) In the IT industry, asking for help is even worse; I think this comes because we feel we are paid because we are smart, intelligent. Somehow, we think that being smart means not asking for help. Well, I've got news for you. That is not true. Asking for help is really a sign of strength."
Allison: "That could be true, but I have been working with a guy that was a total idiot and he kept asking for help, and did not learn anything."
Yves agreed. "I guess that 'I do not want to ask for help, as I don't want to look like this guy' is another reason why people don't ask for help. Guess what, that guy is a real exception, a lot more people make the opposite mistake. The typical situation being a male driver preferring not to ask for help and continuing to drive even when he does not know where he is. Rachel Davies told me recently she would also drive for 10 minutes before asking for help."
"So it's not exclusive behavior for you men?" Allison said with a wink. "Did she also say why?"
Yves answered, "Yes, for her it was not so much that she thinks she will look foolish asking for help. However she does not want to bother people if she can work it out herself. She also added that sometimes it takes a while to realize she got lost. Just as it might take people two or three days to ask for help in their team. Recently Dave Nicolette blogged about a similar experience with some very mature agile coaches that forgot to ask for help during the first certified developer Scrum course."
Allison: "Ok, then when should I ask for help?"
Yves laughed. "Whenever you feel blocked."
Allison: "What if I don't know where I need help with?"
Yves: "Especially then you should ask for help. It feels scary, but the most powerful instances of help I have received, are those when I had no idea I needed help but still asked for it."
Allison: "The previous patterns have a strange format. What about ask for help?"
Yves: "Use 'will you' instead of 'can you'."
Allison interrupts him. "The managers trick."
Yves reacts surprised. "Please say more."
Allison continues. "My first manager never asked 'will you do this'; he always asked 'can you do this', because he knew people would quickly say 'yes'. Of course they can, even when they don't want to."
Allison wonders, "What if I don't want to help?"
"Then you say 'no'." Yves adds, "An ask for help is only valid, if the other party has the right to say 'no'. Without a possible 'no', a 'yes' has no value." Yves proceeds. "When you know that people will ask for help when they need it, it also removes the urge to rescue people. When I was young, I had a hard time asking for help. I learned that behavior because in my environment people rescued other people before they could ask for help. Sometimes agile coaches think that rescuing is the same as helping. It's not. And it teaches people not to ask for help. So basically you make them more powerless. During my first years as a parent, it was hard for me to know the difference between helping a helpless child and teaching them to ask for help. (Which is helping them in the long run.)"
While Allison - who had a ten and a seven year old - grabs her notebook, to jot down a few sentences about this, Yves moves on to the next pattern. "Imagine the next situation, you are in a meeting and after I said something, someone else takes over and says something like:
What Yves says, has a lot of value, remember last year when we released supergizmo 364, customer babelstone had similar situation as what Yves describes. And on top of that, we should not forget that our company goal was to optimize the ROI of our department. And by consequence deploying our system that does what Yves described, we do precisely that. So I propose that we consider that option."
Allison gazes at Yves, confused by the unclear conversation. Yves, amused by her reaction, clarifies, "Let me translate this:
BlahBlahBlah, I would like you to hear my voice, as for me it is important that you think I am important. And blahblahblah.... I agree with everything that was said."
Yves looked at Allison and asked, "Is this a pattern (or better an anti-pattern) you recognize?"
Yves continued. "Imagine you have a meeting with 10 people. Five of these people each spend five minutes talking like this (usually in a group, once a person talks like this, a lot more people adopt the same behavior, so it's probably more then five)."
Allison calculated, "That is 25 minutes for 10 people."
That is what Yves wanted her to realize. "Now imagine that instead of this, you quickly make decisions. Would you not like this?" He did not wait for her to answer his rhetorical question. "Decider offers this possibility. Let me give you an example of a Decider:
Christophe: I propose that we publish our French customer documentation to our website at 12:00.
Everyone shows his or her hand
Christophe: thumbs up
Gino: thumbs up
Sylvia: flat hand
Rachel: thumbs up
Alistair: thumbs up
Linda: thumbs down
Christophe looks at the group and focuses on Linda: Linda what would it take to get you in?
Linda: If want to be sure we have enough time to remove the spelling mistakes Bernard found this morning.
Christophe does an eye-check with everyone in the team and says: I'll change my proposal to 12:30. Proposal accepted.
Allison, will you tell me what happened?"
She accepts the challenge. "Christophe made a proposal. I'm not sure - was this after a long conversation?"
"It could be, but in general, everyone makes proposals as soon as possible."
Allison asks for more clarification. "So then he counts to three. Why did he do that?"
Yves explains, "The reason we do this, is to make sure that everyone votes at the same time. It might sound silly but if you don't, people look at each other and will vote what other members vote."
Allison continued. "The voting had three outcomes, will you explain them?
Yves: "Yes, I will. Thumbs up: I support your idea and I will do everything to make this a success. Flat hand: I don't have enough information to support your idea. Thumbs down: I can't support the idea like it exists now. It needs some changes. If the proposer thinks that the change is too different from his proposal, he says the proposal is dead (not accepted). The same is true if you have too many flat hands (you need enough people that support the idea).
Allison, puzzled, asked, "When I have a better idea, what should I vote?"
Yves smiled. "When you think you have a better idea, you vote flat hand and after the first proposal is accepted, then you propose your better idea. This has..."
Allison interrupts him, "I want to be sure I understand, I propose my better idea after the first proposal is accepted, not when it's implemented?"
Yves agreed, "exactly! This has the advantage that proposals get accepted and we create a momentum. Even if your new proposal is not accepted, at least we have the first proposal that is accepted." This creates a bias towards action. If you vote thumbs down and you propose your own idea, we might end up with pingpong proposals and nothing gets accepted.
Working in this way, means that a team does not block itself from taking decisions even if they think they can come up with a better idea later." It's ok to have better ideas later. We will do a new decider and we'll switch to the new idea (when people find it better). In 'lean' we want to defer decisions to the last responsible moment. The problem I see with this is that for most teams it's hard to find that last responsible moment. On top of that, I see teams block them selves from taking decisions and actions by doing this. So in reality they take no decision, which is worse and which is also waste, waste of time. Using decider to quickly take actions with the possibility to re-decide later (when we have more information) is for me in sync with take decision at the last responsible moment."
Allison: "What if the decision you have to take is a difficult or expensive one to change once it's made?" Yves whistles, "That is a great question."
Yves turned to Mary Poppendieck who was listening into the conversation, "will you answer this one Mary?"
Mary, "Yes, I will. The goal in Software Development is first of all to make all decision changeable. (Decoupled architecture, test harnesses etc.) But when a decision is permanent, it cannot be easily changed, and when that decision is also critical to success, you do not want to make it early, instead you want the team members to decide when they will decide. That means the teams comes to an agreement on when the last responsible moment is, and then when that moment comes, they make the critical, difficult-to-change decision."
Yves relaxed. "I could not have said that better. Remember that first meeting with these same 10 people, imagine that I would have proposed my idea and that we had voted on this. We would have won 25 minutes for 10 people. That is 250 minutes."
Allison: "That is half a working day."
Yves: "Yes, Imagine winning half a day in every meeting. How do you feel about that?"
Allison: "That would make me feel a lot better about meetings. What about aligning people in meeting? And getting to know each other in these meetings."
Yves: "I agree alignment is important, for that you should use the alignment protocol. Actually having your team taking decisions helps them much more for understanding the purpose of the team. For getting to know each other, the earlier check in is a lot better. I had teams take five or six decisions in less then 10 minutes. And then they go off and continue making software. Imagine what this does to your productivity. (And moral, as most software developers hate unproductive meetings.)"
Allison asks, "Meetings are the cornerstone in my company, can you give some more advice about optimizing our meetings?"
Yves: "I'm about to have a meeting with Christophe and Bénédicte to organize the next BootCamp. If you want, you can observe the meeting."
The next passages are the notes that Allison took while observing the meeting.
Christophe starts the meeting:
Christophe: Let's check in. I'm glad that we have this meeting to decide about a next European BootCamp; I'm sad we do this over the phone, I'm glad I hear your voice. I'm in
Bénédicte, Yves: Welcome.
Yves: I'm glad we talk, I'm glad to meet Bénédicte, I'm afraid to have such an important meeting over the phone, I'm glad to know that the core will help us, I'm glad Christophe keeps pushing me for a next BootCamp. I'm glad, sad, afraid my priorities were elsewhere before. I'm in
Christophe, Bénedicte: Welcome
Bénédicte: I'm glad I finally meet you, I'm glad I see things moving. I'm in
Yves, Christophe: Welcome
Christophe: We disclose what we want. I want to know when the next European BootCamp will take place.
Yves: I want to understand how many people are really interested in a next European BootCamp.
Bénédicte: I want to know if my idea for a place for a BootCamp is a good idea.
Christophe: Alignment check, where are you compared to your goal: I'm at 7 out of 10.
Yves: I'm at 6 out of 10
Bénédicte: I'm at 2 out of 10
Christophe: Bénédicte, as you are the lowest, you start.
Bénédicte: I understood that almost all European BootCamp took place in Koningsteen, Belgium.
Bénédicte: Is there an option to do that in another place?
Yves: Yes, there is. We keep working with Koningsteen as it is a great environment where we know we can do everything we want. We selected Belgium as it is rather central in Europe. Will you tell me what other place you had in mind?
Bénédicte: Yes, I was thinking about Domain de Soulignac en France.
Yves: Will you tell me some more about the Domain?
Bénédicte: Yes. At the heart of the Limousin, ...
Yves: That looks like a great place. I would love to try this location.
Christophe: Alignment check; I'm at 5
Bénédicte: I was at 10. I have a new want: I now want the same as Christophe wants. I'm at 5.
Yves: Ok, let' see when we can do this. Do you want English and French speaking trainers?
Bénédicte: Yes, some of the people I know can speak English but they would prefer a French speaking trainer.
Yves: Then the first available option is September. What week in September can we do this?
Bénédicte: I would prefer the second week of September.
Christophe, Yves: Yes, that is possible.
Yves: Cool, we do the next BootCamp from the 5 September 2010 till the 10th.
Alignment check: Bénédicte: 10, Christophe 10, Yves 6.
Bénédicte: I have what I want, I'm checking out.
Christophe: Yves, you wanted to know how many people where interested.
Christophe: Well, we have three people from my company, plus me, we have Bénédicte and five of her friends. How many people is the minimum you need for a BootCamp?
Yves: Seven is the minimum number to learn about group dynamics in one week. I have seen it work with less people, but that where people that were already a tight team before.
Christophe: We have nine people, that should be enough?
Yves: Yes. And I know some more to contact. Looks like we have a new BootCamp ...
Alignment check: Yves 10, Christophe 10
Yves: I have what I want, I'm checking out.
Christophe: Yes, so do I, thank you.
Yves: "You heard a meeting where people used the meeting protocol. Will you tell me what you saw?"
Allison: "Christophe started the meeting, by doing a group checkin. Then everyone stated what she wanted out of the meeting. With a score from 1 till 10. Nobody talked about time constrained. Is that the moment to talk about?"
Yves: "Yes, after the check in, that is the right moment. It is one of the improvements important if you do the meeting over phone or chat. People tend to not do it when face to face as all these meetings are on our calendars."
Allison interrupts, "so why aren't you all at 0 at the beginning?"
Yves, "oh , good observation, I was not at 0 because I had been talking to other people, so I already had an idea how many people where interested, does this answers your questions?"
Allison, "yes it does. Then you started by the person with the lowest score. Why did you ask everyone what he wants? If it is my meeting, I want to set an agenda!"
Yves: "That is true and we want to make sure we address the most important issues concerning this topic. If everyone has to organize his own meeting to address an issue, we now have 10 meetings. (Did I mention already that we schedule our meetings for at least an hour?) The meeting protocol offers us a way to have 10 productive meetings instead of one. And yes people are smart enough to only bring topics related to the goal of the meeting."
Allison: "What if I have no goal for this meeting?"
Yves: "Then why are you in this meeting?"
Allison: "Well, I don't know if my input is needed to solve an issue in this meeting."
Yves: "With the meeting protocol, you will know at the beginning if you are needed or not. And if not, you leave."
Allison: "Yes, I noticed that Bénédicte left halfway the meeting, once she had what she wanted."
Yves: "You can stay if you think someone needs your input in the meeting. (If you always stay and nobody actually needs you, your goal probably is: 'I want to feel needed by the team'. That goal will never be reached.)"
Allison remarks, "haha, this conversation is as funny as I hoped it would be. Earlier you talked about Personal Alignment will you tell me what that is?"
Yves closed his eyes, "No, I will not do that now. I'm too tired and I need some sleep. Why don't we get together tomorrow and continue our conversation?"
Allison: "I propose we see each other at 10 am here in the bar, 1,2,3".
Yves showed thumbs up and said, "That is a deal."
Allison laughs while she said, "Protocol check. You are not supposed to talk during a decider."
The conversation of the next day will appear in the next issue of Methods and Tools.
Allison and Jeffrey are fictive persons. This conversation is based on talks that Yves had at agile conferences the last five years. The meeting between Yves, Christophe, Bénédicte took place in 1st quarter 2010 over the phone. Although the transcript was edited, this was how this 30 minutes conversation went.
Yves asks one agile coaching question every day on http://twitter.com/Retroflection . (Questions created by John McFayden, Dusan Kocurek, Martin Heider, John Gram, Deborah Preuss, Christopher Thibaut, George Dinwiddie, Diana Larsen, Ine De handschutter, Yves Hanoulle, you ?)
This article was written with the help from Jim & Michele McCarthy, Els Ryssen, Paul Reeves, Christopher Thibaut, Adam Feuer, Ralph Miarka, Mary Poppendieck, Gino Marckx, Alistair Cockburn, Philip Almey, Lilian Nijboer, Esther Derby. A big kudo's to Emmanuel Gaillot who initiated the conversational style. Another thank you to google docs that made it possible for this international team to have +3000 revisions.
Yves gives free life time support on this article: send your questions to firstname.lastname@example.org If you want more people to respond, you can connect to the CoreProtocols user group: TheCoreProtocols@yahoogroups.com
 Feel free to mail me your reasons why check in or any other protocol could not work.
Related Methods & Tools articles
Back to the archive list