Tim Schraepen's Blog Yet another developer blog.

Event Storming for realz

After last times Event Storming exercise I was anxious to do it again. And as luck would have it, an opportunity arose soon after.

Friend and colleague Tom Toutenel asked me if I could facilitate an event storming session for one of our newly won clients. I was of course, happy to oblige.


Tom explained that his team wanted to pick the brains of our client so they would get a shared understanding of what they need to build. Preferably in a “Storymap”. And if possible, define a first “Story” to start their sprint in the week after the storming session.

Another noteworthy fact: a considerable amount of effort by the client had already been put into making a thorough analysis of what needed to be done. Eventhough this effort is worthwile, this prompted me to make sure that the group wouldn’t limit themselves too much by the obtained knowledge.

Preparation is half the battle

As you might imagine, I wanted to prepare properly since I’m dealing with an actual client. So I revisited my previous blog post, more specifically all Alberto’s answers. And I checked the notes I had written down the first time I tried event storming again.

Pointers I wrote down

I’ve been using a mini todo-board in my “journal” with mini post-its and the tasks I made for myself were the following:

  • Have Stickies, Sheets and Sharpies for every participant
  • Prepare room (I had no paper roll, so I put 15 sheets of flipchart paper in “landscape mode” up on the wall using painters tape)
  • Introduce yourself
  • Check the groups expectations
  • Give context: EventStorming = What?, Tackle specific problem
  • Put up Events; past tense, start in the middle, extend space if necessary
  • Is Domain Expert interested in Event x? (To solve issues with granularity)
  • Put up Commands + external systems (note to self: look for hotspots)
  • Event to Event is ok: “Person had a birthday –> Person reached pensionable age”
  • Take note of gestures (“moving”, “pointing”, “cutting”)
  • Make UI cards with screens if helpful
  • Ubiquitous Language!

Silence before the storm

As I was preparing the room with flipchart sheets and “superstickies” that would serve as the colorcoding legends, I got a little nervous. I managed to get a little mental checklist loop going to gain some confidence:

  • Are they stuck in the same discussion?
  • How are we doing on time?
  • Is everyone still interested?

Introducing: the participants

In the blue corner we present to you our client, a big contender in belgians electricity market, bringing in a total of 3 persons.

I picked different names, to preserve their anonymity.

  • Lommy, the functional analyst.
  • Leonard, the architect.
  • Lionel, the project lead, aka the product owner.

And in the red corner, hailing from camp Cegeka.

I did not make these up, these are their actual names. A trio of Toms. A TomTrio. A Tromio?

  • Tom T., the team lead.
  • Tom C., the scrum master/customer proxy.
  • Tom B., the developer.

All these people are going to work together in the hours ahead, to create a shared understanding of what problem they want to solve together.

No hiccups

After explaining who I was, and what my role was going to be in the next hour(s), I explained Event/Model Storming in short and what the rules of the game were. Everyone then proceeded to post Events on the sheets of paper. No buts, no arguments, everyone was in the same boat and understood the value of having a shared understanding. Yay, open-minded humans!

There were only a few instances in which Events were not in past tense, and those were quickly fixed once I pointed it out.

Lommy, the functional analyst, went back-and-forth between stickies and his laptop. This told me that he was posting events that were a little bit biased. Most of the time though, other participants had already posted similar events. Which confirmed understanding of both participants and informed me that this bias was negligible. He IS the Domain Expert after all.

Ubiquitous Language

Especially after they started posting External Systems it appeared that there were some issues in the word choice. It appeared that naming External Systems and their actors went particularly well and was clear to everybody. However, once events came in to the problem domain, wording started to get a little fuzzy. Lommy, Leonard and Lionel were all using different words to describe the same events. Which caused a lot of confusion for our Tom Trio.

This is where I noticed immediate benefit of Event Storming: stuff like this usually only appears when you get to that bit of the solution.


As the story started to unfold before their eyes, there was some things that were still unclear and appeared literally outside (off of the paper). I added big exclamation marks on differently colored post-its to make it clear. And every so often, we came back to these hotspots and discussed some more about them. Further more, Lommy knew about these problems, but the rest of the team did not. Excellent learning happened right there, and you could feel the group getting excited about that fact.

One hotspot was about an “edge-case” that appeared to be more important and really couldn’t be considered an edge-case anymore. Marking it as a hotspot also made that more clear.

Talking about an external system also lead to some confusion in ubiquitous language, in that there were different terms being thrown around in relation to the external system (and external actors). They came back to these terms often enough that it warranted a hotspot. I like to think that doing this kept this issue in the back of the heads of the group.

Facilitating “aha-moments”

Aside from the hotspots building confidence in the session we were doing, there were also some other moments that elevated the group to a higher level.

I noticed they were grouping together near one particular part of the line and mentioned that I noticed this while querying “Is this the core of the problem domain?”. I could see them reflect on that a little bit and then unanimously went “Yes! Cool! :D”.

It really felt like the more positive experiences the group had, the better they got at talking to each other and working together at building their shared understanding. It was supercool as a facilitator to see them grow like this.

Adding Contexts

So, I don’t know if this is a good thing to do, but I thought it’s worth mentioning at least.

At some point, someone started noticing that in the time-line that was drawn out, there were some natural groupings that were showing. We decided to name them contexts and hang them up above their location in the timeline. It made some ideas more logical to think about, and caused some events to be shifted into their context. They then also tried to map the contexts to the analysis that Lommy had prepared. But for Tom C., it was getting too fine-grained. Another thing that this facilitated was more discussion on Ubiquitous Language, leading them to declare “This will help us to make the story map more clear, later”.

Lastly, delineating the contexts also gave a good impression of how big those contexts were. This showed something interesting in that there was one context that contrasted a lot in terms of sheer amount, to another context. Upon announcing that observation, they explained that eventhough that other context was much smaller, it was actually more complex. And the reason why they did not have a lot of cards there, was simply because the right people (that had the knowledge of that context) weren’t there.

After we did that the road to storymapping was set and we added some “Shared Language” (the pink post-its in the photo below) and things that could be “Stories” (the purple post-its in the photo below). They didn’t go very far into this because this could be done after, and they felt that they already gained all the extra insight they could get from doing this additional step.


After about an hour I started asking if they wanted to continue the exercise every time the discussion seemed to die down or get stuck. They naturally went back into the discussion when it was interesting enough for them to continue, and other times they jumped to a different topic.

I consider this exercise to be a successful one, eventhough we didn’t get an initial story out of it. In the end I got positive feedback that it was very useful for them. The three L’s were glad they did this and confirmed that we were the better choice in partner to do this project with.

It’s been a month since they successfully went in production and I’m proud to have contributed, albeit in a very small way, to this feat. Well done guys!


Clustering around hotspot End result

How to run a The Responsibility Process™ Retrospective

What is The Responsibility Process™?

Christopher Avery did a bunch of research and eventually came up with The Responsibility Process. Watch this YouTube video too.

In short, it explains how responsibility is not to be considered a trait, something you inherit, but rather something of a state machine, or something that evolves through phases. This process as laid out by Christopher, provides you with a framework that eventually allows you to become aware of which state/phase you’re in, and act upon it as to achieve the goal of Responsibility.

Getting there means you will be able to answer the inner question “What do I really want?”.

Through practice, I found this Process to be extremely powerful. An effect which its simplicity would make you think otherwise. If there’s one resolution you should fulfill in 2015 it’s this one, to use The Responsibility Process and become a better, happier person.

What does it have to do with Retrospectives?

The Responsibility Process is more applicable on a personal level. But make no mistake, it’s very powerful on a team level as well. Providing the answer to the team’s question of “What do WE really want?” is generally a difficult endeavor. However, with the knowledge of The Responsibility Process in the back of everyones mind, can make it realistically achievable.

How do we get this into the back of everyones mind? You build a Retrospective around it!

The goal

To do better in the next iteration, by creating awareness in your team about the Responsibility phases. And by getting everyone in the team to understand The Responsibility Process framework, thereby creating some sort of hivemind, allowing your team to align itself and make decisions easier.

What you’ll need

  • A meeting room
  • Post-its
  • Markers for everyone
  • Sticky (or non-sticky) Flip-charts, Paper-roll, … A clean surface area
  • Tape

Draw out the phases of The Responsibility Process on the clean surface area. Leave some room in between the lanes.

Setting the stage

Make sure you mention Norm Kerths Prime Directive, especially if this is your first retro, but also as a refresher.

Aside from that, pick one! The internet is a vast ocean of possibilities.

Gathering Data

  1. Briefly explain The Responsibility Process. Give short examples for all the phases.
  2. Have everybody write down on a post-it, in silence, at least one event or experience in the past iteration that they can remember, whether it be a good or bad one.
  3. Then have everybody try and hang each of their post-its on The Responsibility Process.

If you have a big team, or you’re doing a project retro, chances are you’ll get a WHOLE lot of post-its. If this is likely the case, you might want to limit the amount of post-its that people can write. You can just lay down a hard limit of 2-3 per person, or constrain them in another way (add to the comment section if you have a nice example).

Generate Insights

This is an important part of your retro. Because here we want the people in the team to become aware of what phase they were in when they experienced their chosen event.

Start with Denial or Blame, and read the post-its out loud. Move up the phases as you go along.

Try to put it every post-it you pick up in the phase where the team thinks it actually belongs. If it isn’t clear what the writer meant by it, have them explain it.

Group same post-its ONLY when they are both about the same subject AND in the same phase!


Here’s what we came up with:

Gathering Data

I’m pretty sure anyone can draw the phases out better than I did. :)

After you finished all the post-its, note how many are in which phase. This is the phase you are most likely to become aware of as a team and move towards Responsibility. The usual thing goes as well where you note clusters of subjects. It might be not as apparent because different post-its on same subjects might be spread out in different phases. This is ok. It’s more important to learn where in the states you are, then which subjects pop out. By saying them out loud, everybody will notice it anyways.

Sometimes people will yell I added that same subject in a different lane!. If you feel like the current phase hasn’t been explored enough yet, continue with other cards in that phase. If you feel like it has, ask them which phase they put it in so you can compare and ask why the same subject is in a different lane.

You’ll notice that it’s often a description of the cause, and not the problem itself that fits best in a phase. Help your group notice this too.

You’ll also notice that some people have difficulty placing a post-it in one lane and will sometimes hang it on the border. In the photo, see the two most left post-its that seem to drape over the border of Obligation and Shame. This is the typical programmers need to reduce duplication. Tell them that in this case, it’s alright :)

A participant mentioned that you could never hang anything in Denial, because it would mean you WOULD be aware of the problem. True, but the post-its that go in there would be experiences that you had and when looking back on them you were in Denial.

The post-its that were in Responsibility were always good ones, and these deserve our attention as well. When stuff is going good in an iteration, it’s definitely also worth mentioning!

Decide what to do

Explain that aside from the personal empowering the framework provides you, it also empowers a team with Shared Responsibility. Then ask the team the big question: “What do WE really want?”. You can then proceed to dot-vote, or merge, or make SMART goals.

Suggest that you can organize a contest where teammembers publicly keep their “Hits & Misses” of the phase that had the biggest amount of post-its.

Closing the retro

Explain the concept of Team Responsibility, which you sort of hinted at already in the previous section. This time make it really explicit that it’s you as a team that also can move through the different phases.

Again, pick one. If you’re like me, you’re going to want to choose one that gives you, the facilitator, feedback on how you ran your retro and how they felt during.

Closing thoughts

I didn’t put up Quit, because I didn’t want to confuse them too much. Quit can be tricky like that. But I did explain it to them afterwards.

Print out the posters and hang them across the team room for easy reference and reminders.

The reason why I think this retro format is great is because you gather data, and learn about The Responsibility Process at the same time. Further more, I find that creating awareness about these phases just improves a team in general, for a loooooooooooong time.

GL HF out there!

Oh, and I welcome questions, remarks, or any other kind of feedback in the comment section.

Hits and Misses game

On a whiteboard or whatever, list the teammembers, a hits column and a misses column. When a person noticed that they were in a certain phase when they said/did something, they can mark it as “hit”. If they notice it after they said/did something or someone else notices it afterwards, it counts as a “miss”.

This might work against you if some teammembers are likely to game the system. It’s fun to then ask them, while pointing at the posters you hung up, out of which phase in The Responsibility Process they’re acting the way they are. :)

Event Storming Exercise

As I’m currently in between projects at Cegeka and just finished working on an RFP, I got to factor in a day of learning along with other developers last friday. And boy oh boy was it worthwile.

TL;DR? Skip to the Struggling part.

Event Storming

Last year at Vaughn Vernon’s (@VaughnVernon) 3-day Implementing DDD course, there was a part where Alberto Brandolini (@ziobrando) gave a workshop on what he called “Event Storming”. Over the year the term has gotten some attention here and there. There’s even a twitter account made: @EventStorming.

Most recently though, Alberto gave a presentation about it at the DDD Exchange conference in London.

Log in to SkillsMatter to see the presentation video.


The idea to get together and practice EventStorming ourselves came from Jo Vanthournout, one of our more avid DDD practitioners. The project he’s on at the moment had a mandatory holiday. And what better way to fill it up with learning than to organize an EventStorming practice session with colleagues.

The idea was to try and storm the tabletop game “Friday”.

In this blog post I’ll list all of the stuff we noticed during our day of learning, so it might a be a bit TMI. :)

Questions, so many of them!

We had some discussion when we got together in the morning that brought us to a couple of questions:

  • Reactive Programming is not the same as an Event Driven Architecture, but they’re alike. But what is the relation between these two?
  • To start using Event Driven Architecture one would normally start with Domain Events, can Event Storming help facilitate with that?
  • Is EventStorming used to model a problem? Or just to model a flow? Or is it maybe a way to explore a process or a problem space?
  • When multiple events need to be gathered before something else can happen, what do you call that? Someone suggested a “coordinator”, which seemed like a very specific name, where does that word come from? Enterprise Integration Patterns maybe? Does EIP also align with Reactive Programming?
  • What should granularity of our events look like? Is it sufficient to write down “Car was started”? Or do we write “Engine started”, “Fuel injected”, “Spark fired”, … ?

Alberto’s Event Storming Recipes

Right after our back-and-forth, the first thing we did was watch Alberto’s presentation that he gave at the DDDX conference.

Pausing and discussing is awesome!

We were lucky to be able to pause it a good couple of times. Whenever we didn’t understand what he was trying to explain, or if we had some additional thoughts we paused and discussed.

I think this worked pretty great. You get the benefit of other views on Alberto’s explanation and you get them instantly. Often this gave extra context to something he was talking about or just made something understandable. I can recommend this way of learning to everyone!

Process Managers

A major point of discussion was the concept of Process Managers. In Alberto’s words: during the session, you’ll sometimes have one event transition straight into another one. In between he annotates something magic happens here. The magic that happens can be contained within a Process Manager, a new concept but a confusing one for sure. Does it wait until multiple events have entered before doing something, or is it simply something to contain some “magic” that leads to an event whenever another event enters it?


Another major pause was when he started talking about how Barriers can be detrimental to your domain. But it was really all right there in the slide.

Strict validation might protect some portions of your process, but it might make a large portion “unobservable”.

What he means is that as a side-effect of your strict validation, some new processes might arise which you can’t control, nor observe. The example he gave was about a very strict validation that caused a company to start an interdivisional excel sheet, that was used to maintain some data necessary for this strict validation… :o

Our problem space: Friday

When Jo first initiated the call for Event Storming exercise on our corporate social tool, he suggested to try it out on “Friday”. Real short, it’s a “deck-building” game that consist of beating 3 progression levels and a boss-fight that you play by yourself.

We got supplies to start our event storming session: a fat stack of post-its, sharpies (at least one per person), and some scotch tape should the sticky notes not be sticky enough.

We agreed on starting our “model” from a state where the game has been set-up and is ready to be played. We then proceeded to have an explanation by Jo backed by the game rules we projected on the wall. We then agreed on colorcoding of our post-its:

  • orange = event
  • blue = command
  • yellow = aggregate
  • green = actor/user
  • pink = external system
  • wide green = process manager

In the presentation we learned that we should start putting events as orange post-its on the wall. And so we did… Until someone asked “Ok, but how does that event occur? Let’s add a command that initiates it.”. And thus, command post-its found their way on our wall quite early on. We carried on anyway, trying our best to think about the next event that needed to happen and a command that would initiate it.

A question that arose after adding commands was of course “Who dishes out these commands? How does a conversation with the system work? Does every command need an actor or are commands by the system just implicit?”.

Back to just events

We already noted that we seemed to be biased by our daily jobs (coding). Somehow this brought to our attention that we should stick to the gameplan more strictly. So we got rid of all our commands we already put on the wall and started adding more events again and decided commands would come later, they’re less important. And it’s true, events sketch out the broader context that clarifies earlier events sometimes and you can more easily rearrange your timeline. Another benefit is that when you already have commands in place, you’re less inclined to change up your wall because of the “work” you’ve already put into it and also because you’re too lazy to rearrange double the amount of post-its. Kind of like the fallacy of sunken cost.

We also noticed that our discussions were taking longer and longer. The action we took was to just keep multiple cards and replace them when we re-iterated over our process at a later stage. Some “double” notes we could take away or replace once we were a little further down the chain. So that verified our hunch.

A little breaky break

Breaky break We just finished putting up one “iteration” of the game. Our process on the wall at this stage ends with “Danger Level Raised”. We took a coffee break - away from the wall - and talked about this and that. However, when we got back in the room and tried to restart our think-engines and get back in the flow, we found it wasn’t all that easy to get back into it. Did this have to do with having too specific events? Or maybe it didn’t mean anything at all?

Optional commands and gesturing

We were now at the stage where we were tackling the multiple stage concept of the game. The discussion we had was about what parts of our process were going to be iterated over. There was a clear need for splitting one straight timeline into two or more separate ones. I noticed we were cutting parts of the wall with our hand-gestures. Both round and straight. Alberto also talks about this as well in his talk. It just helps visualize what you want to do easily. It’s clear enough for everyone in the room what parts you’re separating.

Using the “UI”

At some point we went back to the tabletop that had our complete game set-up to continue our thought about the process and to use proper names. Annotated tabletop of Friday Because we did this we got some extra insight that helped us along. We compared this with how Alberto talks about making little “UI” cards that should explain what decisions a user can take based on what information he sees. This further clarifies some events and is obviously helpful in that way. This did make us come back from our earlier strategy to only add events that were based on UI decisions, because you might miss some important ones actually.

End times

When we had to stop for the day we think we managed to complete the short process of Friday in a visual chain of events on our wall. We all agreed that this was time well-spent, learning a lot. But nevertheless something we need to practice more if we want to do this exercise with one of our real customers at some point.

The Result


While trying to add more events, we noticed that we were struggling with the granularity of the events. Because we are all programmers, we sometimes had the impulse to add events that said something like “card turned”, which might be too fine-grained to see our process clearly. When we did eventually notice those, we decided to tune it back a little and replaced some events that were already on the wall or simply got rid of them. Our general rule was “decisions that are taken based on the UI, we don’t put up as events”.

This struggle did lead us to a small discussion on language we used for some events. We knew we had to use verbs in the past tense, but there was one specific case that I thought was interesting. Interesting because we discovered it so early. We had an event that read 1 hazard card to fight chosen which got turned into Challenge (with chosen card) started. Can you see how different that sounds? It’s basically the same step in the game, except the first notation seems too fine grained, whereas the second one seems to be more coarse-grained but also more clear and says more about the game or of a next phase in the game. Ubiquitous language

Another thing we were struggling with was the concept of iterations of commands/events. For example, when you’ve gone through a deck of cards the next level starts (it becomes more difficult) and a big chain of events starts all over again. We didn’t know how to make that visible on our wall, or even if we should make it visible at all. After some discussion we decided to simply not model it, because the events should speak for themselves. You don’t really need an arrow pointing from somewhere in the middle of your “timeline” back to the front to indicate starting over again. Another indication that we’re not exactly used to thinking in events or streams.

Yet another thing we found difficult to model was conditionals, which might again be an indication of our struggle with granularity and an event driven model. Should conditions also be represented as mere events maybe?

At this point we were all agreeing that we’re missing someone that could provide us with some guidance with this event storming stuff.


  • When you recognize you’ve got Event leads to Process manager leads to Command, you basically got stuck into thinking imperatively again.
  • Don’t go too much into detail, try to stay high level as long as you can. Especially in the beginning of your session.
  • It’s ok when one event leads to another event. You’ll run into this when you really want to translate one event from one bounded context into another event that makes more sense in another bounded context. A good example: “Person x has had a birthday”, leads to “Person x has reached pensionable age”. So really in cases where one event is reinterpreted and/or filtered it’s ok to just generate a new event instead of going through a command.

Questions unanswered

  • How do you properly use the result of an Event Storming session to produce stories?
  • Can you write your implementation completely based on the events you put up during the session?
  • Can you write a “walking skeleton” from the global event flow and do you use this to hook your story implementations on? Or is that considered to be too much of an upfront design?
  • We know of some projects that already used Domain Events and/or Event Sourcing. How did they end up with their events? Did they also model this first somehow?
  • Did they ever model an event that ended up being 4 separate events? And how much of a problem was it to modify their code at that point? Or did they ever model events that ended up being irrelevant? Or vice versa, did they miss events that ended up being super important?
  • For me personally there’s still some unclarity on commands and how to properly position your events when your straight timeline splits up into multiple ones. Can you just put those separate flows anywhere, because the eventstorming session only serves to make a mental picture?

What’s next?

The plan is to implement that game based on our event storming session outcome and see how far we can get. So I guess when that happens you guys will be able to read about it. :)

Coach Retreat

Yesterday I went to the Coach Retreat in Leuven, hosted by Cegeka. Here’s a little report on my personal view of the event.

My expectations

Based on the title, I was thinking something in the likes of a playground for coaches, where you’re free to practice some confrontational talks in a safe environment.

I did not think it would have anything to do with Agile Coaching in particular and that it was going to be a more general view on coaching.

At the end of the day, I expected to have learned a couple new things about coaching in general, but no “game-changing” revelations.


The Coach Retreat concept was brought to life, among others, by Yves Hanoulle (@YvesHanoulle) and Oana Juncu (@ojuncu), inspired by Corey Haines (@coreyhaines) and Rachel C. Davies (@rachelcdavies).

Both Inge Gorgon and Yves Hanoulle, the two facilitators for the day, I consider skillful coaches. They helped keep the groups focused on the exercise at hand and gave a lot of insight based on their own experiences in the real world. This stuff alone is worth it in my humble opinion.

We were welcomed to have a croissant and start reading the scenario’s that were hung up on big papers all over the wall. They described some very recognizable real-life work situations. But most of them described your job/role as an Agile Coach and questioned how you would solve the problem(s) at hand. We ended up voting for one scenario that we would use throughout the day for nearly all the exercises. It was about a head of IT, Patrick, who was having trouble with the “business”. They were ignoring the bureaucratic process and wouldn’t make time to tell the IT department what they wanted. He read that applying Scrum might help, but wasn’t really sure how. You were brought in to coach Patrick through his ordeals and get IT and business to work together to build stuff that actually brings value.

After everyone arrived, we “checked in” by standing in a circle and one by one introducing ourselves and expressing our feelings using 4 basic emotions: Happy, Sad, Afraid and Angry.

Participants were generally Happy that they had the opportunity to be there, Afraid that they weren’t going to be able to last the day without dozing off, Sad about the weather or having to leave their family at the start of the vacation and noone was Angry.

Then we got an explanation on what a Coach Retreat was all about.

A Coach Retreat really works just like the format of a Code Retreat. You practice coaching over and over again, in a safe environment, for the purpose of practicing (and improving this way). All the while getting feedback from your “pair”, in this case, that “pair” was in fact your entire group, consisting of usually 3 spectators, a coach and a coachee.

Having so many eyes and ears on your conversation generates a LOT of feedback. Feedback which you can immediately use to improve your coaching by applying the first technique we learned: Click, Rewind.


Click, Rewind

This is a really simple and effective way to tune your style/technique during a coaching conversation. Whenever you want you say “Click” and you can pause the conversation this way to talk to your spectators and ask for help on what to say next. You could also say Click and then ask to Rewind, which proved very useful whenever you noticed yourself saying something silly that would direct the conversation in a wrong direction.

It’s not something that can only be used during these practice sessions, but also in real 1-on-1’s. Yves told us about a couple that effectively uses this whenever they have a fight and say things they didn’t mean.

As this was our first exercise, everybody was still getting the ropes and opening up slowly. And because the technique is very clear and simple, I think it’s an ideal one to start off the retreat with.

After the explanation everybody made groups of 5 and spread out over the meeting rooms of the Cegeka offices. I went off with our little group of 5, we chose our coach, coachee (“Patrick”), and observers. Then we started talking about the context that our conversation would be taking place in.

After about 50 minutes talking and clicking and rewinding, we were told to do a little retrospective of the exercise and make a summary that we would present to everybody. Then everybody came back to the main meeting room and shared their experiences. We would repeat this structure for every exercise, including the next one: “Yes, and…”.

Yes, and…

Another “simple” exercise where instead of saying “Yes, but…” you say “Yes, and…”, thereby giving a more positive tone to your remarks. Eventhough it sounds really simple it is, in fact, not simple at all. It’s so easy to say “yes, but …”. I got to play the coachee in this exercise, and decided to be a real PITA. You see, my secretary hired the coach and I was under the impression that he was going to do my work for me.

I noticed something very curious and interesting during this exercise. Eventhough I was trying my hardest to be “evil”, I felt like I was being disarmed by my coach because he kept a positive and calm attitude towards me. According to our observers, this was also noticable by my posture that changed after the “Click, Rewind” we did after we noticed the coach wasn’t going in the right direction.

This really proved to me that this tactic just works. You could say it was an “AHA-moment” I experienced. Speaking of which, everybody was invited to write down their AHA moments on post-its and stick ‘em on the AHA-wall in the common meeting room. Another fun and effective device that increases sharing the learning experiences.

Another thing I noted was that you shouldn’t just look to replace “Yes, but…”, you can also just use “Yes, and…” whenever to further amplify your positive message.

Those fifty minutes flew by and soon it was time for the next technique that continues along the “optimistic things” path: “Appreciative Inquiry”.

Appreciative Inquiry

In the “Appreciative Inquiry”, the idea is to get your coachee get a positive thing out of a negative situation. You can do this by moving your coachee through different phases: “Discovery, Dream, Design, Destiny”, by asking “Powerful Questions”. I jotted down “What? leads to Discovery”, “What if? leads to Dream”, “How? leads to Design”, “What? When? leads to Destiny”.

During this exercise I was one of the observers and figured it would annoy me after receiving 4 or more questions in a row. So you can’t tirelessly keep asking these questions. They can be exhausting, and can get you to lose your coachee. Give them some breathing room, talk/think along with them, until you can ask them the next question.

Another important thing was to summarize/repeat at some intervals when a solution requires a lot of smaller steps.

I also noted that our coach in the exercise asked “What would have happened if …?”, this is a different style of “What if?” that leads to a retrospective view of a situation that can give your coachee yet another perspective on their sticky situation. In our case this is what led our coachee to a breakthrough.

So whereas “What would have happend if …?” leads to a historical perspective, “What if … ?” gives you a look into a possible future. The next technique we would learn after pizza would further explore this concept.

The Magic/Miracle Question

“Imagine you go to sleep, and the next morning when you enter work, all of your problems are gone. What does your office look like? How do you feel?”

Asking this question brings your coachee into a hypothetical situation. Maybe it’s a utopia, but it’s a situation you can explore safely, where some things might not seem so unfeasible at all. The hardest thing about this technique is staying with your coachee inside this mental picture. It’s so easy to guide them to a solution that you know by being very suggestive. Of course, this isn’t ideal in many cases and it’s an easy pitfall.

I was coach in this situation and there were many times where I Clicked and Rewound. Another thing worth mentioning was that my coachee knew so much about Agile that he already was explaining an entire solution, leaving nothing for me to guide him at first. We clicked soon enough and restarted the context. Props to my counterpart in this exercise though. It’s really difficult to both picture your character and what he would say, and then also “dream up” a situation from that characters perspective. Saying this out loud made us all think of the move Inception. :)

During this exercise I got some real good feedback on my coaching style in general, aside from the exercise that is. I let my coachee know that I have a solution in my head, and what that might do is get my coachee to keep on asking for the answer. A tip I got from one of the observers was to just remain silent in that case. Or try to not show I have an answer in my head in the first place.

You might recognize this concept from a retrospective game we sometimes use, such as the “Remember the future” gathering insight.

Once again, those 50 minutes flew by and it was already time again to gather in the common meeting room to share our experiences and notes.

A pro-tip that I think came from the audience was that you can use this technique to get people that only complain, out of their comfort zone and into improvement.

Crucial Confrontation

Our final technique we learned was more about a confrontational perspective than from a coaching one. We learned that there might be three phases when having to deal with a confrontation.

The first is about content. Your son came home from hanging out 30 minutes late.

The second is about a pattern. This is the third time that your son came home 30 minutes late after you told him that this bothers you the first time.

Lastly, the third is about a relation. Your son is still coming home 30 minutes late after repetitive exclamations of your worrying about his safety. He is choosing to abuse your parent-child relationship for his own benefit.

Especially in this last one, preparing yourself for this confrontation contributes a big deal to the success.

My Take-Aways

Spectating and participating in these exercises as a group really gets the knowledge-sharing going instantly. It once again amazes me how much stuff you learn by talking to people that have similar, yet different experiences.

Sometimes just don’t say anything.

Try to apply “Yes, and …” more often because it’s really powerful.

Try out Click, Rewind a couple of times in real situations.


Eventhough it was only one day, I felt like I learned three days worth of training. I’m comparing with another coach training I had before this one. Then again, I’m not sure if I would have gotten so much out of it if I didn’t do that previous coach training before doing this Coach Retreat.

I also got to know a couple of colleagues better which is always nice. And I think the clients that also came to this retreat left with a good impression of the skills of Cegeka employees.

Thanks again to Inge Gorgon and Yves Hanoulle for facilitating and organizing this retreat. It was extremely useful and I hope Cegeka will be able to host more of these in the future.

Hope you readers got something out of this post as well.