I'm a lead on a team of 13 right now: myself, 6 developers, a QA lead, 2 testers, analyst, scrum master, and product owner.
We're one of ~15? teams in my organization (part of an overall IT shop of ~3000), but we're fairly separate from the others in business and technologies. We have a delivery manager for our team and a couple other efforts. There's a dedicated tech lead of tech leads, program level PMs, lead product owner, 2 architects. There are also some other folks from the business side, change management, etc that we work with regularly.
We're going through a bit of a change at the moment, removing the QA and analyst roles, spreading scrum masters across 2 teams, and limiting team size overall. So by the end of the year, I expect to have myself, the product owner, analyst is moving to scrum master, 1 QA as developer, 1 QA maybe as developer (we'll see how he adapts), and 4 developers.
It is a really big organization with dedicated departments for security, security testing, application security, performance testing, accessibility testing, brand management, change & release, test data, DB, DB security, gateways, shared components. And those are only the folks I interact with - there are mainframe folks, server maintenance (linux and windows), and the list goes on.
Some of that is moving to the teams now, some later. It's a pendulum though, things will be more generalized and distributed until something breaks spectacularly and someone will ask "why don't we have dedicated testers? why are we trusting every ol' dev with DB access?" and so on.
There are many industries which have found value in specific people to do the paperwork and deal with process. I don't think it's needed under 10 or so people if you have a good team, but once you're we'll into the 20+ range, I don't understand why so many devs are so set against giving this type of work to someone else.
It's certainly not what I want to to be doing day-to-day, yet our tools aren't smart enough today for me to do well in a larger org without it.
Yes and no. On the useful side, they own some of the process inherent in large organizations. But they also act as a conduit to push that process to team members.
In practice, our scrum masters have been a place for the PMs, Analysts, and QA leads to go as their positions have been displaced. I would like to see more technical scrum masters that can own technical impediments, but that doesn't seem to be happening yet.
I also think that spreading scrum masters across teams will disconnect them from the specifics of the work and allow them to act more as coaches than non-technical team members.
We're one of ~15? teams in my organization (part of an overall IT shop of ~3000), but we're fairly separate from the others in business and technologies. We have a delivery manager for our team and a couple other efforts. There's a dedicated tech lead of tech leads, program level PMs, lead product owner, 2 architects. There are also some other folks from the business side, change management, etc that we work with regularly.
We're going through a bit of a change at the moment, removing the QA and analyst roles, spreading scrum masters across 2 teams, and limiting team size overall. So by the end of the year, I expect to have myself, the product owner, analyst is moving to scrum master, 1 QA as developer, 1 QA maybe as developer (we'll see how he adapts), and 4 developers.
It is a really big organization with dedicated departments for security, security testing, application security, performance testing, accessibility testing, brand management, change & release, test data, DB, DB security, gateways, shared components. And those are only the folks I interact with - there are mainframe folks, server maintenance (linux and windows), and the list goes on.
Some of that is moving to the teams now, some later. It's a pendulum though, things will be more generalized and distributed until something breaks spectacularly and someone will ask "why don't we have dedicated testers? why are we trusting every ol' dev with DB access?" and so on.