Can we restrict who can see Retrospective boards?

evan-hyer commented 4 years ago

Retrospective boards are currently visible to anyone is our ADO project...

In order for the feedback/"circle of trust", it would be nice to have an option on restricting who can see the Retrospective board. I.e. Only members of that team can edit and see feedback entered on the board

ArieHein commented 4 years ago

General question:

Who is a member of the default Team or if you have additional teams ? You realize everyone that is a contributor can see your kanban board? why would you need a second level of trust ? what are you afraid of them seeing ?

You trust your devs to commit code but not see retro board, while they still see your kanban boards and the ideas that came out of the retro ?

diveflo commented 4 years ago

I'd love to see this feature as well. For me, it's more the other way round: I don't think everybody on the team will be completely honest (and vent!) if some "higher ups" can see the board.

ArieHein commented 4 years ago

@diveflo So what you are asking was actually asked in other ideas and is slightly different. then this one.

I mentioned in a request long time ago that we should have a way to avoid people reading other peoples ideas WHILE they are added as that has an effect on what people will write if they see another idea. Only allowing all members to see the ideas written after everyone has finished and that phase was marked as "Closed".

If you want to compare it to how retros are done today, everyone writes their own notes for themselves, they all hand their notes at the end to the scrum master or other person who then places all of them on the board (without specific order if they choose to) and then they discuss it and try to find similarities for the "grouping phase". This behavior isn't 100% in the extension today as people edit their ideas in the same UI where you read the ideas and can do that while others are entering their ideas.

What the OP asked is to limit viewing the retro board form people inside the project, for which i commented that there are a set of roles in a project, Read and Contribute and noted that its a bit silly, imho, to give someone permission to commit code to a repo (even if via a PR) and see all the items on the kanban board / backlog (which will include workitems created as result of the retro to being with) but not be able to take part in the retro.

It means originally people were added to the "team" that shouldn't be there in the first place, but that's configuration issues not to mention again, trust issues within the team if you have to get a 2nd layer of trust.

evan-hyer commented 4 years ago

@ArieHein - To your point, I'm am aware our kanban board is visible to everyone, in the spirit of Agile, it should be! Our work should be transparent to everyone in the company, if someone is interested in how much progress a team has made, they can simply go to our team's kanban board without asking a developer or scrum master directly.

@diveflo Has the right idea on why I proposed that. Transparency becomes a concern with retrospectives, the visibility can and should be different. A Scrum Master shouldn't be sharing retro notes to superiors, that information should stay internal to the team. The benefit of a retro is to improve the team performance and maturity. An example: If your team is struggling with a problem with another team or is trying to share something that they don't want their direct superior to see, it could prevent someone from being transparent and sharing those details.

ArieHein commented 4 years ago

How can you in one paragraph speak of agile and transparency and in the next speak about hiding information and struggles with others ? Do you understand what a bad culture this is ? Do you understand that by hiding you're contributing to this bad culture ? Do you think you have what it takes as a scrum master to understand the business risks that a company might face because one team has issues with another team ?

How many good ideas a person wrote once were disregarded by the team, and left outside the backlog because political agendas, ego and seniority ? Every single post-it note has a voice and a weight and MUST be made visible if only so you can reflect back (see what i did there ?) even in future retrospectives about how the overall progress was made.

Do you think that if a person is reluctant to share struggles in a normal retro he will find this extension as the safe haven for him to publicly make his claims ? NO. He will be silent with it and without it. Do you think he will all of the sudden have the confidence to speak up because its not "visible" by managers ?

Heck i would put my keys on the table the next day and look for a new job if we have to work in "secrecy" instead of openness. Cause that is exactly how you get a bad culture.

You want to make a change in how companies work, you first tackle Culture and Communication. Openness and Visibility are key ! Agile was born exactly because of the lack of visibility and accountability.

We should not bend a tool to a "political" agenda. We "bend" the agenda. Or as the boy told Neo:

"Boy: Do not try and bend the spoon. That’s impossible. Instead… only try to realize the truth. Neo: What truth? Boy: There is no spoon. Neo: There is no spoon? Spoon boy: Then you’ll see, that it is not the spoon that bends, it is only yourself."

---rant off.

evan-hyer commented 4 years ago

@ArieHein Seems like we a case of Purist vs. the Realist. In the purest form I agree with that you're saying. Heck even all forms of communication, chat messages, emails, etc. should be open to everyone to see and read, right?

Ultimately it should be a team decision on what should and should not be shared. If there is a lack of safety and security to speak openly (due a potential culture problem like you mentioned) how would that issue ever come to light? It wouldn't... the team member would hold onto the issue and the problem would most likely get worse, and the concern would never be addressed. 99% of the time the team would most likely being fine sharing even the most intimate of details from their retrospective. Empowering the team is the entire thought behind my proposal.

A way to be transparent is focusing on sharing outcomes of the meeting (work items, action items), rather than details.

It's clear we have our differences on to approach retrospectives which I'm fine with.

https://www.mountaingoatsoftware.com/blog/should-you-share-details-from-the-retrospective

vhemmert commented 4 years ago

Great Extension! Thanks for it!

@DCcanadian1 - I fully agree, my Scrum Masters colleagues and I would love to see this feature - a simple way to assign users to the Retro board (a Scrum team is small enough, maybe as well Scrum Masters from other teams). Our team boards are open for everyone in the organization, we do not limit our Azure DevOps "Sprints" backlogs and "Boards" to a team - that means the Retro boards are open as well :(. Action Points ("+ Add work item"), as a Retrospectives outcome, are triggered as work items that are part of our team Sprint Backlog - so here you have the visibility of the Retro output - great solution here, provided by the extension!

Sorry to read this: https://github.com/microsoft/vsts-extension-retrospectives/issues/5 We are still in evaluation phase: let's see how many of our Scrum Masters (we have a lot of them) will use the extension, without this permission feature...

I am not a fan of having the retro workshop open for the "whole" organisation - action points/work items it makes sense. At least: "Make all feedback anonymous" helps here a little bit.

abrower10 commented 3 years ago

Aside from the internal org conversation what if you have external people (contractors/stakeholders) in the team. You are able to set permissions for what they see and don't see within ADO why would you not be able to do the same with Retros. If my team is upset with our stakeholder and vents in the "safe place" of the retro and then I cannot insure that the said stakeholder cannot see such messages. Then there is an issue. Does this extension tie into the default permissions of ADO (stakeholder, contributor etc)?

silanosa commented 3 years ago

@abrower10 Exactly this. We have stakeholders with access to our Azure DevOps, limited to their own small subset of backlogs, boards etc. But for the Retrospectives extension, I currently see no option to limit access to only our internal org. I would love to see a feature with the option to effectively limit access to specific teams. For our purposes, this would not have to be complex, e.g. see retro entries, modify/delete entries, permission to vote etc. A strict "access" or "no access" to the retro board would be perfectly adequate.

MatthewDiPietroTR commented 3 years ago

I would love this feature as well--it's been a common issue that team members have with using this extension because we have 15 individual development teams of a larger organization, and a significant number of external team stakeholders all in the same project.

To echo what others have said, retrospectives are intended to be a safe space for the team. As their manager, the general expectation is that I'm not even included in retrospectives, and they should feel comfortable to say "I keep getting interrupted on my tasks by my manager calling me into meetings and it is really frustrating to me"--this isn't the case, but if it were, they should feel comfortable reflecting on that disturbance without fear that I'm scouring the retro boards looking for negative feedback.

Yes, ideally you have a culture of openness that would allow the team member to just come to the manager directly, and while I foster that environment on my teams, that doesn't mean every single team member is going to be comfortable addressing that directly with their manager, or an external team member, or any other stakeholder. It's not anti-pattern to create a safe environment where feedback can be shared and discussed within the team without having prying eyes.

WTobor commented 3 years ago

Is there a plan to develop that functionality?

justdait commented 2 years ago

@ArieHein Sprint Retrospectives are by the team for the team to focus on inspect and adapt / team continuous improvement. The development team should have the option to decide whether they share retro information or not. Simply if the team feels like the information will be used against them then they will not be open in their retrospectives and you will never get to resolving the core (normally political) issues. It's bad that retrospectives are open to anyone who has access to the board. Yes we want to be transparent with the work and how we improve. That's what the board and reviews are for, not what the sprint retro is for.

ArieHein commented 2 years ago

I agree that devs need to feel safe to express their ideas and pass on criticism when things don't work well. What i do not like is that retros being used to "hide" opinions for the sake of PC. Remember that even if you create a project and have multiple teams and multiple areas and thus multiple retro boards, if you want cooperation, if you want collaboration, you cant hide things from other teams in the same project. If i dont belong to team A, but Team A board says team B didnt work correctly and it affected team A performance, shouldn't that information be visible ? should Team B be "attacked" without them being able to answer back ? I feel you are also looking from a specific group structure of only developers or of a specific role and thus the diff teams (front end team, backend team, qa team, devops team) vs a team structure that is (2 FE, 2 BE, 1 QA, 1 Devops, 1 DBA etc ) where there are other external factors that can block team A (lets say a shared service all teams rely on, but has different effects on the teams).

Retro boards should not be the place to store all the "dirty laundry". That does not support openness, transparency, inter-personal relations, belonging etc.

Now taking all this into an account, should an extension be the one to educate you how to run a team / structure ?

AZDO own RBAC system isn't set to deal with fine tuning permissions for all types of group/team/project structures. It has Reader and Contributor and that's it. You will have to do some complex work to "hide" Team A Kanban board from Team B, as they are basically the same board but different Areas to allow basically immediate filtering of the view. I've seen different projects use different ideas when creating Group/Teams structure that would make this retro board filtering impossible.

I doubt you will be able to change AZDO RBAC for one extension as its has huge implications over all.

But bottom line for me at least, If a person or team feel comfortable to complain about another teams' performance, they should feel comfortable to receive criticism and feedback in return. You only get that with transparency and accountability. If you think this transparency will cause people to not participate and engage, out of fear of repercussion, I think the issue is far bigger in the culture than ANY extension/plugin can help you with.

justdait commented 2 years ago

Put simply - The retro is by the team and for the team and should be restricted to the development or selected team with them having the option to share information. Obviously, all Agile teams want to make their way to innovation transparent and should share as much as they want but it's very very rare where you will find an organization where people can express all opinions whilst maintaining complete Psychological safety within the team. If just one member of the team feels like their opinion will be judged negatively by just one other person in the organization then they will not report honestly and the whole retro process is affected. This should be as simple as selecting a user group, which are quite easily set up. Suggest googling psychological safety from an education rather than personal opinion perspective. What is shared in a retro should always be the choice of the team using it, if it's open to anyone you are going to lose a hell of a lot of value from your retros. Remember in the modern applicational use of DevOps it's not just your organisation that has access but also customers and partnering organisations as well. Speaking for the teams I coach, they don't complain about other teams' performance in retros, they focus on the process issues and look for ways to resolve them collaboratively.

From: Arie Heinrich @.> Sent: 17 September 2021 08:28 To: microsoft/vsts-extension-retrospectives @.> Cc: justdait @.>; Comment @.> Subject: Re: [microsoft/vsts-extension-retrospectives] Can we restrict who can see Retrospective boards? (#49)

I agree that devs need to feel safe to express their ideas and pass on criticism when things don't work well. What i do not like is that retros being used to "hide" opinions for the sake of PC. Remember that even if you create a project and have multiple teams and multiple areas and thus multiple retro boards, if you want cooperation, if you want collaboration, you cant hide things from other teams in the same project. If i dont belong to team A, but Team A board says team B didnt work correctly and it affected team A performance, shouldn't that information be visible ? should Team B be "attacked" without them being able to answer back ? I feel you are also looking from a specific group structure of only developers or of a specific role and thus the diff teams (front end team, backend team, qa team, devops team) vs a team structure that is (2 FE, 2 BE, 1 QA, 1 Devops, 1 DBA etc ) where there are other external factors that can block team A (lets say a shared service all teams rely on, but has different effects on the teams).

Retro boards should not be the place to store all the "dirty laundry". That does not support openness, transparency, inter-personal relations, belonging etc.

Now taking all this into an account, should an extension be the one to educate you how to run a team / structure ?

AZDO own RBAC system isn't set to deal with fine tuning permissions for all types of group/team/project structures. It has Reader and Contributor and that's it. You will have to do some complex work to "hide" Team A Kanban board from Team B, as they are basically the same board but different Areas to allow basically immediate filtering of the view. I've seen different projects use different ideas when creating Group/Teams structure that would make this retro board filtering impossible.

I doubt you will be able to change AZDO RBAC for one extension as its has huge implications over all.

But bottom line for me at least, If a person or team feel comfortable to complain about another teams' performance, they should feel comfortable to receive criticism and feedback in return. You only get that with transparency and accountability. If you think this transparency will cause people to not participate and engage, out of fear of repercussion, I think the issue is far bigger in the culture than ANY extension/plugin can help you with.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/microsoft/vsts-extension-retrospectives/issues/49#issuecomment-921564991, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATC6JBF4MM3URFLL237QQK3UCLUZLANCNFSM4PUUCJFQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

dieselart commented 2 years ago

For our company it is necessary to limit access to Retrospectives section, because our Customers have access to ADO to work with work items. We suggest making this restriction as described in my comment to issuer: https://github.com/microsoft/vsts-extension-retrospectives/issues/5#issuecomment-981604402

dstoddar commented 2 years ago

Thank you for the dialog. We are currently developing an updated version of the retrospective plug-in and after release we are going to prioritize the option of limiting access to only team members in a future release. Stay tuned!

WTobor commented 2 years ago

Is there any roadmap for that feature defined?