In Agile Scrum Retrospective boards, what is the best practice?
Should Teammembers put their Name by each comment? I heard it was supposed to be more Anonymous based when documenting, at least for my last two workplaces. We were trying to figure out for our company.
The retrospectives I facilitate are not anonymous.
If a team member asked me to allow anonymous comments I would certainly do so. I would then try and investigate why psychological safety was so low that team members were worried about being associated with their comments.
It depends, mostly on the level of trust between team-members.
In the best practise situation people are open and have the courage to be themselves, transparent and traceable. Sometimes it helps if voting is anonymous. Still being able to confront each other truly is part of great teamplay.
It greatly depends on the level of trust a team has, have a look ath the trust pyramid.
Why do you need to capture comments or document anything that happens in a retrospective, other than specific, concrete, actionable opportunities for improvement and perhaps some rationale around the improvement, such as why it is valuable or what benefit the team hopes to achieve by enacting it? By removing comments and documentation, you no longer have to worry about keeping people anonymous since there's no record of things that individuals said.
The three pillars of empiricism at the base of the Scrum framework are: transparency, inspection, adaptation.
Transparency also means to have a safe zone to share openly during the retrospective what can work better within the team (and even outside), so no need of anonymous participation or to document what is being said to be used outside the team...
Openness, courage, and collaboration are foundational to effective agile adoptions. Anonymous complaints, suggestions, or concerns are often a symptom that this foundation is either missing or broken.
If you have a Scrum Team where the team members don't feel safe expressing opinions within the team, or don't feel empowered to address process issues head-on, then you have an existential problem with your Scrum implementation. This is most often seen in high power-distance cultures and organizations.
There can certainly be exceptions that would justify a specific problem being brought up privately. Some examples might be sexual harassment, bullying, or other issues that are more personal or interpersonal. Such issues could certainly fall outside the scope of the project and its processes. In such cases, the Sprint Retrospective is probably not the right venue for addressing those concerns anyway.
However, most project and process issues are whole-team responsibilities. Mature Scrum Teams are expected to collaborate as part of the empirical inspect-and-adapt process, and have the courage to address hard problems together.
In Agile Scrum Retrospective boards, what is the best practice?
I'm not sure what "Agile Scrum" is supposed to be, but the official 2020 Scrum Guide has very little to say about how you must implement the Sprint Retrospective. Using boards with index cards or Post-It Notes is just one of many possible techniques. It's a means to an end, not a mandated practice of the Scrum framework, and not one of the framework's defined artifacts.
The purpose of the event is pretty straightforward, and is summed up in a single sentence.
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The activities required by the event are not highly prescriptive. The guide simply says:
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved...The Scrum Team identifies the most helpful changes to improve its effectiveness.
Note the emphasis on the whole-team approach to inspection, discussion, and problem-solving. Those things are hard to do when process issues or team collaboration problems are raised anonymously.
Furthermore, a persistent need for anonymity would violate the five core Scrum Values, especially the last three.
In fact, the guide goes on to say (emph. mine):
The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, [and] to work on tough problems [together].
If these values aren't being embraced by the team, then that's a process or implementation issue that should be discussed. It may not be enough to do so in a Sprint Retrospective. It may be a big enough issue that the need for coaching or root-cause analysis needs to be made visible on the Product Backlog, and time carved out of one or more Sprints in order to address it properly.
If the Scrum Team lacks the openness and courage to discuss process issues forthrightly, this not only fails to embody the framework's values, but it also violates one of the core pillars of Scrum Theory: transparency. The guide admonishes practitioners that:
Artifacts that have low transparency can lead to decisions that diminish value and increase risk.
An anonymously-populated retrospective board seems like an artifact that intentionally lacks transparency. The Scrum Team should collectively determine why doing it that way increases value or reduces risk. If it does neither, then it's an anti-pattern.
Basically, this all boils down to saying that Sprint Retrospectives and the framework in general are designed for committed self-starters who are willing and able to work together to solve process problems and continuously improve their working agreements with one another. If they can't or won't do that, the problem is much bigger than whether or not the team members are visibly placing stickies on a board or prefer slipping folded pieces of paper into a suggestion box.
There is no single "best practise" for whether team members should sign their names next to each comment on Agile Scrum Retrospective boards. The team should decide whether or not to incorporate names based on what will work best for them.
To promote follow-up conversations and make sure that everyone's criticism is heard and considered, I personally prefer to include names with comments. When team members wish to address specific feedback or seek clarity on specific comments, this strategy might be useful.
Open professional direct confrontation is better and more effective, but it requires maturity.
Fun thing is that you can ADAPT IT depending on two factors:
In case of doubt, ask directly your team members. Explicitly state your team members that ceremonies aren't for accusing people, but for discussion ideas, risks, fears, suggestions, opportunities etc.
During adoption of Agile, it is ok to provide space for open discussion and some space for anonymous comments.
Ric
In Agile Scrum Retrospective boards, the best practice is for all team members to participate and provide honest and constructive feedback. The retrospective is an opportunity for the team to reflect on the previous sprint, identify areas for improvement, and develop actionable solutions.
Regarding the use of names on the retrospective board, it is generally recommended to keep the feedback anonymous to encourage open and honest communication. This allows team members to express their opinions without fear of judgment or backlash.
Therefore, it is best to avoid attaching names to individual comments, but it is important to ensure that team members feel comfortable enough to share their views. You can consider using anonymous methods such as an online survey tool, post-it notes, or assigning each team member a random number to associate with their feedback to keep the feedback attribution anonymous. More important than keeping track of the identity of who made the comment is synthesizing the insights and identifying themes that emerged.
