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.
Hm. Interesting. This is something that gets me too…
Taking a step back: what are you hoping to achieve with the retrospective?
What criteria would make something important? Conversely: what makes something minor?
Once we nail these it might be easier to focus the discussion.
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”
Haha don’t worry it’s for framing my thoughts too! ;)
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.
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:
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.