14
Is it fair to say that your process has stabilized in a good place? It sounds like your team is happy with the current way of doing things.
Rather than a reactive retrospective, you could try running experiments. The ol "what if we stop doing x" or "do more of y".
Whenever I read about kanban, the author eventually talks about gathering metrics so the team can run experiments and see what happens to the metrics.
Is it fair to say that your process has stabilized in a good place? It sounds like your team is happy with the current way of doing things.
I think that's largely true. Not trying to assume intention, but I do think a few more of the junior folks on the team read something in a book or blog and think we have to do it that way. Or that it'll work for us because it worked for Etsy/Netflix/ThoughtWorks/etc.
Whenever I read about kanban, the author eventually talks about gathering metrics so the team can run experiments and see what happens to the metrics.
You know, metrics might be a great way to discuss some of these concerns/ideas are coming up. For example, the topic on Jira was related to Cycle Time. If we were concerned about Cycle Time, changing how we use Jira for a few weeks would see what happened to the metrics.
Hm. Interesting. This is something that gets me too...
Taking a step back: what are you hoping to achieve with the retrospective?
I find that the items people are bringing up aren't really important or could just be a question in Slack.
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"
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.
This is a perfect topic for retrospectives.
How do the others see your retrospectives? Are the retrospectives productive? Do you identify and resolve issues? Do you have issues you do not identify and resolve in this format? Is the form stale? What needs to change?
Talk about the goals and focus of your retrospectives. Is it a place for "open ended" questions and discussion? Or should it be more focused on factual or felt issues and irritations? (Doesn't mean it can't be gaining others views on personal irritations.)
In my team we have bi-weekly sprint meetings and retrospectives. Our agile master (basically scrum master) prepares a themed board. Themes may liven and lighten up the process. - Personally, I don't like them much, and feel like the prepared structured format often doesn't offer or allow me to raise questions and issues that came up - but I'm not letting that stop me from raising them.
Every week feels quite often to me. Consider whether and how spreading them may change them - possibly for the better.
Consider making "nothing to discuss" a fine occurrence.
Consider whether other formats separate from retrospectives could focus retrospectives into something more specific.
this post was submitted on 06 Feb 2024
14 points (100.0% liked)
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