You make some good points (dogmatic application of anything is a mistake). But I believe you understood the whole story point thing wrong. Probably because you worked in teams that didn't make good use of it/didn't understand the benefit.
The main idea behind story points is doing comparative estimation because it has been proven to be more effective than absolute estimation (even for the most experienced). That's it.
But the thing I disliked the most about your comment was the sentence: "I simply practice Kanban regardless of the process around me". This tells me you're probably not a very good team player even though you claim to be "saving their assess down the line". Sorry, but I wouldn't like you in my team with that attitude.
All teams I've ever worked with, in fact. Exactly my point. It's always some other teams that are "doing it right" and it doesn't work "because you are doing it wrong" seems to be a common way to dismiss criticism by agile fan boys. There is no right way. Story points are cost estimations and divide and conquer is the name of the game that is being played. Break things down enough and you manage the error margin.
I actually have an academic background in software engineering so I'm somewhat more perceptive when I hear BS than some others in this industry. So, when you say "it has been proven that", I say actually no: there is no such thing as proof here. The only thing that has been proven conclusively about scrum is that in a tightly controlled experiment involving mostly student volunteers that it is not completely actively harmful and in fact may be slightly better than not having any other (unspecified) systematic approach to development at all.
I'm deliberately exaggerating but I've read most of the key papers in this space. Solid research by the way, and you are of course free to interpret the conclusions as you please but, in fact, not much at all has been proven about scrum and agile and what is often portrayed as empirical research is in fact anecdotes and marketing material promoted by for profit agile consultants that typically have a commercial interest in highlighting their presumed success stories and covering up the fact that actually the relative proportion of projects succeeding vs. succeeding in our industry is a remarkable stable thing for decades. Proper empirical research is a rare thing for cost reasons and also companies tend to not be as open about their failures and publishing all the dirty laundry around that.
I've survived a few hype cycles and the only thing that is certain is that there will always be a next one.
Regarding your team and me, you may want to consider that there are those that speak up and those that don't but would like to. All I'm saying is, don't shoot the messenger: you likely have people on your team already that maybe wouldn't disagree with the above. I talk to lots of people with reservations on this front that maybe are not in a position to call out their PMs on the agile BS they are being subjected to on a daily basis.
You misunderstood what I said. I said comparative estimation has been proven to be more effective than absolute estimation. I didn't say that scrum/agile has been proven anything and I don't claim such thing. Whatever works for your team is good, call it whatever. In my opinion, Scrum/Agile provides some guidelines and some empirically tested tools/resources to deal with common issues that developer teams face and it's one of the best starting points known so far.
And I agree that "you have been doing it wrong" is a common response. But is not a way to dismiss criticism, it is an attempt to say that anything that you apply incorrectly will lead to wrong results and by the looks of your comment you/your company applied or understood agile in the wrong way. Thus, you should be criticising your specific way of applying those rules not the whole methodology. Or you could criticise the way that many companies dogmatically apply scrum, of course.
I also have an academic background in software engineering (which means nothing, by the way, it is an authority fallacy) and I also think there is tons of bullshit, I completely agree with you here.
Also, yes, Scrum might be one of those "hype cycles", so what? It means people trying new stuff and techniques, trying to improve themselves and their processes? Seems to me like a good thing to happen.
Finally, what I criticised was your attitude of "I know it better than the rest, I would do it my way not caring about what others do/want". Not only I would not criticise people who "speak up" and give their opinion against our processes, I would love if they did. It would give us great opportunities to improve ourselves. And I constantly try to avoid having an environment where people are not "in position to call out their PMs".
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You make some good points (dogmatic application of anything is a mistake). But I believe you understood the whole story point thing wrong. Probably because you worked in teams that didn't make good use of it/didn't understand the benefit.
The main idea behind story points is doing comparative estimation because it has been proven to be more effective than absolute estimation (even for the most experienced). That's it.
But the thing I disliked the most about your comment was the sentence: "I simply practice Kanban regardless of the process around me". This tells me you're probably not a very good team player even though you claim to be "saving their assess down the line". Sorry, but I wouldn't like you in my team with that attitude.
All teams I've ever worked with, in fact. Exactly my point. It's always some other teams that are "doing it right" and it doesn't work "because you are doing it wrong" seems to be a common way to dismiss criticism by agile fan boys. There is no right way. Story points are cost estimations and divide and conquer is the name of the game that is being played. Break things down enough and you manage the error margin.
I actually have an academic background in software engineering so I'm somewhat more perceptive when I hear BS than some others in this industry. So, when you say "it has been proven that", I say actually no: there is no such thing as proof here. The only thing that has been proven conclusively about scrum is that in a tightly controlled experiment involving mostly student volunteers that it is not completely actively harmful and in fact may be slightly better than not having any other (unspecified) systematic approach to development at all.
I'm deliberately exaggerating but I've read most of the key papers in this space. Solid research by the way, and you are of course free to interpret the conclusions as you please but, in fact, not much at all has been proven about scrum and agile and what is often portrayed as empirical research is in fact anecdotes and marketing material promoted by for profit agile consultants that typically have a commercial interest in highlighting their presumed success stories and covering up the fact that actually the relative proportion of projects succeeding vs. succeeding in our industry is a remarkable stable thing for decades. Proper empirical research is a rare thing for cost reasons and also companies tend to not be as open about their failures and publishing all the dirty laundry around that.
I've survived a few hype cycles and the only thing that is certain is that there will always be a next one.
Regarding your team and me, you may want to consider that there are those that speak up and those that don't but would like to. All I'm saying is, don't shoot the messenger: you likely have people on your team already that maybe wouldn't disagree with the above. I talk to lots of people with reservations on this front that maybe are not in a position to call out their PMs on the agile BS they are being subjected to on a daily basis.
You misunderstood what I said. I said comparative estimation has been proven to be more effective than absolute estimation. I didn't say that scrum/agile has been proven anything and I don't claim such thing. Whatever works for your team is good, call it whatever. In my opinion, Scrum/Agile provides some guidelines and some empirically tested tools/resources to deal with common issues that developer teams face and it's one of the best starting points known so far.
And I agree that "you have been doing it wrong" is a common response. But is not a way to dismiss criticism, it is an attempt to say that anything that you apply incorrectly will lead to wrong results and by the looks of your comment you/your company applied or understood agile in the wrong way. Thus, you should be criticising your specific way of applying those rules not the whole methodology. Or you could criticise the way that many companies dogmatically apply scrum, of course.
I also have an academic background in software engineering (which means nothing, by the way, it is an authority fallacy) and I also think there is tons of bullshit, I completely agree with you here.
Also, yes, Scrum might be one of those "hype cycles", so what? It means people trying new stuff and techniques, trying to improve themselves and their processes? Seems to me like a good thing to happen.
Finally, what I criticised was your attitude of "I know it better than the rest, I would do it my way not caring about what others do/want". Not only I would not criticise people who "speak up" and give their opinion against our processes, I would love if they did. It would give us great opportunities to improve ourselves. And I constantly try to avoid having an environment where people are not "in position to call out their PMs".