Episode 288 - Team Work – Do we still need to talk about it? with Aino Vonge Corry and Lisa Maria Schäfer | Transcript

Like, okay, I need a better grade next year, I need to be able to run faster, I need to be able to blah, blah, blah.

There wasn’t much training in the reflection of what is actually, what’s the cause for me not running faster, what’s the cause for me not getting a good grade in this.

And that meant that I myself and other people would sometimes really push themselves against their nature or against their situation to achieve what other people are achieving, because they weren’t reflecting on how they could achieve and how much they could achieve.

So I think that it’s a big battle to take to try to convince people to reflect on their own if they really are not trained in it.

But I think that one way of doing it would be to introduce it in a retrospective, because as I said before, for some people that’s a safe setting to reflect.

And then instead maybe of taking this as a team retrospective where we’re reflecting on the teamwork, maybe we could start gathering data in silence on our own, reflecting on our own last week or yesterday, or reflecting on conflicts or reflecting on, I don’t know, how to write a peer review or something like that.

How do I react when people do that?

How do I react in this situation?

How do people react when I say that?

So I would suggest to try it out in a very small setting where they reflect only over a day or a week about themselves and then really help them to trust that they do not have to share all their reflections with everybody else, but they can if they want to.

And then there will always be somebody who shares their reflections because they like to talk about themselves and they’ve got some really good reflections.

So there will always be somebody who would want to share.

And then the others can hear, oh, he or she, they said that.

And oh, no, that’s actually not too far away from where I am.

So maybe we’re struggling with the same problems.

And then when they notice that self-reflection is not that dangerous and that other people are doing it and other people can get something out of it and also that other people are maybe learning the same thing about themselves that I’m learning when I’m reflecting, it becomes less dangerous.

And so, again, it’s about removing the fear.

I think that a lot of reasons for people not doing sort of the best for themselves is because they are worried about what other people’s reaction will be.

They’re worried about if they’ll lose some benefits or if they’ll lose some trust or power or something like that.

I had to laugh because when I was little, I think the most hurt sentence by my mother was every time I had something, my mother said, but what will the neighbors say?

Yes.

So you’re taught to be conscious about what will other people think and say and do and so on.

And then you stop doing everything because what will I know say if I will ask her this question?

Yes.

It’s not that great to live in such a way, but I think it changes right now, but it has been in this way for such a long time.

So it needs some time to be changed.

Definitely.

And I think there’s a gender thing here as well, that at least me growing up as a girl and as a young woman, I very much wanted to fit into the social hierarchy of the female group.

And that made me very self-conscious about whether I would create conflict or whether I would sound negative or something like that.

So it’s been a struggle for me to learn to find these things and feel safe to talk about these things.

Yeah, I feel you.

So you talked about retrospective and now I have another question because I don’t know if the gender thing is going in this as well.

But I have not the opinion, so I made the Erfahrung.

So Erfahrung is not there.

Experience.

Experience.

Thank you so much.

It’s so good to have you here.

You speak German, so it’s much more easier for me.

At least I understand it.

So I made the experience that in a team, there’s always someone who hates retrospectives and thinks that they are not worth it.

So you also said when the action items are not addressed and when there’s no real plan afterwards, this makes people feel like it wasn’t worth it.

And even if these points are addressed and are working well, I remember, I think in every single team I’ve been in and I’ve talked to so many people, there are some people who hate retrospectives and think that they are a waste of time.

Yeah, I wanted to say shit, but it’s a live stream, so I didn’t want to.

So you didn’t say it.

I didn’t say it.

Is there something that we as people who think that retrospectives are worth it can do for them to open their eyes?

Or do you think it’s something they have to experience for themselves?

Or do you think there are people who never will ever love retrospectives?

I’m quite certain that there will be some people who will never love retrospectives.

That being said, there are some things that can be done.

I think that when you have somebody who hates retrospectives, and I agree that there is definitely a pattern there, it can be interesting to figure out why they dislike it so much.

Because it could be because they’ve had a bad experience with a retrospective before where they felt like they were under attack or they felt like they had to admit to being stupid or something like that.

So it can be that they’ve had a really bad experience before.

It could also be that they really think that the work that we do as software developers is just typing the code in, and every communication, everything else, it’s administration that the project managers should make.

And I’ve also heard people say, I don’t really care how my colleagues feel about things.

I don’t really care about who they are as people.

I’m just interested in actually getting my work done.

And I can understand that.

There can be several psychological reasons for feeling that as well.

But I think that if you are working in a setting where you are working in a team, it is probably because there is a reason for that.

We can come back to that later about the focus on teams, which is maybe not always healthy.

But if we assume that they work in a team and they are a team, then one of the things about having a team is like it’s a shared goal, and you should work together so that the sum of you becomes bigger than the individual people.

A bit like an octopus, right?

An octopus has eight tentacles, and each tentacle has a part of the brain and can actually think individually.

So together as an octopus, they are even better than if they were just eight arms flumming around on their own.

They can do much more together.

And it’s the same with a team.

So if they are in a situation where they are working in a team for a reason, somebody should talk to them one-on-one and figure out what is actually the problem.

Like are you worried about what will come out?

Is it because you don’t remember what happened?

Is it because you don’t know how to reflect?

Because we can teach you that.

And one of the things I often use with people like that is a pattern from Linda Rising’s first book, Fearless Change, with Marilyn Mans.

And one of the patterns in the Fearless Change, the first book, is this about the champion skeptic.

Because sometimes people have taken on the role as being a skeptic.

Their skepticism has created their career.

They are skeptic.

They are the one which the bullshit threshold is very low, right?

So they can see through things, and that has helped them so much in their career.

And it has given them the street cred that they have that they are skeptic, for better and for worse.

It can also be so bad that the reason why they have the street cred is because people are afraid of them.

But let’s imagine that they have the street cred because they’re really good at being skeptical, and that skepticism has helped them and the team and the organization for years.

That is a role that they do not want to lose, and sometimes that skepticism can be put on the retrospectives.

And in those cases, what you can do is that you can have a one-on-one with them and tell them, Well, I appreciate your skepticism, and I need your help.

Because since we are a team, we need to continuously improve the way we work together.

Because if we don’t add energy to a system, entropy will arrive, and we will be worse.

We have to add some energy into this system.

One of the ways of adding energy into the system is to continue to reflect and to learn how we can improve this.

So we have to do this one way or the other.

And the way that we’ve decided to do this now is with retrospectives.

And I’m the one facilitating them.

So I need your help.

I’ve made a plan for the next retrospective.

Can we go through that, and you help me figure out how can we improve this plan so that it’s not so much a waste of time?

But you have to set the limits.

So you have to say, I would like your help to improve it, but we cannot make it shorter than an hour and a quarter.

We cannot just cancel it.

We need to have it every two weeks.

Inside those boundaries, how can we make this more beneficial?

And then maybe they say, well, we should only talk about how to improve our code.

And that could be something that, well, we say, the next retrospective when we gather data, we ask people to bring some code, and we can look at maybe, I don’t know, legacy or hotspots or something like that.

And that’s what we do, and then we work.

And that’s a coding retrospective.

And that’s something that they can see a value in.

And you might think then as a facilitator, how are we going to talk about teamwork and communication?

But actually, the code quality is also part of things you can improve in a retrospective.

Plus, when within half the retrospective where we are only looking at the code and refactoring and stuff, we will be talking about communication.

We will be talking about, oh, but I didn’t know we had time to change that.

Yeah, but we do.

We just have to ask for it, or we just have to do it, pretend you’re doing something else, whatever.

Oh, I didn’t know that we could actually do it like that.

Oh, I didn’t know that part of the software was finished.

Oh, I didn’t know that part was not finished.

Oh, I didn’t know that was tested together.

And then even though we’re sort of starting with something very code-centric and very technical and very not bullshit or just going to the important part of software development, which is the code, we will have a lot of interesting discussions about why the code looks as it does.

Does that make sense?

It totally makes sense and is a good advice.

And we have a comment in the comments.

So, obviously, I’m so sorry.

Sometimes the words are missing, and then it’s only… You’re doing well.

Okay, thank you.

So, Werner T. is writing, I think it depends on the personality of a person.

For InfoWord people like me, all the ceremonies are really exhausting.

I ever had to do in my 25-year-long experience of developing.

Yeah, for really introverted people, being in all these scrum ceremonies can be exhausting.

Definitely.

And I think that if it really is so exhausting for you to be in the scrum ceremonies, you should talk to the scrum master or your manager or somebody like that and say it really is taking a toll on me that is impairing my work.

So, could we say that I’m just part of this or this or this?

I think, for instance, that a retrospective should not be something that you have to go through.

It should be something that you want to go to.

Because if you have some people that you’re forcing to have in retrospectives, they’ll just be sitting there with crossed arms and finding faults in what’s happening, right?

We want people in the retrospective who really are interested in improving and learning.

And then if those people never come to the retrospectives, maybe talk to them about, instead of saying, why don’t you come to the retrospectives, talk to them about, do you think we have any problems in the way that we’re working?

Do you think we have any problems in the way that we’re reviewing or testing or integrating or creating the right code for the architecture or whatever?

There will always be something that they think could be better.

And then you could suggest, should we not have sort of just with the people who are interested in this, have a conversation about this?

And then you can run that conversation like a retrospective but call it something else.

But going through the five phases, setting the scene, what we’re talking about, why we’re talking about it, making sure everybody is there, not muted, on video if it’s online, making sure everybody has said something, gathering data, what do we know about this if we’re just looking at the data?

Then we start making meaning of the data.

Then we decide what to do if there’s something we can do.

Can we learn something maybe or can we have some action points?

And then we finish it by saying, okay, so what we went through with this, we went to this discussion.

These are the things that we learned or these are the action points we had.

So instead of forcing people to go to retrospectives that they hate, try to figure out what they need and then use the retrospective as a structure to communicate about it and to learn something about it because the point of retrospectives is to share, appreciate and learn.

Those are the three things that are important.

And if you are ever in doubt about what to talk about or what to do next in a retrospective, think about these three things.

How can I improve the sharing, the appreciation or the learning?

And that will give you the answer.

I think this is a good answer.

And Werner, if you have any further comment on this, then don’t hesitate to write it down.

I have something else to say about that, if that’s okay.

Yeah, please.

Because one of the things that I really wanted to talk about was this focus on teams.

Everybody has to be in a team.

The team is wonderful.

We have to build the team.

We have to have psychological safety in the team.

Not everybody works best in a team.

And I think it’s a bit sad that we have this extreme focus on having everybody in a team.

I think we should appreciate the diversity of people.

And some people work best alone, but they will probably need some sort of communication with some people so they could be part of some of the team’s communication, but maybe not all of it.

Also, I think that sometimes people are in a team just by name.

So they’re like the – sometimes people call themselves with a garbage bin team.

We are the people who does not fit in any other team, so that’s why we’re together.

But we’re actually working on seven different things.

So when we have the scrum ceremonies, I’m not interested in hearing what’s going on with this and that.

It’s got nothing to do with me.

It’s got no impact on what I do.

And I think in those cases it’s sad to force people to be in those meetings for so many hours.

So the scrum ceremony should be something that people gain something from.

It should be something that if they don’t have it, they feel like they’re losing something.

So, for instance, I don’t know how many retrospectives I’ve had where people are saying that one of the worst things is all the meetings.

All the meetings.

We have all the time we spend in meetings.

And in those cases I think it’s a good idea to look at how much time do you actually spend in the meetings.

And is it the time spent in meetings that’s a problem or is it the quality of the meetings that’s a problem?

Because you can have daily meetings for 15 minutes that kill you every day.

Like you just feel like the soul is getting dragged out of you.

Or you can have 15-minute check-ins every day where people have a chance to talk about what’s important for them or if they need any help.

And then some people will say, well, I just ask for it if I need help.

Yeah, sure, you do.

You do that.

But a lot of people find it difficult.

Again, as I said, some people find it difficult to reflect and to complain outside the structure for doing it.

So I like working in a team and I like the concept of a team.

But I think we are too much in love with that team thing in our software development organizations.

For example, it’s a team, but everyone works on his own.

There was a comment from AFRL.

Also, not every group shall be called a team automatically.

Absolutely.

And I think that we have a tendency to call everything a team.

And when we call somebody who’s just a group, maybe working on the same skill or something like that, we call them a team.

Then we have a lot of expectations.

And I think that’s one of the big problems with teams is the expectations.

There are some people who are talking about, oh, it’s wonderful.

I love my team.

We have each other’s back.

And that’s wonderful for you if that’s what you have.

But a lot of people have less than that in their teams.

And then they feel like they’re doing something wrong or there’s something wrong with the way that they communicate.

Maybe it’s just not a team, really.

So AFRL has added another comment.

He writes, team may be the highest form of social alignment working in a cohesive group.

That is a certain level of social quality, which I would consider mandatory for groups deserving the term team.

Exactly.

Yes, exactly.

I agree that a team doesn’t become a team just because you call it a team.

They need a shared goal.

They need to be interested in what the other people in the team are doing.

And they need to be able to help each other.

Like one of the things that really creates happiness about each other in the team is to help each other.

You know that, is it called the Ben Franklin concept or something like that?

Which is that we know that if you get help from somebody, it’s very nice that they help you and you get happy about that.

But what is even more powerful is if you help somebody else.

Because if you help somebody else, then your brain is thinking, I must like this person.

Otherwise, it would be stupid to spend my time and energy helping this person.

So your brain is thinking, I must like this person.

And then you start liking this person.

It’s actually as simple as that.

So if you help somebody else, you start liking them more.

But if you cannot help them, it’s difficult to get this liking in.

And when I talk about liking, I’m not saying that everybody should be friends.

And I don’t think that people necessarily should be friends when they’re working in a team.

I don’t think that’s a prerequisite for calling it a team.

But I think that having this impact on each other and this possibility of helping each other is a big part of what creates this feeling of a team where we have a we and them.

And the we and them, of course, there can be problems with that as well because that can create like the borders between the teams.

But as a team who needs to work together and maybe crunch some extra work at some point or take a negative feedback from somebody else together as a team, it helps to have this feeling of us and them in a sense.