27

I'm working in a software development team. We're following an agile methodology. There are eight people in the team, with fairly diverse backgrounds: some just got their college degree, some already have grandkids; some are working from office, some are in a different country, etc. We're only about 6 months in the project, but already couple of months late, so I don't think we have much time to waste. Yet the scrum master insist on having retrospectives (i.e. long running meetings requiring the presence of all team members) every week and insist on "team building" games in these meetings.

What is the point of such games? How would it make the team more productive if I know the favourite beer of a colleague whom I most likely won't ever meet in person and I don't even drink alcohol? How do I tell this to the scrum master without sounding like an asocial jerk?

8
  • 27
    How long do these meetings last?
    – DaveG
    Aug 21, 2023 at 3:12
  • 11
    Are the sprints really 1 week long? Or is the scrum master just insisting on these meetings independent of the sprint length?
    – DaveG
    Aug 21, 2023 at 13:45
  • 28
    Start with the fact that you're not following the Agile process. Retrospectives happen after a sprint, not weekly.. Games have no part in the retrospective, and you can never deliver late in Agile, because that's against the principle.
    – PeteCon
    Aug 22, 2023 at 1:59
  • 5
    Is your team behind schedule, or did they overestimate their velocity? This is the kind of thing that should be discussed in a retrospective.
    – Seth R
    Aug 22, 2023 at 13:37
  • 3
    @EpicKip I assume PeteCon means that setting a delivery date for a given feature in advance and thinking of deviation from that as "late" is against the principle. It's arguably more agile to simply plan to release each thing when its ready.
    – bdsl
    Aug 23, 2023 at 11:56

11 Answers 11

108

Both insisting on having retrospectives and running retrospectives introducing some creativity in the process is literally the Scrum Masters job.

Unlike Daily Scrums, which are following a pattern and focus on repeating results, the retrospective is focussing on new ideas to improve your process, on thinking outside the box to solve problems.

In Scrum (I am assuming you are doing Scrum, otherwise why would you have a Scrum Master...) the restrospective is supposed to be "timeboxed to a maximum of three hours for a one-month Sprint", so if your sprints are only a week long, I would say an hour is perfectly fine. How long do yours take? Are they timeboxed? If not, that might be something to bring up in the retrospective. If they take longer than an hour, that too might be something to bring up.

How do I tell this to the scrum master without sounding like an asocial jerk?

You cannot. Let me put it this way... you say you are a couple of months behind whatever you had in mind as a timeline. In a project 6 months in. Assuming that "a couple" is at least two, that means you are 33% behind schedule. I don't think cancelling a weekly meeting is going to cut it. You are not in "we need this one hour so we can deploy this bugfix to production, just once" territory. You are in "we need to improve on how we work" territory. That is exactly what a retrospective is supposed to improve.

Whoever decided to use Scrum did that for a reason. Retrospectives are a big part of any agile Method. How else would you "Inspect" and "Adapt". So... you are 33% behind on schedule, maybe bring that up. And try to solve that problem.

11
  • 23
    Long running meetings with team building exercises sounds like a multi hour meeting every week. That could easily be using a significant fraction of the team's time.
    – DaveG
    Aug 21, 2023 at 3:11
  • 23
    How else would you "Inspect" and "Adapt" - sounds like they are using retros for everything but that. Aug 21, 2023 at 4:00
  • 28
    "Whoever decided to use Scrum did that for a reason" that reason most likely being "everyone else is using it"... Aug 21, 2023 at 11:15
  • 9
    You are in "we need to improve on how we work" territory. - and the improvement needed may be cutting an hour or two of meetings per week. I've personally experienced environments where the meetings, bureaucracy, and communication overhead were so overwhelming that I'd find at best two uninterrupted periods of a couple of hours to write code per week, and sometimes none. You imply that nuking one weekly meeting can't possibly mean a 33% improvement in productivity but I counter that it easily can mean that in an environment where devs are struggling to find any time to actually code.
    – Mark Amery
    Aug 21, 2023 at 12:57
  • 54
    @MarkAmery Given that none of that was mentioned in the question, I can only answer the question as asked. But again, if "too many meetings" are a problem, the time and place to discuss this is the retrospective.
    – nvoigt
    Aug 21, 2023 at 13:19
44

Without wanting to be too harsh, the reason you think this makes you sound like an asocial jerk is because it is the action of an asocial jerk. People aren't machines, and we do actually care if people ask about our hobbies/kids/favourite beer, because those little social niceities smooth the relationship between people.

Perhaps a more reasonable way to express this is that you think there's too much time being spent in your retrospectives; that's something you can bring up in the retrospective itself, as one of the primary outputs of a retrospective are suggestions for how to improve the team's process. Maybe your team agrees with you, maybe they actually like all this; the scrum master should then adapt the process to fit the self-organizing team.

However, I suspect your team is "Agile in name only": a scrum master shouldn't be "insisting" on anything in retrospectives, and you can't really be "a couple of months late" on an agile project. That could make it harder to change things if you're actually in an old-fashioned "command and control" type organisation.

8
  • 36
    "we do actually care if people ask about our hobbies/kids/favourite beer" — speak for yourself. I come to work to work. Aug 21, 2023 at 10:09
  • 48
    “People aren't machines.” Also, not all people are the same. Those staged social interactions with required active participation can be very uncomfortable for some.
    – Carsten S
    Aug 21, 2023 at 10:24
  • 11
    Appreciate the human aspect of this answer. At least where I currently work, supporting each other is a big part of why I like the company culture so much
    – Anthony
    Aug 21, 2023 at 11:07
  • 21
    @CarstenS Sure. But from the text in the question, the OP is trying to force their view that team building exercises are pointless on the whole team without having gathered any consensus. That's just as bad, if not worse. Aug 21, 2023 at 11:13
  • 43
    I've been on teams where we never talked about non-work subjects with our coworkers. We never built relationships, we never built up trust between each other, and we ended up not really caring that much about each other and teams turned tribal (why help that team when my team needs to do XYZ). They are the worst soul-sucking jobs where I feel like I'm alone and I've learned (especially in remote jobs) you NEED to have small talk time with your team (favorite beer, etc), SPECIFICALLY to build team rapport, so we all can find commonalities with each other and trust each other.
    – JJrodny
    Aug 21, 2023 at 12:52
12

How do I tell this to the scrum master without sounding like an asocial jerk?

Do a bit of team building yourself: chat outside the meeting to your cowokers, one to one, bring up the topic of whether anyone actually likes the team building and also feels it's a waste of time.

Once you've got sufficient people on your side you all come forward and say "we, the team, insist on not doing this".

6
  • 11
    To me that sounds more like a coup than a professional way of handling a situation.
    – Aubreal
    Aug 21, 2023 at 19:10
  • 2
    @Aubreal, it depends on the tone conveyed. "insist on not doing this" may be too strong, but if the team is really united and united against the manner of doing the retros, it might have sufficient weight
    – eques
    Aug 22, 2023 at 0:49
  • 2
    If the group has a concrete alternative to recommend that addressed the same needs, they will have a far easier time convincing others.
    – keshlam
    Aug 22, 2023 at 5:28
  • 2
    Agile is "supposed" to be led by the team, rather than a conventional command structure enforced by the Scrum Master. "Individuals and interactions over processes and tools". Of course, what inevitably happens is that humans treat it as a dogmatic system in which the Scrum Master imposes a rigid process without regard to what their subordinates want.
    – pjc50
    Aug 22, 2023 at 8:25
  • 12
    If there only were a meeting in Scrum where you could bring up improvements and discuss them amongst the team and get a consensus how to improve... oh... wait... :)
    – nvoigt
    Aug 22, 2023 at 13:58
9

My experience with retros:

Pros

  • Proactive feedback on processes that can be improved
  • Follow up action actually is being followed up as a planned action task.
  • Short 5 min ice-breaker that's also fine.

Cons:

  • Long complaints without any follow-up
  • "Team building" games

I would propose to have team building games as a separate optional activity. Like "get-together", "afterwork beers", "fika". Some people like to take part at this activities others not.

I didn't take part at any team building ceremonies while working in kitchen, electro industry, civil engineering or my first IT companies and we were working together just fine.

2
  • 3
    One of the things that I think is most useful with retros is the fact that everyone has an opportunity to speak about what worked and what did not work within the context of the sprint, and also the overall structure of the team. It really can be tough to have to take time out of your workday to have to go to a retro, but done properly, its an invaluable time to allow developers to give feedback that you otherwise might never get, regarding your process and procedures as a dev team.
    – element11
    Aug 22, 2023 at 4:35
  • 3
    Also have a retro every single week seems like overkill. Just how much is there to retrospect at the end of a week? It usually takes more than a few days to give something a chance and see whether it works or not.
    – DaveG
    Aug 22, 2023 at 20:27
8

TL;DR Your question reveals no reason for me to assume that team building exercises are the cause of the problem. It actually sounds more likely that this is an attempt at fixing the real problems.

I apologize for the long answer but I genuinely urge you to read it. While there are some educated guesses in this answer; there are several points that I think you need to hear in order to re-evaluate some of your opinions.

You're trying to do the right thing, but I'm not convinced you're trying to do it the right way.


Your goal

How do I tell this to the scrum master without sounding like an asocial jerk?

You can't, because the point you're making is inherently asocial. Note the difference between asocial and antisocial, the former is indifferent and the latter is adversarial.

There's no continuation to this part of your question - it's inherently impossible to not sound like the actual thing you're trying to accomplish (and no, lying is not something that is advisable anyway).


Your gripe

How would it make the team more productive if I know the favourite beer of a colleague whom I most likely won't ever meet in person and I don't even drink alcohol?

I want to dissect this quote, because it does a lot of heavy lifting in terms of revealing who you are at work and how you approach your workload. I want to be clear here: this is not a personal attack, I am making these points so I can then revisit them when we talk about the team's workload.

First of all, regardless of whether you think knowing innocuous facts about others is relevant or not; you then continuing about the pedantry of you "not even drinking alcohol" is a crystal clear indicator that you are getting distracted by the details of a particular fact rather than the bigger picture of discussing the value of these exercises at large.

If you have a bone to pick with the specific team building question about someone's favorite beer, that needs to be addressed in a very different context than one where you are picking a bone with your team's workload, delays and the overall existence of team building exercises.

Secondly, when working in a team, it is only natural for team members to at least know each other. This helps the overall flow of the team, otherwise there's no "team" to speak of. A team should not have any boundaries of (unreasonable) formality, conversation should flow freely to maximize the awareness and knowledge share between members.

Team building exercises are not exercises in extracting useful information from one another. No one is thinking that knowing Bob's favorite beer will directly help you achieve your deadline.

Team building exercises are attempts at breaking the ice between team members, in order to facilitate casual conversation, which is necessary when that casual conversation has been lacking in the team.

Sometimes these kinds of conversations happen naturally anyway (depends on the people's character and shared experiences) but sometimes people don't pick up conversations with strangers and are more able/willing to do so when there has been some prior conversation. The latter is exactly why team building exercises can be useful tools in order to build the team (hence the name).

There are eight people in the team, with fairly diverse backgrounds: some just got their college degree, some already have grandkids; some are working from office, some are in a different country, etc.

This sounds exactly like the kind of team setup that inhibits natural conversations, which leads me to believe this is why your scrum master insists on these team building exercises.


Your work issues

We're only about 6 months in the project, but already couple of months late, so I don't think we have much time to waste. Yet the scrum master insist on having retrospectives (i.e. long running meetings requiring the presence of all team members) every week and insist on "team building" games in these meetings.

The question as to why a project can run late is really broad. I cannot write an encompassing answer on that.

It is interesting to note that you point out the significant delays and are only picking at one particular thing that you dislike. So the first question that comes to mind is whether the team building exercises are actually related to the delays, and at least a major contributor to the problem?

Assuming that "a couple of months" is at least 2 months, over a 6 month span, you would have to be doing team building exercises for about 13 hours (1.6 work days) per week in order to have pushed your deadline by that much. I'm going to go ahead and assume that this is not the case.

For now, let's put the team building exercises aside. We'll come back to them.

The two predominant reasons for retrospectives running longer than you're comfortable with are either that people talk about problems without solving them, or that there's just so much going wrong that it takes a significant amount of time to even be able to address it. Given the kinds of delays you're dealing with, I'm leaning towards the latter here.

Even if everyone is individually working at a common goal, that doesn't mean they're doing it efficiently. There's a reason you're asked to form a team, not to be eight individual developers on their own track.
Assuming a team that has individually competent developers but effectively no good line of communication, the delays you're dealing with sound like they're in the right ballpark.

I'll admit that this is an educated guess, but I can even combine the two mentioned issues: the retrospective is probably chock full of the kinds of issues that make it clear that these problems would've been either mitigated or negated entirely if the team had been more acutely aware of the other members' activities and opinions.

So your scrum master is making you do team building exercises. You think this is a problem. However, your question reveals no reason for me to assume that team building exercises are the cause of the problem. It actually sounds more likely that this is an attempt at a fix.


My critique

This next part is going to come across as more adversarial towards you, but I genuinely intend it to counter some of your implied assertions in an attempt to get you to reevaluate your stance on things.

I can easily argue that by resisting to engage in the team building exercises and instead touting a more "face to the grindstone" attitude about what you should be spending your work time on; that you are probably a significant contributor to the team spirit issues that lie at the basis of the delays.

Don't get me wrong, it's clear that you like to work hard. Someone with a lazy work ethic would embrace these "time wasting" exercises with open arms. I don't think anyone here is question the effort you put in.

However, I'm going to openly question the efficiency of your effort. The adage is work smart, not hard for a reason. You're pushing a boulder up the hill and instead of taking a step back and trying to come up with a better solution, your proposal seems to be to stop trying to find solutions and instead just push harder.

This attitude works in the short term, but it will horribly fail in the long term. This is not a sustainable work ethic. If you persist with it, you run the risk of running the project entirely off the cliff, burning yourself out, and creating an inhospitable (if not toxic) work environment.

Sometimes, the better solution is to host a party, get people to come drink your drinks and dance to your music, talk to them; and they'll help you push the boulder the next day.
You're arguing that you could've been working instead of planning a party, and that is correct today. But how you spend your day is not what matters. What matters is how quickly you can get the boulder to the top of the hill.

If the party planning approach leads to you achieving this faster than just by pushing harder, then pushing harder is not the right decision to make. No one is giving you a star for your effort. You will be rewarded based on your achievements. High effort is not the best way to get there.

I genuinely believe that you intend well, but you are pushing yourself to blindly put in more effort instead of strategizing and coming up with smarter ways of tackling the problem in front of you.

And for a developer, that is definitely the wrong attitude.

I hope you will take this answer as it is intended: as a kind wake up call to revisit your metrics for success; because I've mentored several developers who were in the same boat. I was once in that same boat as well. Hand on heart, I do not intend to persecute you for causing the problem. I am hoping to convince you that you can help yourself and everyone around you by revisiting your stance on the importance of connecting with your team.

6
  • +1. Editing for brevity could attract more eyes, and still maintain your polite tone.
    – Tim Grant
    Aug 23, 2023 at 12:28
  • 1
    @TimGrant: I'm definitely not unaware of my verbosity (it's not the first time) but I do consider that being terse here leaves more gaps for interpretation and that's precisely what I wish to avoid (for OP's sake). I'll revisit and see what I can do.
    – Flater
    Aug 23, 2023 at 22:13
  • I'm finding quite a leap in your "work issues" section where you assume that lengthy retrospectives that include team building exercises are a necessary attempt to fix massive problems in the development process. Remember, these are being held each and every week, and presumably are running several hours long. Unless a lot of new problems are happening each and every week, the retrospectives simply aren't effective. Given my experience sitting in lengthy meetings I'd say the odds strongly favor the OP.
    – DaveG
    Aug 24, 2023 at 14:06
  • @DaveG Sorry to return the favor but I find it quite a leap to assume that the retros are running artificially longer than they need to be w.r.t. the retro content. If there's nothing to bring up, the retro ends in mere minutes. I also didn't say that for a fact that the team building exercise is necessary, but it's in my experience often the employees that universally question the purpose of team building exercises that create the necessity to hold these exercises. OP specifically reveals that they think team building exercises have no purpose in general, hence my assumption.
    – Flater
    Aug 24, 2023 at 22:46
  • 2
    @HappyIdiot As long as you don't face any apprehension with approaching and keeping in touch with your peers for work-related topics, the personal topics don't matter. But people who tend to not engage casually tend not to have the best professional lines of communication either. That's not an absolute by any means, but it's a good enough justifiable reason for leadership wanting to engage in team building exercises.
    – Flater
    Aug 26, 2023 at 8:42
5

Retros are good, but it sounds like your scrum master isn't doing them correctly

One of the core tennets of Agile methodology is that the team gets to edit the process as they go.

Retros are a core aspect of that: The team is supposed to reflect on what is working and what isn't. It's supposed to be a sort of 'safe space' to bring up concerns. Scrummasters will sometimes use retro games to start discussions, but the discussions should be work-focused.

If each retro each week is dominated by team-building exercises that go over information not directly relating to the project at hand, then the retros are not being used effectively.

You can reduce the 'asocial jerk' effect by expressing appreciation of the team-building efforts so far, and how much you appreciate everybody on the team. The team building has been a success! But the looming deadline makes you nervous and you'd rather brainstorm ways to improve the pace or reduce scope, and you'd love it if the retros went back to a traditional format of 'what works/what doesn't work/shout-outs/next steps'

Perhaps you could suggest doing one last 'for fun' team discussion at a virtual happy hour at the end of the project.

2
  • This answer is not wrong as to the definition of a retro; but the retro and team building exercises are likely back to back meetings because the whole team is present, instead of having to find two separate time slots to get 9 people in a room together. OP's argument isn't that the retro is being drowned out by the team building exercise. They're arguing it's drowning out the development time. OP seems to be against the retro too, quote from OP: "I don't think we have much time to waste. Yet the scrum master insists on having retrospectives [..] and insists on team building exercises."
    – Flater
    Aug 23, 2023 at 22:23
  • 1
    per OP: 'Yet the scrum master insists on having retrospectives . . . every week and insists on "team building" games in these meetings.' Team building games tend to take a long time to be effective, and the more distracted people are, the longer it takes to make the team building game feel useful. My gut feeling is that the retro is being drowned by the team building game, if not in actual clock time, then at least in how long it feels to OP, who is undoubtedly itching to focus on engineering and product building.
    – LeLetter
    Aug 24, 2023 at 13:48
4

Scrum is an implementation of the agile philosophy, and one of the foundational tenets of agile is people over processes.

In other words, if these "team-building games" aren't working for your team as a whole, the team gets to tell the scrum master that they aren't interested in playing, and the scrum master needs to accept this. If they refuse, they're ignoring this tenet and being doctrinal, and that would mean they're not doing their job.

Note, however, my qualification regarding the games and the team. If you're the only one who has problems with the games, it likely indicates you're not a good fit for your current team.

Finally, it's not your judgement call to make about time being "wasted" or the project missing deadlines - it's your manager's. That doesn't mean you shouldn't have these concerns, but it does mean you should be discussing them with your manager. Especially, you shouldn't be using them as an excuse to undermine or push back against parts of the scrum process that you don't necessarily agree with; you are, after all, on a team.

0
4

What is the point of such games? How would it make the team more productive if I know the favourite beer of a colleague whom I most likely won't ever meet in person and I don't even drink alcohol?

I have been a team leader for years and was uncertain as to exactly why these games are included.

I have worked with a solution owner who removed these games and used a default format for the retro for the purpose of brevity.

An efficient retro is a good retro right?

Wrong. They became perfunctory and felt even less necessary.

I took responsibility for the retros and reinstated them and themed each retro based on current events (world cup games, favourite album, Queen's jubilee) and noticed a lot more engagement and some useful ideas the we experimented with and improved our velocity.

I realised just how much we were suffering from the same approaches yielding the same results.

The point of these games is not to get to know teammates better.

The point of these games to separate you from the problems you have been facing every day, improve the quality of your reflection on problems and increase the potential for novelty of any ideas to try to improve.

These games, when run well:

  • separate your mindset from your regular working day
  • get you thinking in a novel state. By the games being irrelevant this allows you distance and objectivity to approach the problems you have been facing every day from a new outlook
  • provides psychological safety to help you feel confident to suggest creative ideas that may seem "silly" but have a positive impact
  • allow you work together and "yes-and" suggestions, you might have a "silly" suggestion that won't work, but it might inspire a colleague to have an approach that will work.

It will make the team more productive by improving communication and the breadth and quality of reflection and suggestions that arise.

1
  • 1
    @happyIdiot me too. They're not always necessary and different teams have different strengths and areas for improvement. A good team will use warm ups applicable to them, well. A poorly performing team will do them because good teams do them. It is better to understand why and how to apply them rather than eliminate them.
    – StuperUser
    Sep 1, 2023 at 13:37
3

Many of the existing answers seem to explain what the point of retros is, and about time management and such. Let me tackle the concrete, verbatim questions here:

What is the point of such games?

Some points of social games in retros or any other kind of meeting can be:

  • To give people a chance to move from the usual problem-solving, maybe crunchy state of mind, to a state where everything is more about social aspects - which is what a team is, after all.
  • To generally loosen up the athmosphere; maybe introduce some kind of humor, relax people (especially if everybody is already tense due to time pressure).
  • To build trust: there is a saying that you cannot hate somebody whom you really know, and it is generally easy to dislike or distrust someone you do not know at all. Knowing personal details about people often makes it such that it is easier to be trustful.
  • To generally get everybody to be more open about anything - also about non-personal issues in other kinds of meetings; especially in the second, "main" part of the retro.
  • (Maybe trivial, but...) some of your colleagues might actually like this kind of activity.

How would it make the team more productive if I know the favourite beer of a colleague whom I most likely won't ever meet in person and I don't even drink alcohol?

The better you know someone, especially if you never meet them in real life, the easier it is (for a general "you"; maybe not you, OP, personally) to trust them, to open yourself up to them, and so on and forth. For example, for a junior team member who maybe has issue being open about having some kind of coding problem, it might be easier to talk about that and ask for help if they know the other team members on a more personal level. This can be incredibly good for morale and productivity, in extreme cases.

Also, in the main part of the retro, where the team would discuss possible reasons why it seems to be unproductive, it helps if the atmosphere is open, loose, and trustful. If you hardly know anybody, it is hard for many to be open with these topics.

How do I tell this to the scrum master without sounding like an asocial jerk?

You are in an agile, self-organizing team. The Scrum Master is mainly there to facilitate the process, but the team itself has far-reaching capabilities to define the finer details of said process. In other words: discuss it in the retro! Ask your team members - including the Scrum Master - if they are all fine with the time spent. Ask them what you asked us (i.e., if it is important for them to have these kinds of games), and so on and forth. If it turns out that nobody likes them, then the Scrum Master can, there and then, explain why they thought it's a good idea. If nobody is convinced, then the team can decide to drop them or not.

If you for some reason absolutely cannot do that, and actually positively want to talk to the Scrum Master alone, then simply do it in the "I" format: "Hey Scrum Master, just wanted to let you know that I have trouble understanding why we do the social games in the retro. Can you explain your reasoning to me? Do you think it would be helpful to cut them, so we have more time to do X instead?"

So finally:

How to cut team building from retrospective meetings?

By involving the team, and coming to a consensus; and accepting the outcome (if the rest of the team likes them, then just go along).

Your actual issue seems to be that you are behind schedule. That is a wildly different question, there may be many reasons for it (which there are none mentioned in your question). 15-30 minutes of social games is very little in a 40 hour work week (or whatever you have); if those minutes make or break a sprint, the problem is not the 15-30 minutes, but the many hours wasted in other ways (or simply too little capacity for a too high workload). If you wish tips on that, feel free to make a follow-up question. But as a little outlook, discussing how many meetings there are in a given week or sprint is also perfectly fine to discuss in a retro -> if that is your issue, do it there.

2

I don't think you should try to get them cut from the meetings. Instead, try to move the focus from people's personal lives to their work. You can say you're not comfortable mixing work and your personal life. You're almost certainly not alone.

It's entirely possible that the scrum master is grasping at straws trying to make people feel like a coherent team, and would welcome alternative ideas.

I strongly believe that the only paths to a positive outcome involve you being direct (yet still diplomatic) with the scrum master. Trying to bite your tongue will probably fail spectacularly down the road. Forming a posse to force change will likely go really bad, even if you get the change you want.

I think the fact that it's an Agile methodology is of only marginal importance in this situation. The bigger issue is whether the team building activities have value that justifies the time spent on them.

When COVID lockdowns started, the place I worked started daily 1hr conference calls with about 30 people. Even worse, the majority of the time was the manager talking to the half dozen people he knew best. It was horrible.

The fact that at least one employee is bothered by the team building exercises is a single data point indicating the activity has a negative impact. It appears that the Scrum Master is unaware of your annoyance, which is another point against. Feedback should be actively sought from attendees and used to improve the approach. Drinking is also a dangerous topic. There are many reasons why people might be uncomfortable with that subject.

I'm a very friendly person, but I don't go to work to make friends. It's not an absolute rule, but I prefer not to make friends at work. Experience (personal and observed) has taught me that it often leads to complications.

However, I'm a strong proponent of team building. The trick is to keep it focused on the job, not on people's personal lives. My favourite approach is to set up times where one employee narrates some aspect of their job, while another watches and asks questions.

Many people are uncomfortable sharing personal information, but most are fine with showing a colleague what they do. It acts as informal cross-training, builds interpersonal connections, and frequently results in significant process improvements.

I personally feel that one-on-one interaction is far more effective and it doesn't keep an entire team from doing their work.

-5

Your job is not what you think it should be. It is whatever the company you work for is willing to pay you to do.

In this case it's to develop code, participate in meetings and play these "team building" games. It is not to figure out how to increase team productivity, so why are you wasting your brain cycles worrying about that?

What is the point of such games?

What is the point of the software module you're working on? What is the point of the product your company is developing and is that really the best use of your time? If you get stuck in the "what's the point" thinking you're never going to get anything done.

Now if you insist that you know better about team productivity than the people your company is paying for that, the best way to do something about it is:

  • Develop social skills by participating in "team building" games
  • Use those social skills to become a manager
  • Advance to the position of a director
  • Drive change downward by demanding no more "team building" games
4
  • 5
    Taking the attitude of "I'm just a grunt, I do whatever my manager tells me to do" is a pretty narrow view of the world. I always felt part of my job as an employee was to point out when the company was screwing up. Understanding that management might not agree with me, but at least I could have a clear conscience that I had done my best to alert them.
    – DaveG
    Aug 21, 2023 at 22:14
  • 2
    -1 The OP's job includes being in a meeting. A Scrum retrospective meeting. Which means "how they can improve the process during the next sprint" (productplan.com). Figuring out how to increase productivity is the job. Aug 21, 2023 at 22:51
  • 1
    @DanielR.Collins You just repeated everything I said, except the last sentence. The OP's job is not figuring out how to increase team productivity. His job is to increase his own productivity, and to use the retrospective meeting to communicate what would help him do that. If his best answer is "well if I could just not do these meetings..." he's got a problem!
    – nr44
    Aug 22, 2023 at 0:44
  • 1
    @DaveG If you want to drive change, remaining in an engineering position is not the best way to do that.
    – nr44
    Aug 22, 2023 at 0:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .