True full stack in #fintech. Analysis, solutionizing, developing and delivering.
Mostly working in dotnet and javascript, with a passion for process optimising!
Good idea Rieko! Inclusion can always be hard as some simply don't want to take part. I think you are definitely on the right track with the anonymous messaging if people don't want to openly discuss something. In this scenario I would still make sure I played back their message to the group, to give the author (or group) chance to correct it (Things may get lost in translation!)
You are right on the results. If people can't see things changing why would they come out their shells to suggest change?! It's something we have always struggled with, as it's hard to get buy-in.
This is what we (try) to do: At the end of each retrospective, agree which items should be focussed on. Be practical about the volume of items. We then assign a task or action into the upcoming sprint, so that way it technically becomes a "deliverable" (Easier for tangible items like "We need to increase test coverage" vs "We need less time in meetings".)
For items in the latter category, I would make a point of any time somebody took an action which had a positive result towards the goal. (I.e. Your team get a blanket invite to a meeting, you push back and ask if it's really a requirement the whole team goes, as they feel they spend too much time in meetings currently). Hell, even if the change isn't positive, I would still make a point of demonstrating an attempt!!
As well as the above, we also (try to) make a point to review any retrospective items added into the sprint, attributing each item to the person that raised it for a sense of ownership.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Good idea Rieko! Inclusion can always be hard as some simply don't want to take part. I think you are definitely on the right track with the anonymous messaging if people don't want to openly discuss something. In this scenario I would still make sure I played back their message to the group, to give the author (or group) chance to correct it (Things may get lost in translation!)
You are right on the results. If people can't see things changing why would they come out their shells to suggest change?! It's something we have always struggled with, as it's hard to get buy-in.
This is what we (try) to do: At the end of each retrospective, agree which items should be focussed on. Be practical about the volume of items. We then assign a task or action into the upcoming sprint, so that way it technically becomes a "deliverable" (Easier for tangible items like "We need to increase test coverage" vs "We need less time in meetings".)
For items in the latter category, I would make a point of any time somebody took an action which had a positive result towards the goal. (I.e. Your team get a blanket invite to a meeting, you push back and ask if it's really a requirement the whole team goes, as they feel they spend too much time in meetings currently). Hell, even if the change isn't positive, I would still make a point of demonstrating an attempt!!
As well as the above, we also (try to) make a point to review any retrospective items added into the sprint, attributing each item to the person that raised it for a sense of ownership.