These are awesome, Guillaume. Great suggestions - thank you for sharing!
Post by Guillaume LederreyIf we want to talk more about emotions, feelings and all those fuzzy
things (which I think we should, it isn't because it is fuzzy that it
isn't important!), we usually need to bring different kind of tools to
the table. Language tends to steer us into analytical thinking.
Language requires us to build structured thoughts and tend to not help
all that much to get us started into a deeper discussion of
interpersonal issues, or discussion about emotions. I know the "left
brain / right brain" is a gross over simplification of how our brain
work, but it is a useful metaphor here. Language activate our
metaphorical analytical left brain more than our metaphorical
emotional right brain.
So we need tools to activate our right brain. I have a bunch of them,
but none is adapted to a distributed setting. Or at least not without
quite a bit of modification. Still a few idea, someone might know how
* photolanguage [1][2]: A classic that seems to be more documented in
French than English. By bringing pictures into the game, we activate a
different kind of thinking. In short, the instruction could be "In all
the pictures that are "here", find a picture that expresses something
that your team did well this past week". Discussion starts from the
pictures.
* positioning games: I can't find a link for that one, but the general
idea is: "please move along the wall here according to how you found
the last feature development went, if you think it was really crap,
move to the far left, if it was brilliant, move to the far right, if
it was just ok, move in the middle...". Having people physically move
around tend again to activate different ways of thinking. I have no
idea how to adapt this to a distributed / online retro...
* I have an unnamed variation of the rocket retrospective: find one
thing that went well, one thing that went bad. Write 2 words (max) on
2 pieces of paper (one piece with what went well, one with what went
wrong). Pass one piece to your left neighbour, the other to your
right. The person receiving the piece of paper must imagine what that
thing was based on the 2 words. While not as radical as the 2 other
examples, this tend to stimulate imagination more. Variants can be
that the person receiving the paper must present a solution /
improvement to the problematic thing, or a way to generalize what went
well. We can add constraint such as "the solution must be implemented
by the person proposing it", ... The more constraints, the more we
need to think outside of the box.
I might add the "adjective game" in a follow up.
[1] https://fr.wikipedia.org/wiki/M%C3%A9thode_Photolangage
[2] http://www.picturetelling.ch/e/method/
[3] http://tastycupcakes.org/2014/06/the-rocket-retrospective/
Post by Arthur Richards+1 to Strine's thoughts. Very similarly and in line with David said about
getting a team to name emotions that occurred around mechanical feedback
(I'm removing the 'factual' part that David originally included because
emotions are facts too!), I've also had success combining the "mad, sad,
glad" format with the "timeline" format (also in the Esther Derby book,
which worked really nicely for a more engineering-centric group. The
timeline portion helped lay everything out in a logical, event-based
(feeling-free) manner; but then layering the "mad, sad, glad" piece on top
of that helped reveal how folks were feeling about various events that
happened, which spurred deeper conversation.
Post by David StrineThe book "Agile Retrospectives" by Esther Derby and Diana Larsen has a
section on managing group dynamics and a description of the "Mad, Sad, Glad"
format. I also found an online example here [1].
I've found that if you get a team to name emotions that occurred around
the mechanical/factual feedback you can get a glimpse into the interpersonal
issues. The emotional statements open the door for you to dig deeper ask
pointed questions.
[1]
https://www.retrium.com/resources/techniques/mad-sad-glad
Post by Kevin SmithHi all,
I'm looking for advice about how to structure retrospectives to encourage
more feedback about interpersonal issues. I believe the teams I work with
feel the retros are a "safe space", but the vast majority of the issues that
come up are mechanical, not personal.
Of course, it's possible that there really aren't that many interpersonal
issues on these teams. (They do seem to be more emotionally healthy and
mature than many teams I have interacted with.) But I don't want to take any
chances. And I don't have a ton of experience running retros, so I'm hoping
those of you with more experience can provide some pointers.
Thanks!
Kevin Smith
Agile Coach, Wikimedia Foundation
_______________________________________________
teampractices mailing list
https://lists.wikimedia.org/mailman/listinfo/teampractices
_______________________________________________
teampractices mailing list
https://lists.wikimedia.org/mailman/listinfo/teampractices
_______________________________________________
teampractices mailing list
https://lists.wikimedia.org/mailman/listinfo/teampractices
--
Guillaume Lederrey
Operations Engineer, Discovery
Wikimedia Foundation
UTC+2 / CEST
_______________________________________________
teampractices mailing list
https://lists.wikimedia.org/mailman/listinfo/teampractices