Skip to main content

A 'development team access policy'?

Last post 10:53 am May 17, 2016 by Timothy Baffa
1 reply
05:55 am May 17, 2016

Does anybody have any experience of implementing a 'development team access policy'?

What do I mean by this term?

Working in a large, highly regulated (and controlled) organisation all staff member are subject to the same local machine restrictions, i.e. website access, inability to run .exes, install browser extensions etc.

I am working on a proposal to standardize a development team policy, whereby team members have complete control over their local system. I hope to see less time wasted circumventing these measures, which in reality is all that happens.

If you have any experience in fighting this battle, I'd appreciate your input.

I'm particularly interested in the 'how' i.e. VLAN, filtering/sweeping etc. Realistically, considering the type of environment in which this organisation operates, certain security controls would still need to be in place.

Thanks,
Anthony


10:53 am May 17, 2016

Anthony,

I did have a similar experience at a previous assignment (highly regulated financial firm, strict security restrictions).

Our approach was to create a single "dedicated" on-site workstation with relaxed security controls. The workstation basically served as a "gate" to access websites otherwise restricted to the development team, in order to facilitate learning and aid development. The team was also able to use the relaxed machine restrictions to try different configurations to help their sprint development and testing.

Unfortunately, I cannot provide specifics on the "how" part, but my suggestion is to try a small "experiment" with operational and organizational oversight, as opposed to seeking a sweeping change to machine security and configuration for all of your Development Team members.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.