How to handle access to resources on a Scrum team which was previously a hierarchical team?

Question

From what I've read and learned about scrum from my recent reading, as well as years reading the great questions and answers on this site, a scrum team is a team of equals, where there's no hierarchy, and knowledge is shared vigorously.

Is it still possible that some members of the team may have specific access to a set of resources which others do not? For instance, a database expert on the team may have the ability to run SQL queries against the live, production database, but one might not want everyone on the team to be able to do this who isn't trained in SQL. Is this a correct way of thinking, or would we give unrestricted access to all on the team and warn them not to break stuff?

What about simpler things, like the team's Slack instant messaging system? It's arguably much harder to break Slack (or Sqwiggle, gitter.im, or any other instant messaging system). Would it be expected that everyone be an admin to this system, or would a specific individual serve as the admin?

I am concerned about things like this because they could inadvertently preserve some of the pre-scrum hierarchy that exists prior to moving to the scrum framework. What is the best way to approach these things on a new scrum team which was previously non-scrum?

Answer 1

Cross-Functional Teams, Trust, and Risk Management

There are really a number of issues buried in your question. Let me try to address them sequentially, although the order isn't actually important.

1. An agile team must be cross-functional, but that doesn't mean that everyone one the team has the same skill set or level of access. As long as the team has all the required skills and passcodes, that's sufficient for an agile framework.
2. Agile teams are built on trust. If the message is "we don't trust Bob with the root password," then there's a fundamental problem with your team's composition or development process. However, if the issue is a separation of duties concern (as it is in some environments, regardless of framework) then it's perfectly fine to let teams self-organize around the fact that some access is on a need-to-know basis.
3. Agile teams are responsible for self-organization and self-managing. If there's a risk that someone on the team could blow away a critical service by accident, then the team should have backups, roll-back plans, disaster recovery plans, and other contingencies in place before asking anyone to do something dangerous regardless of their level of skill. This is also a great opportunity for cross-functional training!

I've been on agile teams where everyone had the root password, and anyone could push to production. However, all the systems were Puppetized, and our infrastructure was fully version controlled. Risk was therefore minimal.

I've also been on teams where the team had full access to development, but none into QA or Production. That was fine, too, since our functional responsibility stopped at those boundaries.

While segregation of duties is not the DevOps ideal, it isn't actually counter to any of the agile principles when properly implemented. If segregation of duties is necessary, simply lay out the requirements and let your team organize itself around the implementation details.

Answer 2

Nothing in Scrum says that everyone must be equal. A Scrum team must at least have all skills and permissions required to deliver a done increment of software every sprint.

So as long as there are team members with the right permissions, that should be enough.

On the other hand, a scrum team should be mindful of its "Truck-factor" and ensure that skills and knowledge are spread across the team. So if you only have one person with the skills and permissions to change production databases, it' highly recommended that he pairs up with another developer to spread that knowledge and over time hand out a couple of copies of the keys to the castle so to speak.

To prevent the old hierarchy to resurface, talk about the ambitions for the team and have them come up with ways to spread the skills, knowledge and permissions. Retrospectives are a good starting point, but it may be that your team may need to get a few directive pointers (aka constraints) that tell them that certain things are no longer desired behavior.