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.

>scrum master

Serious question, do you find real value out of this position?

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.

Funny you say that while every other "expert" says it's pointless to do scrum above around 10 members.

Not that I believe any of that eh, scrum usually devolves to ritualistic, empty blabbering in around six months anyway.

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.

Yes absolutely, a good one is invaluable at helping the rest of the team be more productive.

They forgot QA lead. I know it's currently posh in some companies to do away with QA (YOLO software development methodology?). I've found successful software delivery without a strong QA lead on equal footing as the tech lead and PM/PJM is a recipe for disaster. QA is often the only source of truth that you can rely on when you want an accurate assessment of where things stand.

The thing is that tests generally have to be a core part of the development process now, so if the QA isn't being driven by the devs then they aren't doing software engineering quite up to contemporary standards.

Having said that, I have had a lot of jobs on small teams, especially some years ago, where testing was inadequate or not really part of the development process, and I always tried to convince them to hire one good QA person. They never listened. Instead on a few occasions a user or business analyst would be assigned to QA which I explained was a joke. But I guess I have just not had the best budgeted projects or something.

I don't think testing and QA hit the same sweet spot. Trying to automate acceptance tests often gets into brittle territory, doubly so on mobile apps. Obviously it depends a lot on the nature of the product, but in a lot of cases human QA (perhaps with QA engineers building some partial automation) leads to a higher quality product at a lower cost than trying to get fully automated test coverage for everything.

Dev needs QA/Test just like writers need editors.

I was a QA manager for a while. It's been over 10 years since I've worked somewhere that had any sense of QA/Test.

Now we have Horde, err, Scrum and DevOps. Proudly. It's like the industry just gave up.

I don't what it's like at the allegedly highest functioning teams (environments) Google, Facebook. But out here in the wild, it's madness.

Dan Luu has been best at capturing and articulating "contemporary standards" for what passes as "quality" in software development. http://danluu.com (I wish I was 1/2 as smart as Dan.)

"Delivery manager" is basically how people say "project manager" now. Their job is to set priorities, triage incoming issues, make sure everyone knows what everyone else is doing (when relevant); coordinate with third parties or external integrations, etc. Product owner is who you're building the product for - in client services it would be your client; for internal projects it would be who is "driving" (more bizspeak) the project - could be the CEO or a marketing person or a VP or whatever. Tech Lead is responsible for making technical decisions, architecture, hopefully writing some code, etc.

"Project Manager" has negative stigma. I'm not entirely sure why, but I think the perception has to do with the way that project management might be done in larger organizations - concern for minutia and TPS reports over actual accomplishments.

The Project Management Institute and their certification process has led to a situation where project management is seen as a domain-agnostic discipline. As a result, many certified project managers know little about the domains they are managing. Furthermore, coming from the construction industry, many of the traditional project management processes and thought is linear and waterfall in nature. They have taken steps to adopt agile and iterative processes in the past few years, but bear great legacy costs when it comes to applying project management to technology projects (where many projects fail for a variety of reasons).

The minimum team size is one: A single person building a project.

I'd guess the minimum successful team size is in the 2-3 range. At the very least you must have a client or customer of some kind and a developer or implementer.

I think it is possible to have a successful team of one. Customers aren't usually included as part of the team.