The Core Protocols Cheat Sheet

I have gathered a very simple cheat sheet for core protocols and when you can use them. You can find them here and embedded below.


Test Driven Development by Example

After taking LeSS course with Craig Larman, my mindset toward coaching teams has changed. I inspired to include coding practices alongside my liftoffs. That's how I started to do a lunch & learn with some teams and introducing them on TDD. The problem I picked was exactly the problem that Craig picked, prime factorization table. It was a very well thought of problem and the way the algorithm will evolve is very intuitive and mind-blowing at the same time. At each step, you are only worried about the test you want to pass and that's it, the algorithm evolves by itself; of course, driven by tests.

I tried to capture the steps in a powerpoint, to show how we the algorithm of finding prime factorization was evolved from one line to the full algorithm.

What I tend to do in the coding session is to ask for help, to see if there is anyone that wants to help me with coding or even thinking and getting it going. In the last one I ran, one person got up and sat on my laptop and did the rest of the coding. I then told them this is how a pair programming would look like, at least this is how you can try it to begin with.

I found out that Uncle Bob had a very similar approach called it PrimeFactorKata.


Notes on LeSS with Craig Larman

I was very lucky for Craig Larman to be my fellow traveler in my Agile journey in April 2016, although for a very short period of time. I had the honor of taking part in LeSS practitioner course offered by him. I immensely enjoyed learning from one of the Agile Gurus, not only about LeSS but more importantly about Agile. I have heard stories leading up to the Agile Manifesto meeting at 2001, philosophies behind defining Scrum and why things have been named the way there are now. My mind has officially been blown. It completely reignited me to learn more and try new things while not forgetting the principles. Notes below is the ones I took at the course. It was the first time that it has been offered in Canada, thanks to Bertieg.

This is the big picture of LeSS. There are lots of details in the picture. You need to pay attention to all the details. For example, there is one scrum master that is helping with two teams and there is a team with a dedicated scrum master.

And this is my first attempt at describing LeSS to one of my colleagues.


Characteristics of a Great Scrum Master

Finding a great Scrum Master is not trivial at all. Anyone can take a course for two days, take the test and become a Certified Scrum Master. However, you are not mastered in anything. Your journey has just begun. Through my experience looking for great Scrum Masters, I came up with the following list of characteristics. This list summarizes what I am looking in a person for a great scrum master. It is important not to forget that a Scrum Master needs the knowledge of basics of Scrum, before even being considered a good one. 

I also have assigned points to each characteristic. By looking at those, you can have a better understanding of which quality has a higher weight in determining a great scrum master. 
  • Innovative / Creative Solutioner
    • A great scrum master is someone who is innovative, someone that can come up with creative solutions on the fly  depending on the situation. Someone that can understands complex situations or if he/she doesn’t understand the situation, to find out ways of understanding the situation.
  • Good Communicator / Facilitation guru
    • A Scrum Master is needed to be able to communicate his messages to the team flawlessly. He needs to be felt part of the team when communicating to the team. He needs to be more direct in communicating the message with the leaders. He need to be direct if communicating with people helping removing impediments.
  •  Team player (Lead by example)
    • Leading the team needs someone that is a good team player and know the rules of the game. You can’t be a great mentor for the team if you haven’t played in the field yourself (even if you failed while playing).
  • A good Agile Tour guide / Knowledgeable about Agile values and Principles
    • A good scrum master needs to lead people into the Agile world. Leading people needs prior knowledge of where we are getting them and how we are getting them to. What challenges might be in different paths and how to overcome it.
  • Be prepared for the unexpected (fearless)
    • In an Agile team unexpected(s) are expected. A good Agile guide needs to be prepared for those. You need to have tools in your toolbox to deal with those. 
  • Be a good psychologist  
    • As someone leading the team, the scrum master needs to be a person that listens well. The listener needs not only to hear but also observe and feel the team’s feeling. He needs to have an empathy muscle. 
  • Be comfortable making people uncomfortable
    • Scrum master is the agent of change. He/She needs to be able to sell changes inside the organization. Doing so, the scrum master needs to have people skills to make people uncomfortable.
  • Be patient
    • A good scrum master understands that change does not come fast. You can introduce a new concept or a process to people and don’t see the effect right away. A great scrum master has follow-up plans. 
  • Continuously improving
    • A great team is a team that always looking for improvements and growing all the time. Leading a team  with such great qualities, you need to live and breath that quality by yourself. 

  • Personality Qualities (A Qualities) (+45)
    • Innovative / Creative Solutioner (+13)
    • Great Communicator / Facilitation guru (+12)
    • Be a good psychologist (+5)
    • Be comfortable making people uncomfortable (+10)
    • Be patient (+5)
  • Professional Qualities (B Qualities) (+25)
    • A good Agile Tour guide / Knowledgeable about Agile values and Principles (+15)
    • Be prepared for the unexpected (fearless) (+10)
  • Personality & Professional (A + B Qualities) (20)
    • Team player (Lead by example) (+12)
    • Continuously improving (+8)

90 total


Postcard Retrospective - Travel Through The Last Sprint!

During one of the retrospectives, I asked the team to write a postcard to one of our ex-team members. Amer left the team to pursue new endeavours in Montreal. I thought this would be a great opportunity to write him back and send him some postcards. Having that in mind, I asked him to write the team in the first place. I presented his letter to the team and asked them to write back. I didn't specify the context on which to write back to him. Whoever needed clarification on what to write back, I suggested talking about what have changed from the time he left and what they are missing about him. You can see the presentation I put together for the team below, I called it Travel Sprint.

This is all the postcards the team wrote back to Amer.

What was good about this type of retrospective?
This would be a good exercise for the setting the stage and gathering info section of the retrospective. Great conversations can be started based on what the team members are writing on the cards. You just need to direct the conversation into generating action items.

This exercise will also unintentionally bring up the concept of "not being a resource" in each team member's mind. We are talking about a specific person with specific characteristics. You can expect different personal aspects to be talked about.

This exercise will give you a good understanding of how different your team members are. You can put all the postcards on a table and ask them what do they see. Also, it helps them with understanding each other's different perspectives.

As you can see through the rest of the slides, I ran the expectations exercise and the four Qs building on top of the postcard exercise. Finally closed the retrospective with the dot voting on action items.

PS: Please be more pro-active running this exercise. Try to use coloured markers and some stickies to make it more fun. I didn't have time to grab all those and just did it with plain papers and sharpies, hence the quality :-(.


Notes from Agile Facilitation Tools & Techniques Course

These are the notes from the facilitation workshop / course held by Sue Johnson.

My Aphorism

You need to show the same audacity for not facilitating a session having no or negative value, as opposing a team's decision contradicting Agile values.

Great Facilitation Skills

  • Having made them write it down => great facilitation skill for helping with the introverts  
  • Put someone on the spot, a big NO NO
  • Bring it to the team, they are there with their best interest
  • Good to do process check in intervals in the meetings
  • Secondary Facilitator
    • Originally from Group Gold Mining book
    • I want to use it as an opportunity to coach a person to become a good facilitator
  • If it is about your job, you don't want to facilitate that meeting, an example of what not to facilitate
    • Even the meeting is not a good option
  • Facilitator needs to make sure it is not becoming a slugfest
  • Do we get instructions to become a parent / husband / wife? On how to become a good communicator / facilitator
  • Get the participants in group first, before introducing the group activity
  • Give them what and let them find the how, on how to facilitate neutrally
  • Facilitator is more about facilitating than being a facilitator
  • Will you be tempted to influence the team? And can you be a team member? To ask a manager before attending a team meeting
  • Facilitating a group is much harder v.s. a team. You need more time to prepare, as they don't know each other to the extent of team members. 
  • Use of Empathy Map 
Empathy Map (Source)
  • If people are flooded with emotion, you can't work with them (and facilitate the session), you need to take a break
  • You need to understand that an angry woman most probably will cry at work. It is not appropriate to be angry at work for women. 

Good to Remember Questions

  • What's your gut feeling, are we missing any of those? (Referring to your feeling in an indirect way)
  • Do You want to say more about this?
  • I want to hear from the people I didn't hear
  • Stand right by a person, works both for quiet people and talkative people
  • How do you know? A god way to asking if it is really the case
  • Ask for an example, good one or BS
  • Is that true or is that your opinion (stronger word to use: story)?


  • Everyone is right but only partially (our own version of truth)
  • Distinction between Interest & Position
  • Go back to facts, we need to walk those people down the ladder when resolving issues
  • UNMET NEEDS => Reason behind having conflict, look for what's missing 
  • You Are Always Right! From each person's perspective they are right, try to use that a lot and believe in it sincerely. Look from their perspective. 
  • Conflict around ideas not people
  • You can improve on Negotiation Training
  • Conflict, alternatives to:
    • Disagreement
    • What wants to happen?
    • Emerging things

Spiral of Doom
Who it is going to be won
As we start to files attached, we start to move to world of fiction
Fact going through our believes
There are facts supporting that conflict


We are powerful people, we thrive on:
  • Powerful Observation
  • Powerful Question
  • Powerful Request

Open Space

  • Open space is for complex problems that there is no simple answer to it. 
  • A theme is good to have for an Open Space

Individual interaction

Individual exercise -> group exercise
(time to reflection, talk before think)
introvert -> extrovert
small group -> big group

Haiku for Team Dynamics

Work togetherish
Live happy with conflictish
Grow with each otherish


5 to 1 ratio for positive to negative feedback ratio
Radical Candor
Deep Democracy

Arc of Facilitation (Very similar to 5 Retrospective stages)
Learnings Summarized at the end of the session


Stand Up Estimation - How to estimate large number of user stories very quickly even with a big team?

Have you ever tried to estimate a large number of user stories with a big team? What was your best solution for that? Planning poker will be an awful experience, I can assure you of that. Everyone will become tired after a while; you won't get that many people participating after a while and the session will not serve its purpose. 

For a large number of user stories, what I'd like to do is to ask them to do "Stand Up Estimations". 


You need to have a table and divide it into sections. Alternatively, you can use a wall with sticky notes or sticky user stories cards, up to you. You will need to define sections on your table. The sections present the size of user stories. The size can be in numbers (e.g. Fibonacci numbers) or simply words (e.g. small, medium and medium).

I divided the table into seven different sections, and in each section and both sides I have a number stuck (The numbers are based on Fibonacci sequence). I strongly suggest for you to remove the chairs out of the room if you can, or move it far away as possible.

You also need to print out the user story cards. If you are using Jira, you can use Agile Cards for JIRA. In the picture below you can see the amount of user stories printed and waiting to be estimated.

Let's Standing & Estimating begins!

On the entrance of the participants to the room, give them some of the user story cards. You want to make sure everyone get cards, so divide them in the fashion that everyone get a bunch of cards and no one feels to be left out.

Ask the participants to follow these rules:
  • The only thing that can be put on the table is the user story card. Nothing else can be put on the table, no laptops, cell phones, coffee mugs etc
  • Ask them to stand up while doing the estimation

First Round

Ask everyone to silently read the cards and estimate them to best of their knowledge. The estimation is the act of putting the card on the table. 

Second Round

This is when you ask everyone to look at the cards on the table. Ask the participants to read the user stories on the table and discuss the user stories. If there is a user story that they don't feel correctly estimated, they can have a discussion and change the estimate or keep it there.

Following Rounds

The discussion will go on. It depends on the complexity and the level of familiarity of the people with user stories. People get tired, then tend to use their energy for the most important user stories and the ones that they really think is important to discuss. Otherwise, when they are comfortable and after rounds of estimation, they sit out of the discussion; and literally on the chairs far away from estimation table. This will give you a good visual indication of how much more the session will take and when you need to puts and end to it. 

Final Round

You need to end the session somehow. It depends on your facilitation skills and how comfortable are you with the team. You can sense when there is not many important discussions are remaining. That's when you need to end the session. You can, alternatively, set a time limit for it. I would prefer the former approach. The former approach emphasize the value of estimation by estimating not all the stories.

To keep in mind

Some points you need to consider before facilitating this session:

  • This is a very fluid session, you need to have confidence in your facilitation skills to run it. You might get into situations that easily can get out of hand. Think different outcomes that might come out of it and be prepared for that.
  • I suggest running the idea of Marathon Sizing in team member's minds beforehand. You want them to expect them something new, especially for those participants that were used to a sit down boring long meetings.
If you are interested in estimation, you can read more @ http://blog.sheidaei.com/search/label/estimation