No, you misunderstand. I don't care about the breakdown, but I do care about these tasks and concerns (and you seem to agree that they exist). How to deal with

No, you misunderstand. I don't care about the breakdown, but I do care about these tasks and concerns (and you seem to agree that they exist). How to deal with them needs to be explained in the context of the new methodology, and how it relates to the old ones. That's what I have not seen with Scrum, it pretty much ignores all the history of project management as a discipline. And actually, when I started programming professionally, I didn't think that management was necessary, and that we could self-organize and all that. But as I changed projects and bosses, it turned out, I just had a good manager (and it was a waterfall-like method, by the way). So I think the idea of self-organization is intuitively appealing to many people (especially young without any experience), and if you have a person in the team who can naturally take each of these roles, then I think it can work (that is - sometimes). But today, I don't think it will work in general, and for that reason. Now I recognize that, for instance, you need somebody well-organized on the team who can make sure things do not fall under the table. Or you need somebody who is process-oriented, interested in improving process. Then self-organization can work. If you don't have people with specific traits like that, or they don't emerge as natural leaders (gain respect) in their specific areas of interest, then you need to appoint somebody to have that role. Then it makes sense to have explicit project manager, or product manager, or architect, who focus on certain tasks and concerns. I suspect the fact that sometimes you can do without having these people designated as such can account for some anecdotal success of Scrum (or any other method - I personally had the best experience with waterfall-like approach).