2 ms·

There might not be a clear consensus what a given person does but there are three types of tasks or concerns on the project, as I outlined them. Do you disagree

by js8 8y ago

There might not be a clear consensus what a given person does but there are three types of tasks or concerns on the project, as I outlined them. Do you disagree with that? So if Scrum (or any other methodology, for that matter) wants to define a new role (to what end?), they should explain, how they are related to these concerns? What tasks that were traditionally done by the triad are supposed to be done by the new role, and why? And moreover, how are the concerns from the triad dealt with in Scrum? That's what I miss from Scrum. There is no connection to what was before, aside from using waterfall as a straw man (it's not a methodology to begin with). It's an ideology, its own world. The result of Scrum being an ideology is, somebody who becomes scrum master in Scrum, and effectively doing project management work (in the better case), by default, has no idea that there is a field called "project management", and that he should study that field. So they don't know, for instance, the classic like Fred Brooks.

lmm 8y ago
> There might not be a clear consensus what a given person does but there are three types of tasks or concerns on the project, as I outlined them. Do you disagree with that? That's one way to break down the set of tasks/concerns you've identified, sure - but only one. I don't think that the industry as a whole accepts your categorisation into three, or even your paradigm for which tasks do and don't need addressing in this way. You're coming across as far more ideological than the thing you're attacking, assuming that your particular breakdown must be the canonical one when it simply doesn't have a level of industry acceptance that would justify that.
- js8 8y ago
  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).
  - lmm 8y ago
    > I do care about these tasks and concerns (and you seem to agree that they exist). Not really, and I don't think the industry as a whole does either. Everyone has their own set of tasks and concerns; I don't think there's any consensus that says that all the important ones are on your list, or that everything on your list is important.

by js8 8y ago

lmm 8y ago

> There might not be a clear consensus what a given person does but there are three types of tasks or concerns on the project, as I outlined them. Do you disagree with that? That's one way to break down the set of tasks/concerns you've identified, sure - but only one. I don't think that the industry as a whole accepts your categorisation into three, or even your paradigm for which tasks do and don't need addressing in this way. You're coming across as far more ideological than the thing you're attacking, assuming that your particular breakdown must be the canonical one when it simply doesn't have a level of industry acceptance that would justify that.

js8 8y ago
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).
- lmm 8y ago
  > I do care about these tasks and concerns (and you seem to agree that they exist). Not really, and I don't think the industry as a whole does either. Everyone has their own set of tasks and concerns; I don't think there's any consensus that says that all the important ones are on your list, or that everything on your list is important.