FesLe latest blog articles:

Great: Product Owner, DevOps & UXDesigner!

Great: Product Owner, DevOps & UXDesigner!

In this article I will share a facilitation idea, you can include into your Product Owner, DevOps or UX Designer Workshop. You can also run it on the Agile Community in your company. It can help the participants to realize what makes a great: Product Owner, DevOps & UXDesigner!

How to approach a RED JERK in a Scrum Team?!

How to approach a RED JERK in a Scrum Team?!

In this article I will discuss the topic of Brilliant Jerks AKA Super-Chickens AKA Ricks AKA Toxic Workers and the perspective of a Scrum Master. It aims to help you channeling your focus and energy back on the team instead of on the brilliant jerk.

The power of a Sprint Goal (examples)

The power of a Sprint Goal (examples)

In this article I will share four examples of the same Sprint Goal but expressed in different ways. Explore the impact it has on the team..

How to recruit an 8 Stances Scrum Master

How to recruit an 8 Stances Scrum Master

In this article we'll share the approach we developed to recruit Scrum Masters using Competency-based recruitment process, Barry Overeem’s 8 stances of Scrum Master, and Behavioral Driven Development.

Where do you really want to work? Orange vs. Green vs. Teal

Where do you really want to work? Orange vs. Green vs. Teal

In this article you will find answers to the following questions: What distinguishes some organizations from others? What impact can these differences have on your career and life? How do you know, when recruiting, if an organization is right for you?

Does a Scrum Master need Conflict Resolution Skills?

Does a Scrum Master need Conflict Resolution Skills?

Going through some job offers for Scrum Masters, I couldn’t but notice that in most of them conflict resolution skills were expected. So here is the question: does a Scrum Master need conflict resolution skills?

This 4 guys, while introducing change [my five tips for you]

This 4 guys, while introducing change [my five tips for you]

When trying to run an experiment and improve something in an organization I always come across these four different groups of people. Click and learn more about them.

How I've used Story Cubes too break ice between Teams from different countries

How I've used Story Cubes too break ice between Teams from different countries

In this short article I will share my facilitation guide for a creative Ice Breaker exercise using Rory's Story Cubes® for teams working on the same product but in different locations.

Great: Product Owner, DevOps & UXDesigner!

Great: Product Owner, DevOps & UXDesigner!

In this article I will share a facilitation idea, you can include into your Product Owner, DevOps or UX Designer Workshop. You can also run it on the Agile Community in your company. It can help the participants to realize what makes a great: Product Owner, DevOps & UXDesigner! Use it as a part of your workshop's Kolb's Learning Cycle (in Experience and Reflection stage)[1].

The idea was inspired by a post shared on LinkedIn by Glen Bowering:

Great: Product Owner, DevOps & UXDesigner!

Facilitation idea on "What makes a Great Product Owner":

  • [1min] Present the participants with this provocative statement:
Agile: Bring the Business and Tech "together" by creating a Product function to sit between them
  • [2min] Ask the participants on how it resonates with common sense and their understanding of that role.
Great: Product Owner, DevOps & UXDesigner!
  • [10min] Divide participants into groups of 3-4 people and invite them to generate a list of behaviors and situations from a day of: 1) a Bad Product Owner which is a Proxy between Business and Tech 2) a Great Product Owner who brings the tech people to the business people.
  • [5min] Each group present their BAD/GREAT PO behaviors lists.
  • [10min] A big group discussion on what was surprising and how it looks in their company.
  • [10min] alternatively to the discussion you can hand out real life case-studies and ask the participants to relate the examples to the BAD/GREAT PO behavior lists.


This exercise is great because it works for a mixed group made of both senior Product Owners, Agile Specialists and people not familiar with the topic at all. Let me know in the comments bellow how it worked out for you.


[1] Kolb's Learning Styles and Experiential Learning Cycle

Article author: Błażej Drobniuch

Back to top Contact us
How to approach a RED JERK in a Scrum Team?!

How to approach a RED JERK in a Scrum Team?!

In this article I will discuss the topic of Brilliant Jerks AKA Super-Chickens AKA Ricks AKA Toxic Workers in a Scrum Team. This topic was actually already thoroughly described (check it out  [3] [10] [2] [4] [5] [6] [13] [17] ) so I will only focus on the perspective of a Scrum Master, and share some patterns and personal stories.  Disclaimer! : this article is not   about specific persons, but about a set of  behavioral patterns  you could encounter in your work as a Scrum Master. It aims to help you channeling your focus and energy back on the team instead of on the brilliant jerk.

Why Red?

Red color is one of the four colors from the Insights Discovery methodology (a psychometric tool based on the psychology of Carl Jung). This tool helps people understand their style, their strengths and the value they bring to the team. It breaks down too four kinds of  behavior  types:

  • Red : who is dominant and commanding,
  • Yellow : who is social and optimistic,
  • Green : who is laid back and friendly,
  • Blue : who is analytical and precise.

It is greatly described in the bestseller book  Surrounded by Idiots [1] by Thomas Erikson. Now, from my personal experience our super brilliant jerks fall into the red type. Knowing that is really helpful in spotting behavior patterns and choosing the right tactic. Also, knowing your own color can help e.g. when you're green it will be much more difficult for you to handle RED JERKs then for any other color. So definitely read that book, check out the links and take the Insight Discovery test.

RED JERK patterns stories:

Here are some patterns I've notice regarding RED JERKs and how I try to handle them (based on my experience and knowledge). I'm not a specialist on manipulation and human behavior. What interests me is team work and making impact on other people. If you don't agree or have some nice tricks or advice, please share them in comments below the article helping me to improve!

  • Talking in the name of the TEAM:  e.g.  "if you do this the team will feel bad", "we all think that we're wasting time"  that's a common manipulation technique. A team is a group of people with a common goal it doesn't have feelings, the people inside do. Ask who exactly feels bad. If the team is present during the conversation, move the focus away from the RED JERK and just ask the others by name what do they think. Remember to separate the facts from the opinions.  "What exactly will make you feel bad?" . It's necessary because others are probably influenced by the RED JERK or even scared to share own different opinion.  Story:  I witnessed a situation where a new senior member was bullied by a RED JERK. I prepared an Ice Breaker retrospective so that the new joiner could know the rest of the team better. The formula was simple <just tell us something about you>. The RED JERK was sabotaging it from the start stating that everybody in the team already knows each other well. I moved the focus away from him and asked the new senior member: “Jimmy what do you know about Paul (one of the team members)?” Jimmy responded: “Not so much.” “Paul could you please tell your story in our company, your hobby etc.” We've gone through all the team members and even the RED JERK softened and joined the ice breaker.
  • Talking in the name of people not in the room:  e.g.  "I've worked with many developers and they all claimed that the retrospective has no value", "nobody in our product group believes we can do this, let's don't waste time on this solution"  now a red lamp should light up in your head. Remember the original purpose of the meeting/conversation because it's likely that the RED JERK's statement is for another meeting e.g. f2f etc., just propose to meet another time and talk about it. Park his statement. If that's not the case, start from asking who exactly <by name> has such opinions. Do not engage in any clarification discussion because it was not meant to be clarified right from the start.
  • Fundamental axiom statements with technical and Agile buzzwords, bending they meaning:  transparency, autonomy, self-organization, agile delivery, you name it.  Story : The RED JERK used to call a team for not reporting to him or refusing to ask him to make technical decisions "not transparent". Another example was when the RED JERK didn't allow to participate in a daily scrum developers from another team working on the same product wanting to synchronize. He claimed that "the company is depriving his team from autonomy" because we won't let his team conduct a daily scrum behind closed door "the daily scrum is for the developers though". Another when he rebelled the team against the PO because “planning for more than a sprint is not Agile.”  It's good to stop right away and clarify the real meaning of the words.
  • praise someone in the presence of HiPPos (management, chief architects etc.):  the RED JERK will never complement someone when there are no 3rd persons presents. Just the opposite: when there are HiPPos[High Paid Persons] like management and chief architects in the room. The red jerk is praising someone to diminish their skills and to show how important he is in front of others. What's characteristic, is a serious tone of voice always starting in a form of "I" e.g  "I would like to point out that I have noticed an improvement in <person, team group>"  praising someone but in the same time remaining on how they were bad till recent.  Story : On an important meeting with managers the RED JERK took time to talk about a "success" his teammate (he was constantly undermining) finishing a simple minor task made. What was specific is that he chose to praise him for a simple easy task everybody knew was trivial.  Now a good thing is to talk about this situation with HiPPos after the meeting, focusing on facts and sheering concerns if they pop out. Also, make sure that they won't make an opinion about someone only basing on the RED JERK "kind" words.
  • undermine the legitimacy of the actions of others, when faced with counterarguments changing subjects:  There is a big value in questioning someone’s plans and actions as long it is in a good intention, aimed to reach the consensus [19] . But what when the RED JERK goal is quite different? Notice his actions when he immediately changes the subject if he is presented with valid counterarguments probably following with another attack. As a facilitator try replacing the absolute, judgmental terms  "right/wrong" "good/bad" , with the situational  "helpful/unhelpful" . Also try asking questions like  "How does that help (...) to (...)?" . If possible try to park the discussion and suggest to postpone the topic for a follow up meeting. If you instead continue the discussion, it will most likely lead to exhaustion of the group and bad morale. In worst case scenario you land on RED JERK's enemy list.
  • Spreading bad opinions about others with people not having the whole picture, leaving the recipient of the message with a sense of expectation and responsibility to handle the situation (even when it's not her role):  Another typical pattern is when the RED JERK spread rumors and share their opinions on others not supported by facts but personal judgments to people outside, especially to Scrum Masters and HiPPos, like managers and chief architects. They do it in a way that the recipient of the message feels that she should handle the situation and do something about it (even when it's not her role). The best what a Scrum Master could do now is  actively do nothing!  A conscious withdrawal of own projections and "Help" deepening the problem! Just listen out the Jerk. If there are others recipients like managers you should coach them to be cautious and not to pay attention to opinions without facts.  Story:   The RED JERK shared with me that he purposely spreads opinions with different details for different recipients so he can later on determine who did react.
  • Making fun of someone behind his back in front of others:  A common RED JERK pattern is to make fun of someone behind his back in order to undermine that person’s authority. In this case, I try to remind him that such behavior is unprofessional and state that I'm expecting professionalism from my co-workers at my workplace (RED JERKs see themselves as professionals and will feel ashamed). Talk with his manager to work with him 1v1 on that behavior. This is less common in companies performing 360 behavioral feedback session or supporting giving feedback in other ways (explained later on in the article).
  • Creates Ally Camps vs Enemy Camps:  RED JERKs divide people into camps. So when you don't act the way RED JERK wants he'll start to spread opinions about you and you land in the Enemy Camp. People who easily engage and support spreading RED JERK's bad opinions land in the ally camp. It's hard to be neutral because the RED Jerk will pick you up interrogating what do you think about the topic connected to the enemy camp. What are the symptoms of the existing camps to be sensed by the Scrum Master? You'll hear a lot of  "We" , "Them"  in discussions about solutions; management will talk about the bad performance of the Enemy Camp (based on opinions not facts); the RED JERK will be indulgent on his Ally Camp minions setbacks; some Ally Camp members start explaining themselves from opinions stated in the presence of RED JERK when he is not around. The RED JERK tactics is to demonize the members from the enemy camp. What works for me to solve this situation is to engage in co-op the people from two camps and facilitate a session so they can get to know each others more. Also it's good to name things and separate facts from opinions when you hear those stated in the ally camp. Be very careful while doing this as you will be pushed very quickly by the RED JERK to the enemy camp. When you're not neutral for the people from the ally camp it will be much harder to fix this situation.
  • Monopolize conversations not letting others to moderate meetings:  The RED JERK is an effective meetings moderator. He is always engaged 120%. This is how the management sees him. What they don't see is that his goal is not to emerge the best solution but to pass his solution. It's also a great opportunity for him to show how important he is in front of others. The additional downside is that his team will be unable to perform effective without the RED JERK. The work will not move when he is on vacations. Now what works for me is to engage others in facilitating or moderating the meeting (which is not always easy since the RED JERK will take it as an attack on his position in the group) or use facilitation techniques that engages the whole group in the role of the facilitator (silent brainstorming, working in pairs, 1-2-4ALL  [11]  etc.).
  • Using the advantage of possessing key information and the lack of information of other co-workers to build his position or undermine others:  Since REDs are very task and result oriented they easily become the contact person of first choice for busy Product Owners, Product Managers, Clients, Architects and Businesses Annalists. So, when the RED is also a JERK he uses his advantage of possessing key project information to build up his status and deny it for the persons from the enemy camp.  Story1:  RED JERK used the group dynamics and formed a circle with the rest of the team turning his back to a developer that needed information and asked some questions, whereas the RED JERK purposely ignored him (showing him that when he won't play by his rules, he'll be treated that way).  Story2:  This behavior is common not only inside the scrum teams. I witnessed a management person interrogating Product Managers pointing out their lack of knowledge about the product in front of others (demonstrating that he has this knowledge himself ) Now this is an important topic for a Scrum Master solely responsible for transparency. Not only the RED JERK's behavior introduces fear and anxiety, but also it demonstrates that this behavior is OK (creating followers). This is really destructive for the Organizational Innovation Culture where key factors are fail friendly environment and attitude that "it's OK not to know and just ask" [16] . This is actually so important that I believe it should be included in the company values  [8]  (e.g Spotify [7] , Netflix [6] ). The Scrum Master should aggressively react on the RED JERK behaviors and bring this up to the higher management [13] .
  • Asking for advice:  As stated before RED JERKs see themselves as experts. This is in some sort justifiable because REDs are great learners - if they don't know something they immediately look it up. They learn mostly by themselves not mentored by someone. So what does it mean when a RED JERK is asking for advice? Unfortunately, from my experience they don't do this to learn something but to either smuggle some topic into the discussion or to secure they future plans ( "after all, I've consulted a specialist" ). So from the perspective of a scrum master my advice is to pay attention not only for what he's asking but why.
  • Wonder out loud publicly that "someone" screwed (when everybody knows who). Saying out laud publicly with Bob in the room that he would rather like to work with Alice:  Now that's probably the most JERKy behavior, because it can hurt badly the person concerned. Paradoxically, it's easy to miss and to ignore by the Scrum Master (in the rush and by other topics). It's important that you as a Scrum Master understand that that behavior undermines the core Scrum Values hence it's justifiable to schedule a 1v1 with the RED JERK and at the same time, reporting to his superior.
  • Reacting on feedback:  RED JERKs rarely receive feedback in any form. It's because they introduce anxiety and fear.  Story1 : A high management person confessed to me that he deliberately avoids the RED JERK despite the fact that the RED JERK is "just" a software developer (it shows how scary they can be) . So because they rarely receive any feedback, they lack the ability to accept it and easily get defensive. They don't see feedback as an opportunity for growth but a direct attack on their position.  Story2 : A RED JERK shared with my friend something what happened to be unethical and even against the law. My friend drew his attention to that and offered help at the same time, thereupon the RED JERK stopped to greet him and say hello in corridors, and started spreading rumors about my friend in the whole company.  OK so what works for me is to share  only  my emotions/feelings  [9]  resulted from RED JERK's behaviors. Unfortunately, criticizing a s pecific behavior will only put the RED JERK in the defense mode.  Story3:  I've only seen the RED JERK adjust his behavior in long-term when he received congruent feedback from his whole team via a 360 behavior HR process.  Because of that I'm a fan of supported by the company process behavioral feedback sessions  [5] .


  • Manage your energy don't spend it all on the RED JERK
  • Redirect the group focus from the RED JERK
  • Check if others feel the way the RED JERK does
  • Park discussions not related to the purpose of the meeting and schedule a follow up meeting on the RED JERK topic for him and others wanting to participate
  • Separate opinions from facts (coach others to do so)
  • Actively do nothing (don't help to spread opinions)
  • Facilitate co-op and ice breakers sessions with people from the conflicted camps  [12]
  • Engage others in meeting moderating
  • Request a 360 feedback tool in HR
  • Do not recruit RED JERKS  [10]
  • Help the company to value helpfulness and implement innovative culture
  • Give instant feedback on how you feel affected by RED JERK behavior
  • Report harmful behaviors
  • Clearly define which behaviors must change and what is expected  [14] [15] [17]
  • Monitor your emotions/feelings (they are great JERK behavior detector). Stop and Reflect every time your emotions seems exaggerated in relation to current situation. Look not only on what is being said but ask yourself why. Take a note of this moment and whether it is repeating.

Is a Team better of without RED?

Definitely no! There is a higher probability to get an effective team out of a balanced mixed color composition. E.g. I've encountered how destructive for a team is a dominance of Blue (which is common in IT due to bad recruitment based only on corner cases theoretical assessments). Also I've seen the best team leaders to be RED. What we should really ask is a team better of without a Jerk. I leave you with Dan Jacobs quote:

"It’s better to have a hole in your team than an asshole in your team!" - Dan Jacobs

and with the Netflix policy:

No brilliant jerks in Netflix policy  [6]

bad apple syndrome:

Bad apple behaviors: a “Jerk”, “Slacker” “Depressive Pessimist” leads to 30% to 40% reduction in team productivity!  [5]

according to a recent working paper from Harvard Business School:

" Finding Superstars vs. Avoiding Toxic Workers:(...) In comparing the two costs, even if a firm could replace an average worker with one who performs in the top 1%; it would still be better off by replacing a toxic worker with an average worker by more than two-to-one. That is, avoiding a toxic worker (or converting them to an average worker) provides more benefit than Finding and retaining a superstar."  [10]

But in the same way it's always got to reflect on your organisation and the system it's creates that promotes those jerk behaviors  [18] .


[1] Surrounded by Idiots: The Four Types of Human Behavior and How to Effectively Communicate with Each in Business (and in Life)

[2] Super chickens

[3] Brilliant Jerks in Engineering

[4] Be kind

[5] Performance Management, the new team responsibility

[6] Why Netflix Doesn't Tolerate Brilliant Jerks

[7] Spotify Engineering Culture part 2

[8] The most innovative companies all share these values

[9] List of emotions

[10] Toxic Workers (Harvard Business School)

[11] 1-2-4-All

[12] BAB Workshop

[13] Why you might need to fire your most talented employee

[14] How To Change A Toxic Culture

[15] Hey CEO! Request from your Scrum Masters Outcomes not Tasks; Ask for Values not the Process; Evaluate for Outputs not Outcomes;

[16] Fear and the Sandbox, Part 1

[17] How You Manage These 2 Kinds of Employees Will Define Your Company's Culture

[18] What to do with A-Players?

[19] Dealing with psychopaths during Agile change

Article author: Błażej Drobniuch

Back to top Contact us
The power of a Sprint Goal (examples)

The power of a Sprint Goal (examples)

In this article I will share four examples of the same Sprint Goal but expressed in different ways.

Imagine a cross-functional, cross-component Scrum Team experienced in the automotive industry who is working on an autonomous self-driving car project. Imagine that the team's Product Owner is on a business trip and can't joint the Sprint Planning with the development team. Now luckily the PO crafted an input Sprint Goal for the Dev Team so the developers can be aligned on what's most important.

First let's stop and ask ourselves what is a Sprint Goal? According to the Scrum Guide:

"The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on  WHY  it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some  flexibility  regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to  work together  rather than on separate initiatives."  [1]

So when I think about a great Sprint Goal I think about one that uncovers hidden assumptions and supports further discussion on "what problem are we really trying to solve?". To grasp this it should contain:

  • WHY?  ($ Businesses goal: What does our organization get out of the whole thing?)
  • HOW? & WHO?  (Impact: Who and how will be able to do something differently thanks to our solution?)
  • WHAT?  (Scope: What can we accomplish during one sprint that can move us towards the desired impact and outcome?)

The good the bad and the ugly!

So here are four examples of the same sprint goal but visualized and expressed in different ways.

The BAD:

A list of tasks to do in Jira as a Sprint Goal! Take a look at the Sprint Goal listed below and search for the WHY, HOW, WHO & WHAT. If you're lucky you could maybe determine what to do but definitely not why. No comments, unfortunately this is most common :(


The Sprint Goal in a form of Image! Nobody said that a Sprint Goal should be in the form of text. Remember the Agile Manifesto?  "We are uncovering better ways of developing software by doing it and helping others do it." [7]  experiment be creative! The lack of clarification of what exactly is the Sprint Goal in the Scrum Guide does not limit you, but is actually releasing. Take a look on the Sprint Goal listed below and search for the WHY, HOW, WHO & WHAT.

No alt text provided for this image

(c) Photo from  [2] Autonomous driving at the BMW #NEXTGen 2019  promo clip. Image used in this article only as an example of a Sprint Goal for a Development Team .


The Sprint Goal in a form of a User Story Map [3] ! Why not make the sprint goal two or even three dimensional. Start not from the solution but the problem that we are trying to solve. Tell the story of the user. This can really free up the creativity and result in innovation in your teams. Take a look on the Sprint Goal listed below and search for the WHY, HOW, WHO & WHAT.

No alt text provided for this image


The Sprint Goal in a form of an Impact Map  [5] [6]  (My favorite)! A great way to uncover hidden assumptions and the WHY, HOW, WHO & WHAT is an Impact Map! So why not to use it to visualize a sprint goal. Additional benefit is that it stimulates the team on planning for delivering early value [4] . Take a look on the Sprint Goal listed below and search for the WHY, HOW, WHO & WHAT.

No alt text provided for this image

The benefits of a great Sprint Goal:

  • Better collaboration and teamwork
  • Focus on value
  • Each sprint is engaging
  • High alignment
  • Enforce decision making and ownership
  • Gives a reason to celebrate
  • Flexibility and creativity
  • Feeling of purpose and autonomy
  • Stimulates discussion on possible solutions


As humans by nature, when faced with a problem we immediately focus on the solution (especially when we are being paid for that). A written down and expressed in an engaging way Sprint Goal can not only stimulate the discussion on "what problem are we really trying to solve?", but also help recall our reasoning from days before we started the implementation. An always visible Sprint Goal not only reminds us on why we are doing something but challenges decisions made in the past and provokes the search for simpler and more impactful solutions on daily basis.

A great scrum team constantly works on improving scrum artifacts. Defining a good sprint goal is a great way to achieve that. Also experimenting with different techniques for expressing the sprint goal can be helpful in introducing those also for other activities like backlog refinements or innovation sessions (which is sometimes hard especially for teams that are not used to look for different possible options to achieve specific outcomes). This could be for example a first step to try out a User Story Map as a Sprint Backlog or an Impact Map as a Product Backlog.

Experiment, Experiment, Experiment...

Good luck, have fun :)


[1] Scrum Guide

[2] Autonomous driving at the BMW #NEXTGen 2019

[3] User Story Mapping the Fashion World

[4] Make Impacts, Not Software

[5] Impact Mapping: Making a big impact with software products and projects


[7] Manifesto for Agile Software Development

Article author: Błażej Drobniuch

Back to top Contact us
How to recruit an 8 Stances Scrum Master

How to recruit an 8 Stances Scrum Master

In this article  Tomasz Moranski  and myself will share the approach that we together with  Mateusz Klimczyk  developed to recruit Scrum Masters using Competency-based recruitment process, Barry Overeem’s 8 stances of Scrum Master, and Behavioral Driven Development.

Before you go any further you must know that we won't share our recruitment process questions :) Instead, we will tell you how to develop your own process.


The topic of recruitment of a Scrum Master isn’t something new. But when we faced the challenge to recruit new scrum masters in our company we knew there is space for improvements and that we want to create our own process. This conclusion emerged from our previous experience in being recruited for a Scrum Master position and from the approach on how does HR recruit experienced leaders.

The main flood in mainstream approach:

Most companies recruit scrum masters asking theoretical questions (like in the Agile Imposters 2.0 38 questions  [0] ) or by performing hypothetical case studies scenarios during the interview meeting and asking the recruited person to imagine a situation and then looking for particular candidate behaviors (like in Case Studies for Conflict Resolution: A key element in civil rights training  [3] ). 

Although these methods bring value and can be helpful they introduce the following downsides:

  • The answers on theoretical questions can be memorized and learned upfront with no practical experience whatsoever. So we have no clue if the candidate will really do the job.
  • The hypothetical case-study scenarios during the interview don’t guarantee that the candidate will act in the same way in real life when faced with real situation involving people she will be working with. Additionally, in that approach we assume in advance that the best way on how to solve problems from the hypothetical scenarios is Our Way -which is simply not true (even if our solution worked in a certain situation, "You could not step twice into the same river"- Heraclitus).

What did we do differently:

We wanted to get true Scrum Masters. We wanted to get experienced people proven in field of Scrum and Agile. In order to achieve this we decided to create our Scrum Master's recruitment process in line with the Competency-based recruitment approach [2] .

Why do we call it BDD? :)

What we changed in the process is that we didn't start from building question first, but instead we started by defining expected behaviors.

In order to do so we created a competency map [4]  based on Barry Overeem’s “The 8 Stances of a Scrum Master” described at [1]  where he defines the Scrum Master as a Servant Leader, Facilitator, Coach, Manager, Mentor, Teacher, Impediment Remover, and Change Agent.

We knew what competencies we are looking for but we didn't knew what behaviors will define those competencies. We started to ask ourselves what behaviors do best define e.g a great facilitator who is a neutral person accepted by the group with no decision making, equipped with facilitation tools, helping the group identify potential solutions and improving the process of decision making, increasing the efficiency of meetings and following through with action points.

Surprisingly this was the hardest part. But when we finally defined the expected behaviors it was really easy to form proper questions around them. We used the Funnel  [5]  and S.T.A.R  [6] [7]  tools for that because they are great for checking the candidates practical experience.

Example:  Facilitator - one of the expected behaviors: encourages people in the group to take an active part

  • Give an example of a situation where you encourage people in the group to take an active part?
  • What was the group's challenge?
  • What approach did you choose? What actions did you undertake?
  • What was the result?

This way we designed a checklist of questions that helped us evaluate our candidates. In addition, we solved another problem. Before our checklist, we evaluated every candidate with different questions relaying on our intuition. Now, we have one candidate profile build around what's most important for us, allowing us to continuously improve our process. Furthermore, these questions and behaviors have a great use for annual performance reviews.

Our experience in practice:

It turned out quite difficult to go through all the questions for all the 8 stances in a reasonable time. Luckily, some questions verified more then one stance at a time. We ordered the questions to maximize the amount of expected behaviors shared in one candidate's answer. TIP: prioritize the questions by the potential they share to expose the candidate's behaviors most.


To create your own recruitment process go through these steps:

  • Create a competency map for the Scrum Master Position in your company  [4]
  • Define what behaviors imply those competences  [1]
  • Prepare Funnel and S.T.A.R questions for those behaviors  [5] [6] [7]
  • Experiment what questions bring most value
  • Gather candidate's answers to inspect and improve your process

Thanks for reading. If you have any questions and like the article, please comment.


Article author: Błażej Drobniuch, Tomasz Morański

Back to top Contact us
Where do you really want to work? Orange vs. Green vs. Teal (23 questions)

Where do you really want to work? Orange vs. Green vs. Teal 

On average, people spend 90,000 hours at work [21] . It's over 10 years of life! The average working time in one company is about 4 years, but for the first employer many people decide to stay longer. That's why it's important to find the company that suits you best from the very beginning. How to accomplish this without comparison and reference point? What questions should you ask a potential employer during a recruitment interview to get to know them better?

In this article you will find answers to the following questions:

  • What distinguishes some organizations from others?
  • What impact can these differences have on your career and life?
  • How do you know, when recruiting, if an organization is right for you?

First let's ask a question: How can we group organizations? A scientist Frederic Laloux has created a great organization classification placing them in successive generations going through the history of humankind.

Let's name the consecutive organization generations: RED: anarchistic like the mafia, AMBER: commanding like the army, public schools, and the Catholic Church, ORANGE: controlling like multinational companies, investment banks; GREEN: caring & paternalistic like culture driven organizations; TEAL: cellular & releasing like network organizations [1] .

Orange vs. Green vs. Teal

As for now, in 2020 most IT companies operate either within the Orange [2] , Green [3]  or Teal [4]  paradigm. Let's take a closer look and compare them in the table below:

So an orange organization is like a machine with a lot of controlling process and process imposed roles. People are seen like cogs, specialized to perform a specific task. Everybody must stay busy and resource management in excel sheets is a common associate when running out projects. The focus is on building the products.

Green organization, on the other hand, declares "We are family" and emphasize that the key to success are passionate people who are able to learn what's needed to deliver value. Teams are main building blocks and the principle is to build long-living teams. When optimizing green organization are more focused on delivering early value (instead of keeping everybody busy). Green organization concentrates on developing people, and a great product is only a side effect.

Teal organizations recognize that each of us is unique. And that the key is not to learn what is most needed but to discover your own talent and path, then follow it. Building blocks are small cellular groups discovering new ways of working and re-inviting the organization purpose.

Leaders [5]  in orange, green and teal organization:

Managers in orange organization focus on governing constraints e.g. by creating process and telling people what to do. They use a combination of reward and punishment to induce a desired behavior (carrot and stick approach). The result is an over application of control approaches and not the recognition that not all systems are ordered. This makes people break rules to do their job well. Another common pattern is that in most cases burned out "cogs" (specialists that couldn't handle the pressure) are promoted to leaders positions, which has a huge negative impact on the company culture [22]  and employee performance [18] .

Leaders in green organization are much more focused on creating a safe environment so people inside can demonstrate unsafe behavior. When a conflict arises, it can be immediately resolved by the persons concerned [17] . They take on the role of servant leaders who specify enabling constraints (e.g. by facilitating groups and coaching people to grow). The result is you get coherence with huge variation around it. That effectively allows locally valid solutions to emerge. The teams creates their own process and adjust it as needed. Decisions are pushed to the lowest level. Key leader competencies are soft skills.

Teal Leader's [6]  role is to consistently hold the space and prevent people of going back into old habits of creating processes and hierarchy structures. Remind people of deeper assumptions by saying "This is not how we do things here". Teal leaders invite people to make decisions by their own. They also create context necessary to make those decisions. Teal is far away from anarchy and this is reflected in a range of practices that these organizations do differently. Teal deals with areas such as [7] [8] : decision making, organizational structure, staff functions, meetings, conflict management, project management, dismissal, strategy, recruitment, performance and change management, planning and budgets, targets and marketing in completely different ways  [19] .

Authority in orange, green and teal:

Since orange organizations introduce meritocracy, knowledge is the key to promotion. This results in tree things: "I don't want to share my knowledge with others", "I don't want to show that I doesn't know something", "I'm better off showing others’ incompetence". Unfortunately that attitude results in a culture of fear and low transparency [15] [16] .

Green is more about peace and harmony, which can sometime result in not making difficult but key decisions. However, green is a paradigm that promotes culture of helpfulness which is the key to effective teams [14] . It's also easier to introduce more transparency which is a crucial aspect in order to react fast. Green is where Agile grows best [10] .

Teal is all about unleashing a human's full potential, that's why authority is build on wholeness. You work with people who can show up at work as their true selves. Not only ego but their deeper self. Not only masculine side but also feminine. Not only rational but also emotional, intuitive and even spiritual  [20] .

How to determine if the organization you are recruiting to is orange green or teal?

Now a crucial question would be how to determine the paradigm in with a particular organizations operates. Here are listed 23 potential question [13]  you should ask while recruiting to a particular organization to determine its paradigm. Those questions are a result of a brainstorming session performed on two specialists forums in Poland ("Trener Trenerowi Trenerem" [11]  trainers forum, and "Wszyscy jesteśmy turkusowi" [12]  teal organization forum). It's not that you have to ask all those questions. Some are even a little controversial and dangerous to ask. What's important is that you can find the answers on that questions while in a recruitment process without even asking them (just as side conversation). Another possibility is to ask friends who are currently working for this company or find someone from this company on LinkedIn and talk to them about it.

How are  hiring and firing decisions made in your company?

  • ORANGE: Someone at the top of the organization's pyramid (based on budget and the need for specialists)
  • GREEN: A leader who works with people on a daily basis often as a coach (based on matching the culture of the organization and the team)
  • TEAL: People who are working directly with candidate/that person make decisions

What are your company values?

  • ORANGE:  No values / there are values but the recruiter doesn't remember them / there are a lot of them and they are contradictory / cynicism in conversation about values
  • GREEN:  The values are not contradictory / the leader tells what is hidden under them / the CEO defines them
  • TEAL:  They are not clearly defined / are fluid and live their own life / people in the organization talk a lot about what the organization is guided by

If I wanted to introduce a new tool in the workplace that would require investments and training of people, what would have to happen for me to succeed?

  • ORANGE:  You must convince HiPPO (highest paid person's opinion)
  • GREEN:  You must involve others in the decision making (Consensus / Democracy)
  • TEAL:  Everyone can do this (after consultation with the specialists in that field)

How are decisions made to start and stop a project?

  • ORANGE:  Someone at the top of the organization's pyramid makes the decision
  • GREEN:  A business person supporting communications with the client, stakeholders and the development team makes the decision
  • TEAL:  People who are involved in creating the product make the decision

Who onboard employees on their tasks?

  • ORANGE:  Team Leader / Group Manager
  • GREEN:  Person from the team to which the candidate came (volunteer)
  • TEAL:  "Sherpa people" (colleagues responsible for your development)

How often as a manager do you ask employees for feedback on your work?

  • ORANGE:  Never / Only when the HR department expects it
  • GREEN:  Regularly during 1v1 / we have 360
  • TEAL:  I ask for feedback people I work with on daily basis

What is your company proud of?

  • ORANGE:  We are proud of our product / technology we use
  • GREEN:  We are proud that we are all family here
  • TEAL:  We are proud of how we are changing the world

What is the company's policy when it comes to payment transparency and salary raise?

  • ORANGE:  Lack of disclosure. Manager by recognition and budget
  • GREEN:  Pay grade levels according to seniority. Known to everyone. Periodic evaluation with the Leader
  • TEAL:  Everyone knows how much someone earns. If you think you deserve a raise, you just communicate it within the organization

Give an example for which you would punish an employee?

  • ORANGE:  Employee does not perform his tasks
  • GREEN:  Employee does not consult ideas / is a bad team player
  • TEAL:  Employee Does not fit our way of working

What do you value most about your boss?

  • ORANGE:  He gives 120% / "defends our group" / "can get budget when needed" / "reacts when there are fires"
  • GREEN:  That she express the interest both in my success and well being. Her feedback that can challenge you directly but at the same time carries personal care for your person
  • TEAL:  No boss

What are the example team names in your organization?

  • ORANGE:  Technical names / components / architectural layers
  • GREEN:  Names selected by team members
  • TEAL:  ???

Give an example for which you (the organization) would reward an employee

  • ORANGE:  He does overtime / does his job best
  • GREEN:  He is pro-active / helps others
  • TEAL:  He looks for what he is best at and does it

What is the procedure when the employee has nothing to do?

  • ORANGE:  We assign tasks to him / transfer him to another project
  • GREEN:  Division of tasks is a matter of the team / let them use their free time for learning (if it's ok for the team)
  • TEAL:  The employee chooses what's most valuable in his opinion and does it (self-management).

What do you value most about your subordinates?

  • ORANGE:  That they do their job well
  • GREEN:  That they are growing (developing themselves)
  • TEAL:  N/A

What is the structure of your organization?

  • ORANGE:  Pyramid
  • GREEN:  Flat
  • TEAL:  Cellular

How often will I work on tasks with people outside my team?

  • ORANGE:  It happens / people work on several projects simultaneously here
  • GREEN:  Very rarely / the team works on its joint goal / we value teamwork and long-lived teams
  • TEAL:  ???

What job titles do the people I'll will be working with have?

  • ORANGE:  POSITIONS RESPONSIBLE FOR THE PROCESS (Product Manager, Error Manager, Quality Assurance...) [many different positions]
  • GREEN:  Only Software Developers (who have different competences needed to deliver working product) and supporting roles, e.g. Line Manager, Product Owner, HR [few positions]
  • TEAL:  No job titles (only pro forma) everyone has different roles the job titles are not important

Who during the recruitment asks technical questions?

  • ORANGE:  Your supervisor / asks both technical questions and checks candidate experience
  • GREEN:  A person from the team ask technical questions, the supervisor checks experience & cultural fit
  • TEAL:  A team member asks technical questions and checks experience. The last stage is one work day with the team

How would you describe the HR department in your company?

  • ORANGE:  Opinions without facts / Language we vs. them / cynicism
  • GREEN:  Language of facts / puzzled by the question / listing of HR tasks with ease
  • TEAL:  No HR department / Sourcing only

How are conflict situations resolved between people in the company?

  • ORANGE:  Your supervisor talks to the supervisor of the person you are in conflict with (mediation / escalation)
  • GREEN:  "As your supervisor, I will support you so that you can resolve the conflict directly with the person concerned"
  • TEAL:  We have a dedicated framework / way to resolve conflict in our organization

What is the company's CEO focused on?

  • ORANGE:  Makes key decisions
  • GREEN:  Crafts the organizational culture / talks a lot about values
  • TEAL:  Makes sure that the organization remains teal, invites people to make decisions and is the face of the company

[job description in the job offer]

  • ORANGE:  Extensive; many responsibilities; listed processes and policies
  • GREEN:  Short list of responsibilities; Company values listed
  • TEAL:  includes in the description that: "you apply to teal organization"

What is the access policy for tools and code base

  • ORANGE:  Very restricted, only process roles has rights
  • GREEN:  Everybody that works on code has access to codebase and tools
  • TEAL:  Everybody chosses their tools


It's not that green is better than orange, and teal than green. It's about what do you really looking for yourself. I know people that feels best in green organization. I know people that feel best in orange organization. And I know people that are teal. If you seek structure and power go for orange. If you look for consensus and friendly work environment go for green. If you want to challenge yourself and are ready for a journey to discover yourself go for teal.

It's not that organizations are pure orange, green, teal. There always a mix of subcolors. Organizations can also change their colors in time but this is a topic for another article.

Article author: Błażej Drobniuch

Back to top Contact us
Does a Scrum Master need Conflict Resolution Skills?

Does a Scrum Master need Conflict Resolution Skills?

Going through some job offers for Scrum Masters, I couldn’t but notice that in most of them conflict resolution skills were expected. So here is the question: does a Scrum Master need conflict resolution skills?

Before we go any further, please do this short exercise. Let's imagine that you are recruiting a Scrum Master and that you want to check if she demonstrates conflict resolution skills. Take a sheet of paper and for 2 minutes try to define what you would expect as an answer from your perfect candidate for the following two questions:

  1. "Describe a situation where you encountered a conflict situation in your Scrum Team as a Scrum Master?"
  2. "What actions did you undertake?"

Stop! :) don't scroll any further. Try to answer those questions

Back to my question "Does a Scrum Master need Conflict Resolution Skills?", Well.... in my opinion probably not the way you described it!  [Let's continue to find out if I'm right]

For now, please answer another question: Is a conflict a bad thing?

Answer: not at all [11] .

Conflict Matrix: five conflict-handling modes [24] [1] .

Best solutions and outcomes are a result of cooperation aiming not for compromise but for collaboration! And conflicts are a necessary mean to get there!

The job of a Scrum Master should be to create an environment for the teams where they can optimize for collaboration. I like to bring up this quote:

"Safety actually means demonstrating unsafe behavior"- Gunther Verheyen

The Scrum Master role is to establish a safe environment. What we need to understand is that safety doesn’t mean peace and harmony but actually quite the opposite, namely, an environment where people engage more often in conflicts (owning them) leading not to compromise but true cooperation. The goal should be to create an environment where the team is able to resolve conflicts in non-harmful way by themselves.

" ...Conflict is frequent because candor is safe. And that's how good ideas turn into great ideas, because no idea is born fully formed. It emerges a little bit as a child is born, kind of messy and confused, but full of possibilities..."  [10]

Here is how the Scrum Master should approach conflicts with regards to conflict escalation level:

Options for Conflict Situation Level vs Conflict: Cost & Complexity & Escalation.

Let’s go through some examples for every conflict level.

  1. Create Environment:  as a Scrum Master, you should create an environment that fosters collaboration even before any conflict occurs. Aim for the culture of helpfulness [10] : get the people to know each other better, stop rivalry, solve problems together, and help each other so the team members interact with each other from a place of wholeness [19] . You can do that starting with small things like introducing Kudo Box in your organization [2] , facilitating team building activities [14] , introducing liberating structures [12] , organize Mob Programming sessions [22] , setup tools improving remote work [21] ; to big topics like fostering Scrum Values, working with HR on the culture and values of the organization [3] , flattening the organization and going Teal [13]  - anything that works, experiment with the goal to promote helpfulness & wholeness.
  2. Implement process : Create a process for the teams where they can handle occurring conflicts [23]  and direct them to increase cooperation by bringing tensions to the surface  [20] . E.g. retrospective where everybody can speak up loud [15] , facilitate meetings improving teamwork [8] [9] , introduce alignment tools like impact mapping [17] , engage HR in creating a 360 feedback tool [5]  giving the opportunity to confront in a more healthy way etc.
  3. Train:  Help the team increase their competences that could help in a conflict like: how to communicate [7] , giving feedback, conflict resolution [16] , teamwork, assertiveness, problem solving etc. engage HR to help you!
  4. Mirror:  Many times, the Scrum Master should act as team coach [4] , being a "mirror" for the team helping them better see and spot their behavior in order to improve and learn faster. Using coaching tools like: listening, empowering, articulating what's going on, open questions, powerful questions, giving feedback, sharing emotions, visualize the room temperature, bringing up taboo topics, be an example: demonstrate openness and vulnerability and more.
  5. Coach 1v1:  You should avoid 1v1 coaching when dealing with conflicts. When it pops up while coaching on a different topic, it's OK to engage. But you should definitely not schedule 1v1 coaching aimed solely to handle conflict. It's the role of the Line Manager! What you should do is to coach and teach the Line Manager to acknowledge the value of coaching in conflict resolution. It's important to change her attitude so she starts to resist the temptation to be a mediator or arbiter and move towards coaching and council, since the goal is to develop proactive teams willing and able to solve their problems themselves!
  6. Council:  Definitely a no! It's OK to share own experience (what worked for you), but if you want to be a professional Scrum Master don't tell people what to do!
  7. Mediate:  Do not mediate! The best thing that a Scrum Master can do is actively do nothing! A conscious withdrawal of own projections and "Help" deepens the problem! Just listen the person out. Mediation is a job for HR, who have prepared procedures and needed competence for that occasion. If that's not the case, then I would support the Line Manager in the decision to deal with the people who are the cause of an unhealthy escalation. It's a hard decision but it's a right one in order to prevent toxic workplace. There is no place for mediation in a Scrum Team!
  8. Arbitrate:  (same as Mediate).
  9. Fire:  When you feel that that's the case, support, couch and provide legit data for the Line Manager so she can make the right decision [6] ! E.g. Bad apple behaviors: a “Jerk”, “Slacker” “Depressive Pessimist” leads to 30% to 40% reduction in a team's productivity [5] ! It's the Line Manager's job to "rescue" the team from their frustration and misery! But it should be done the right way [18] .
  10. Litigate:  Guess it's a case for lawyers!


The Scrum Master role is not to resolve conflicts but to create an environment where people cooperate and conflicts arise as often as possible leading to great ideas. I believe that there is nothing that suggests that Scrum Masters should have greater conflict resolution competencies than any other member of the Scrum Team. What a Scrum Master should really have is great team coaching competences to develop a team that handles conflict themselves.

Watch this scene from the movie "Remember The Titans" where the Team Coach resists and doesn't engage in conflict resolution


What do you think? Please let me know in the comments!


Article author: Błażej Drobniuch

Back to top Contact us
This 4 guys, while introducing change [my five tips for you]

This 4 guys, while introducing change [my five tips for you]

When trying to run an experiment and improve something in an organization I always come across these four different groups of people:

  • group #1: "We can't do that in our organization!"
  • group #2: "You will tell us what to do to be Agile!"
  • group #3: "We need to figure out how to make it work for us!"
  • group #4: "hm../meh"
No alt text provided for this image

"We can't do that in our organization!"

While trying to change something I was approached by those guys many times. When an idea is being introduced, they say  "We can't do that in our organization"  followed by:

  • a huge list of corner cases, and reasons why it will fail
  • a statement that the organization is in some kind special and just not meant to be Agile (but without justification or any valid arguments)
  • a panic reaction that it will break the product, the business or slow the development considerably (but not willing to find answers on how we could make it work)
  • a suggestion that they are already doing this with examples which are actually changing the meaning of what we are trying to achieve (e.g.  [6] ).

My advice is not to engage in trying to convince them to run the experiment, since their goal isn't to prevent the organization from failing, but to maintain the status quo [5] .

However, it's a very good idea to listen to them, because some of the arguments they state can actually help you justify the experiment, since those are usually the symptoms of the problem you are trying to solve. Everybody around says that the project is doomed, so we need to try out something new, anyway.

How to determine that we're dealing with the "status quo" guys and not truly concerned employees? You will be able to observe that they do not listen to you and just repeat same stuff like a broken record. Also they will change the topic when presented with valid counterarguments.

TIP#1: When they state  "We can't do that in our organization"  while you are introducing the experiment, park that statement and encourage them to approach you after the meeting to figure out how we could address all the potential threats. If they are really concerned, they will reach out. 

No alt text provided for this image

"You will tell us what to do to be Agile!"

They are either naive that the world around can change without them or just stating this for PR reasons so they can claim  "we're Agile"  and be a part of a potential success. From my experience, they will change their minds at the earliest opportunity.

These guys are a great counterweight to the pessimistic  "We can't do that in our organization!" , but if they approach you, be only a mentor and storyteller. Don't give in and don't engage to run the experiment at their backyard because they aren't committed to the change. Otherwise, your experiment will end halfway as a failure.

They're typically over optimistic. They don't share potential risks that should be addressed before running the experiment. When working with them, you will also notice that they don't really team up with you. Instead, they treat you as an executor or a knowledge base.

TIP#2: Ask them: "Could you please share with me what exactly did you do since last month to improve your organization agility or remove any wastes?". If they really want to become Agile, they will have no problem with that question. Remember that by improve you don't mean create more process and roles but: more value, more purpose, more understanding, more passion, more reliability, more responsiveness [4] .

"We need to figure out how to make it work for us!"

These are those guys you're looking for. Change agents that see problems and are looking for solutions. They want to team up and follow it through to the end. They engage with you and share problems they see, and brainstorm with you on possible solutions.

When you are proposing improvements, they ask the  "yes, but"  questions (only one at a time), discussing the topic until they're confident that the experiment won't backfire and when they really feel that it promises more benefits then potential drawbacks. You also have the feeling that they listen to you, and you eventually end up as friends :)

TIP#3: They are open to learn, so share interesting videos and readings with them.


This group is rather interested in developing the product and focused on everyday work and new technologies. They don't think so much about the organization's ways of working and wastes in the process.

Monitor them since they can be easily pulled on the side of "status quo" defenders.

Their characteristic is that they are realistic and sometimes critical, but they never enter the never ending loop of  "We can't do that in our organization!" , and are always open for small experiments.

Decide if it is helpful to convince them to run the experiment or just do it anyway, since they probably don't care so much.

TIP#4: They are great in giving valuable feedback afterwards which is helpful to determine if the experiment was successful.


A successful Agile transformation needs to be both top-down and bottom-up. The best way to succeed is trying to find change agents [1]  inside the organization and team up with them. Combining their long term business domain experience with yours from other companies can result in a really convincing strategy that can engage management and make them support the change.

TIP#5: Don't just focus “vertically” on people above your position but also create “horizontal” alliances with others in the organization.

Remember you're not responsible for the success of Scrum in your company [2] . You are only responsible to try everything possible in your zone of control to make it happen [3] .

What's your experience with people while introducing change? Do you have the same observations or maybe quite the opposite? What's your strategy while introducing change? Please share your stories and thoughts in the comments below..


Article author: Błażej Drobniuch

Back to top Contact us
How I've used Story Cubes too break ice between Teams from different countries

How I've used Story Cubes too break ice between Teams from different countries

In this short article I will share my facilitation guide for a creative Ice Breaker exercise using Rory's Story Cubes® for teams working on the same product but in different locations.


The team I've recently joined from Krakow, Poland was visiting our headquarters in Austria and meeting other people involved in the development of a game we just finished. We had planned a big retrospective and meetings related to the next important milestones.

What I needed was a way to create a safe and relaxing environment for me and other team members, especially new ones, and those not so comfortable in speaking English. My goal was to put our fears aside, build relationships, focus on our goals and recharge batteries after a long car trip. In order to achieve this, I've proposed to start with an Ice Breaker exercise.

I was politely warned:

"But please don't force us to touch each other"

Hence I knew they probably had previous experience with irrelevant, pointless, or poorly designed icebreakers. So in order to make it work it had to be fun, creative and non-physical.

I've searched trainers Facebook groups and found Mateusz Kałamarz (Design Thinking Facilitator) who shared his experience with Rory's Story Cubes®.

I only had to redefine the game mechanics to achieve what I've intended. Finally I've created a 15 minutes Ice Breaker which served its purpose surprisingly well.

About Rory's Story Cubes®:

"Rory's Story Cubes® is the iconic storytelling game that fosters imagination and connection across generations."[1]
"Rory’s Story Cubes® originated as a creative problem solving tool for adults, way back in 2004. Rory was a creativity trainer and coach, working with individuals and organisations to look at problems in different ways. The idea was conceived using an invention technique called ‘Advanced Civilisation’ (by Win Wenger)."[1]

Ice Breaker Facilitation guide:


  •  integrate teams working on the same product
  • get everyone involved 100% right from the start
  • help new members get to know each other
  • creative warm-up on the product topic
  • begin an interesting conversation among participants
  • practice English
  • prevent another boring meeting


  • 4x Rory's Story Cubes® sets (e.g stories, voyages, actions, fantasia),
  • For each participant a Facilitation guide for the Ice Breaker exercise in A4 format.


  • [3min] explaining the purpose and goals of the ice breaker, giving out handouts, introducing the Rory's Story Cubes®,
  • [6min] part one (pairing up and storytelling),
  • [6min] part two (sharing stories in a big circle).

Instructions part one (pairing up and storytelling):

  • randomly take one STORY CUBE from the pull of 36 cubes on the table
  • pair up with someone you know least
  • roll the Cube dice
  • your task is to learn a story from the life of your pair/mate related to the icon on the cube
  • you've got 2 minutes each
  • (if there is still time)* roll with your pair/mate two dices and create a story about the product you are developing basing on those two story cubes

Instructions part two (sharing stories in a big circle):

  • gather in a circle with the rest of participants (next to your pair/mate)
  • introduce your pair/mate
  • tell what picture was on the dice
  • tell what story did you learn about your pair/mate
  • together with your pair/mate tell the short story about the product (If you had time to create it)

Facilitation Guidelines:

  • Take your time to introduce Rory's Story Cubes® (they arouse curiosity so the participants don't focus on the instructions).
  • It's common that participants ask the facilitator what particular image on the cube means. Tip: Just tell them it's up to them.
  • When working in pairs make sure they understand the task and stay focused, remind them about the additional task to "create a story about the product you are developing" when they still have some time left.
  • When presenting the stories in groups make sure they introduce their pair/mate by name, and show the whole group what was their picture on the Story Cubes.


The Ice Breaker worked really well and I received positive feedback. We had a lot of fun, The Ice was broken and we gained new energy to follow up with the big retrospective. I hope it will work similar for you.

Other scenarios for the ice breaker:

  • team retrospectives
  • on-boarding of new team members
  • brainstorming sessions
  • group coaching sessions
  • joining new team as a Leader, Scrum Master etc.

Please let me know if this article was helpful in the comments below.


[1] Rory's Story Cubes®

Article author: Błażej Drobniuch

Back to top Contact us