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:
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.
[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.
Summary:
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.
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]
.
Summary:
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]
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
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]
.
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 INSPIRING:
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.
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.
The IMPACT MAKER:
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.
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
Summary:
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.
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.
Backstory:
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 Scrum.org
[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.
Summary:
To create your own recruitment process go through these steps:
Create a competency map for the Scrum Master Position in your
company
[4]
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?
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
Summary:
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.
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:
"Describe a situation where you encountered a conflict situation
in your Scrum Team as a Scrum Master?"
"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?
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.
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.
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.
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!
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.
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!
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!
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!
Arbitrate:
(same as Mediate).
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]
.
Litigate:
Guess it's a case for lawyers!
Summary:
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!
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"
"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.
"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.
"hm../meh"
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.
Summary:
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..
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.
Backstory:
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:
Goals:
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
Handouts:
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.
Agenda:
[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.
Summary:
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.
![This 4 guys, while introducing change [my five tips for you]](resources/images/blog/t4g_small.png)
