Are you aware of the stories you tell yourself? – Clean Feedback

Have you ever wondered how discussions escalate into shouting matches? Into a series of accusations and “I never said that!” “Yeah, you did!”

Us humans have a tendency to think that the stories we tell ourselves in our heads are the actual factual truths. We are rational beings after all. Or are we? At least we can trust our perceptions, right? Not really, either. We make stuff up all the time.

Point in turn: This – only tangentially related but super-awesome – twitter thread on the brain making shit up. Read it, I’ll wait:

On a more abstract level it is hard for us to separate between the things we actually see and hear and the story we tell ourselves about it.

A great way to think about this is with the Clean Feedback model by Caitlin Walker. It separates feedback into three components:

  • Evidence
    This is about observable behavior. What have you seen or heard? There is no judgement here.
  • Inference
    What meaning do you make of it? How do you interpret the evidence? What is the story you tell yourself?
  • Impact
    How does that make you feel and behave?

Here’s an example:
“When you are absent-minded in the meeting, the meaning I make of this, is that I’m not important enough to pay attention to, which makes want to avoid you.“

Could you identify the different components? I hope not, cause that was a trap. Being “absent-minded” is not a real observation. It’s already an interpretation. So what are the actual things I’ve seen and heard?

Lets try again:
“When we’re in a meeting and you look on your mobile a lot and pick it up and use it, I assume that I’m not important enough to you and in turn I want to avoid meeting with you. It also makes me sad.”

The tricky bit is that we often think of our inferences as the evidence. But it’s worth it to try to separate it into parts.

Unpacking thoughts like this makes it easier to judge less and stay curious. When shared with the other party it’s easier for them to understand how you arrived at your interpretation of events. And they can set things straight and say what they really meant.

Have you ever tried Clean Feedback? What happens in your conversations when you do?

(I’ve learned about Clean Language and Clean Feedback in this online course by Judy Rees and Olaf Lewitz. It originates in the book “From Contempt to Curiosity” by Caitlin Walker.)

PS: Like what you're reading? Join the Finding Marbles newsletter to get new blog posts in your inbox!

“How can I excite others for retrospectives?” – Don’t be too elaborate

“I’d like to share the awesomeness of retrospectives. How can I excite others?”

On the surface, this question is similar to last week’s about motivation. But they are asked in very different moods. People who ask “How can I motivate people” are subdued. They’ve often run a couple of retros that somehow fell short of expectations.

People who ask “How can I excite others?” are bouncing on the balls of their feet, eyes sparkling. They haven’t run a retro yet, but they want to hold ALL the retros! They are so excited that they want to wow everyone away with how awesome of a first retro they facilitate. They come to me looking for some ultra fancy activity from the Retromat treasure trove.

And I don’t deliver something fancy. Instead I’ve got a word of caution: If you want to convince people that retrospectives are a fabulous idea, then don’t make it too fancy. Don’t start with something that’s far removed from people’s normal interactions. It’s likely to confuse or make participants defiant. Depending on the team, appearing as too much of a tree hugger hurts your credibility. Let’s ease everyone into it.

In my experience a “normal”, well-facilitated retrospective already has a huge effect. You don’t need more than that to get started. If the participants get real benefits (shared understanding & improvements in their work flow), they usually want to do it again. Keep your enthusiasm and down the line you get to try funkier activities 😉

Btw, I totally get the desire to create something elaborate. When I introduce teams to retrospectives in my freelance work I always get the urge to pick special activities. I mean, they are paying me the big bucks. How can I possibly go there with a variation of my default retrospective? Well, because it’s the right thing to do: It’ll get them good discussions and actionable action items. It’s easy to understand what’s happening and what to do. It’s versatile and they can repeat something similar without me. And remember: These well-worn tried-and-true activities are new to them.

If that hasn’t convinced you, let me share some anecdotal evidence with you:
A friend of mine just started at a company where retrospectives have a bad rap. He’s a developer, but he pushed for a retrospective in his team and facilitated it himself. The team doesn’t have an agile coach and he was new so he didn’t have a huge stake in the content, yet. He’s a good facilitator but it’s not his main job. This was his first real retrospective ever.

He took my default retrospective and adapted it a bit. The feedback he got was along the lines of “The best retrospective I have ever seen in this company with a wide margin”. Really great for him, really terrible for the company. That’s why I think you don’t need anything fancy to start. Just the basics, well done.

Does that make sense? Have you ever introduced people to retros? How did it go?

PPS: Have you heard of Wall-Skills.com? It’s main idea is teach people basic concepts when they weren’t looking for something to learn, e.g. about retrospectives or the agile mindset.

“How can I motivate people for retrospectives?” or Retrospectives are Step 1 of 2

“How can I motivate people to do retrospectives?” is a question I used to hear frequently.

If you ask me, that’s the wrong question. It’s wrong because you don’t have to motivate people to do something that they perceive as valuable.

Which makes the real question:
Why aren’t they getting value out of their retrospectives? And is there anything anyone can do to get them their money’s time’s worth?

The only time, when the “motivation” question is admissable is if you’re trying something for the first time. You’ve never done a retro before? Yes, then you’re asking for a leap of faith from participants. And maybe the first one is wonky and you need a second one to make it count. But that’s it. From then on retros have to pay their own way – just like any other meeting should. If it’s not creating value then why are you doing it?

Btw, the retrospective itself is usually not the problem. It’s what happens afterwards. Which is often enough: nothing. It’s unfair to tell people “come on, we’ll look for improvements” and then not implement a single improvement idea. The actual meeting is Step 1. Following up on the agreed upon action items is Step 2.

Change happens

Sometimes this problem with Step 2 originates in the retro: The improvement ideas are too vague to be actionable. Other times it’s outside: There’s not enough time or money to do anything. If retrospectives don’t affect any change or these changes aren’t beneficial the majority of times, then yes, people don’t want to do them anymore. And rightly so. They shouldn’t. In these circumstances, retros are a waste of time.

Ironically, I’d use a retro to figure out what’s going wrong and how to actually make them more valuable 😛
But only after I did my homework. And I’d try something new, not the same format that failed people before. Maybe this one.

PS: Interested in retrospectives? Sign up to the Retromat newsletter to get related news and tricks!

Raise your hand to speak – Self-Facilitation Basics

For somebody who spends as much time as I do on thinking about what we do at sipgate and why it works, I missed a tiny, big detail for a really long time: Our meetings work much better than at most other places because we raise our hands when we want to speak. And we talk in the order of hands being raised.

There’s this book I’m procrastinating on writing to help teams facilitate their own meeting. And it never occured to me to include raising your hand. I had thought about talking sticks and keeping a visible list for big groups, but not about “queueing” to speak. Which is kind of the basis for all the other things that work well in our meetings and the reason we rarely interrupt each other.

I only realized this, because my colleagues talked about someone who didn’t wait their turn and how super irritating this is. It ruins the flow and also makes it more likely for others to display bad meeting manners: Interrupting others becomes more frequent because everybody is anxious to get their thoughts out.

Even now that I’m writing it down, I feel like it’s too basic, too obvious to be mentioned. I mean: “You want nicer, fairer meetings, in which people are not talking over each other? Gee, have you tried taking turns by raising your hand to get the word when it’s your turn?” Duh.

But then again, I rarely see the hand raising in other environments and meeting flow is worse for it. So, I’ll be happy to state the obvious, if it helps some team, somewhere.

You’re meetings are going smoothly without hand raising? Great! Maybe it’s because you’ve got a facilitator? Facilitators can often guess who wants to speak, based on body language. And give the floor to that person either explicitly or also using subtle body language. I often give somebody the floor, by raising my open palm towards them or just looking at them with my head cocked.

But facilitators are not mind readers so even then the hand raising bit helps. And when there’s no facilitator it helps a lot! If they know who wants to speak, the more confident team members can give the floor to shyer ones, who wouldn’t just talk over someone else to be heard.

So, yeah, queue to speak and get more orderly meetings with a fairer distribution of “air time”. Peace Out 🙂

PS: Like what you're reading? Join the Finding Marbles newsletter to get new blog posts in your inbox!

Help, our retrospectives are complain-fests – How to turn blame and whining into action

Here’s another gnarly retrospective problems:

“Our retrospectives are huge complain-fests. All the team ever does is blame others and whine, whine, whine. Honestly, I don’t know what to do…”

This seems to be a common situation in newly agile teams judging from how often I have heard descriptions like that: The team eternally blames external parties. Naturally, they never come up with any action items. Why would they when it’s all somebody else’s fault anyway…

Blaming others is a convenient way to avoid taking responsibility and changing oneself. So how do you get a team out of this attitude? I describe several tactics in the ebook “Retromat – Run great agile retrospectives” and wanted to share them with you, too:

“What are you going to do about it?”

I start by stressing “you” a lot, as in “What are _you_ going to do about it?”

Here are activities supporting this angle:

Solution focus

Surprisingly you can also try a very positive angle: Talking about what the team did well sometimes opens up a window to also talk about what didn’t work out, e.g. with an Appreciative Inquiry.

In general, I’m a fan of the solution-focused approach, where you avoid analyzing the problem and look for things to try out instead. These activities fit this approach:

Change perspective

A change of perspective can help the team to empathize with their scape goat and see things in a new light. It can also do wonders if the scape goat attends the retrospective and shares their view and reasoning.

Try:

If all else fails I try an intervention along the lines of “We can’t change other people. We can only change our own perspective and behavior.”

Have you ever tried one of these with a finger-pointing team? How did it turn out?

PS: Interested in retrospectives? Sign up to the Retromat newsletter to get related news and tricks!

Ad-Hoc Leadership

[This topic in German will be part of the upcoming 2nd sipgate book \o/].

We don’t have any middle management at sipgate. In our teams nobody is anybody else’s boss. Hearing this, visitors often assume we’re without leaders. In fact, the opposite is true.

(Disclaimer: We do have a hierarchy. It only has 2 levels but it’s there. Our not-so-called C-level sets strategy and everyone else is trying to execute it.)

The roles of Scrum Master and Product Owner have elements of leadership in them. Product Owners have authority about what is being build. They do not have authority about people, their jobs, how the team builds something or the broader organizational setup.

Because nobody gets to lead solely by the power vested in them by some management title, everybody takes the lead sometime. If something is important to you and you don’t take the lead, there’s a chance nobody will. Fortunately, the issue that’s important enough to take action is a different one for different people. So it distributes nicely.

Some people will now object that there is always an informal hierarchy in a team anyway. And someone at the top. After pondering this for months and qualitative surveys at the coffee machine I can’t confirm this. Who’s on top is ever-shifting. Within any given team there are several people that lead, depending on the area in question. UX? Dan. Java? Lara. JavaScript? Kim. We follow their lead because we trust them to best judge the long term consequences of any decision. And yet, they usually don’t decide on their own, but together with others.

I’m pretty sure that half my colleagues would be team leads in other companies. They’ve got all the skills you’re looking for: take responsibility, present results in front of 100+ people, give constructive feedback, facilitate discussions and they’re reflected.

Btw, this post isn’t called “Agile Leadership” for a reason. In my experience, when managers talk about “Agile Leadership”, they babble about “empowerment” while keeping the existing hierarchy and its reporting structure as it is. Yeah, right. Wash me but don’t make me wet, much?

And what do we get from having a flat hierarchy? Everybody takes responsibility. We can take decisions fast. We don’t waste time on political games. Instead we can add value.

PS: Like what you're reading? Join the Finding Marbles newsletter to get new blog posts in your inbox!

Scrum Masters and Agile Coaches need an Emergency Fund

Scrum doesn’t fix an organization’s problems. It makes problems glaringly obvious so that you they have a chance to fix them themselves. Except that “glaringly obvious” is relative and sometimes you still need someone to point to the steaming pile o’ shit of a problem and say it out loud. Sometimes to someone that has the authority to fire the messenger.

As a Scrum Master or agile coach it is part of your job to speak truth to power if necessary. And while it’s certainly a good idea to work on delivery, and phrasing hard truths in a way that make it possible for the recipient to accept and stomach them, there’s still a risk involved.


That’s why you need to have a certain level of independence. And a big part of that independence is money. How can you expose someone to an uncomfortable truth, if that person can fire you from a job you depend on? Depend on for rent, for food, for insurance. For your kid.

It’s a whole lot easier to “have guts” if you have an emergency fund, e.g. 3 to 6 months of living expanses in cash in a bank account. How many months you need depends on how fast you think you can land another job. Ultimately it depends on what you need to feel secure. My need for financial security is high, so we’ve got 12 months. This is just living expenses, not fancy vacations. Not that it’s necessary at my workplace but it’s still a very comforting feeling and helps me not be afraid to say what I think needs saying.

If you don’t have an emergency fund, why not start now? If you can’t save big chunks, chip away at it. Small contributions will also help. Having some money in the bank will make you more effective in you job. And it’ll let you sleep better at night.

PS: Like what you're reading? Join the Finding Marbles newsletter to get new blog posts in your inbox!

Phases are not always linear in retrospectives

If you facilitate retrospectives then you’re probably familiar with the 5 phases from “Agile Retrospectives” by Derby and Larsen:

  1. Set the stage
  2. Gather data
  3. Generate insight
  4. Decide what to do
  5. Close the retrospective

Whenever I talk about them and in all the material I’ve created, it always looks like the phases are strictly linear. But that is not how they work in the majority of my retrospectives – because I rarely have single-topic retros. I usually run a “gathering potential topics”-activity like “Speedboat” or “I like, I wish” and then the team works through 2 or 3 of these topics.

It would be strange to first talk about 3 topics in depth and afterwards come up with action items for all of them. Instead we talk about 1 topic in depth and create an action item for this topic. And only then start with the next topic. Like in this highly elaborate diagram 😉 :

I thought it might be worth stating this explicitly as it’s not necessarily obvious for beginners.

What about you? When do you decide on action items?

PS: Interested in retrospectives? Sign up to the Retromat newsletter to get related news and tricks!

 

Expect turnover – Agile transitions and changes in the work force

The other day, I’ve had 3 visitors from a large corporation. Since one of them was from HR we talked a lot about these topics and exchanged our hiring processes. One hidden criterium of theirs is that people must be “leidensfähig” to a certain extent.

“Leidensfähig” is a beautiful German word that literally translates to “ able to suffer”. If you’re leidensfähig, you are able to put up with a certain amount of (corporate) bullshit without quitting. We cast for the exact opposite. If something sucks, it’s your responsibility to go fix it.

Expect turnover

It reminded me of how much hiring criteria differ between companies and that it’s really no wonder that turnover is to be expected during any big change. You’ve hired people to work in a certain way and – boom – now you ask them to work in a different way. Not all employees can and want to work in a new way. It’s not their fault either. It’s just people and companies going their separate ways. It’s not them, it’s not the company. They are just not a good match for each other anymore .

PS: Like what you're reading? Join the Finding Marbles newsletter to get new blog posts in your inbox!