Ask Experienced Devs

1232 readers

1 users here now

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago

MODERATORS

Ategon@programming.dev

How to liven up retrospectives when they've gotten uneventful / unhelpful? (programming.dev)

submitted 9 months ago by flumph@programming.dev to c/ask_experienced_devs@programming.dev

7 comments fedilink hide all child comments

My current team runs weekly retrospectives using the Lean Coffee format. More and more, I find that the items people are bringing up aren't really important or could just be a question in Slack.

For example, someone recently made a topic for how we can test credit card payments. Another topic was navel gazing about how we use Jira and multiple team members asked "what's the problem you're hoping to solve?" to which the only answer was "That's not what I've seen elsewhere".

I'm beginning to think that there's something wrong with our format or prompts, in that we aren't identifying important issues for discussion. Perhaps the format is stale or there's no serious issues lingering each week?

Any advice on alternative formats, how to get better feedback, etc. would be greatly appreciated.

you are viewing a single comment's thread
view the rest of the comments

[–] flumph@programming.dev 4 points 9 months ago (1 children)

Thanks for helping me reframe my thoughts. I definitely don't want to call anyone's concerns unimportant.

More specifically, I view retros as a time to talk about improving the team, either through experimentation or doubling down on good practices. To that end, I'd want topics to be problems or shout outs.

Something like "how do we test credit cards" might be a sign of "our documentation isn't great and it slows me down" but it's talked about as a discreet item. Similarly "I haven't seen Jira used this way before" isn't a problem; maybe the underlying issue is "I don't understand how we use Jira" or "what we're doing causes a lot of paperwork"

[–] otl@lemmy.sdf.org 2 points 9 months ago* (last edited 9 months ago)

Thanks for helping me reframe my thoughts.

Haha don't worry it's for framing my thoughts too! ;)

To that end, I'd want topics to be problems or shout outs. Something like "how do we test credit cards" might be a sign of "our documentation isn't great and it slows me down" but it's talked about as a discreet item.

Devil's advocate: what are those good practices? What constitutes improvement? One way to focus discussion is to try and pick some specific team values/objectives. Let's go with the example about Jira.

Similarly "I haven't seen Jira used this way before" isn't a problem; maybe the underlying issue is "I don't understand how we use Jira" or "what we're doing causes a lot of paperwork"

The statement "I haven't seen Jira used this way before" is not ideal starting point for discussion - agreed! But with a value in mind I think we can work with it. Let's say, for argument's sake, the goal is stronger shared understanding of project management.

You mentioned other team members asked "what's the problem you're hoping to solve?". I think that's a very pragmatic, specific question (I'm a software engineer, too, I get it!) but it's not really in the service of the goal of the discussion: a stronger understanding of project management.

So how can discussion help with that? What about a Q&A session? The interactive, conversational exchange is a natural way for people to learn (I hear ChatGPT is pretty popular!), and it's likely others will learn a bunch of stuff too about why things are done the way they are.

Another technique is to use the free-flowing discussion format for what its best at: exploration of ideas, not necessarily solving problems. Solving problems usually takes code, data, testing, experimentation... things that require time at the keyboard.

Taking the credit card example:

Something like "how do we test credit cards" might be a sign of "our documentation isn't great and it slows me down" but it's talked about as a discreet item.

Use the conversational format to its advantage. Respond to the question with another question: "why do you ask how we test credit cards?" From there they might reply with something about documentation, or maybe the tests aren't clear, or they're not run often enough. Maybe they want ways to run credit card tests on their own workstation as unit tests? From there we identify a whole bunch of ways to improve the code/project/workflow/better align with best practices.

Anyway, I'm not a manager :) I'm just thinking out loud so next time I start speaking to a team to join maybe I understand the dynamics a bit more.