A large part of Agile, at least from what I remember in my ScrumMaster training, is to recognize reality.
You estimated that you would do x amount of work. You only did y. Or, you did x + z - wow, you are a great performer. You should verbalize your success more often.
A part of confronting reality, is confronting the prospect of under-performing employees.
I think your 'ideology' is blinding you a little bit OP, at least - if you want to base your concept of standups based on how they were formulated in the original Agile manifesto - 'At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.'
Frankly, most dev teams don't give a whit about Agile and just do stand-ups to keep the PMs and SMEs appraised of progress and to check in on a couple of things here and there.
The selective pressures of your model reward dishonesty (under promise over deliver / make estimates as high as possible to mitigate downside and reduce pressure). Why is that making your team better?
If my estimates are padded to the point where I always complete what I commit to and my boss is happy with my output, what’s the problem? My boss gets value from being able to accurately convey estimates to clients, the client 9/10 gets the work done on time or maybe even gets a couple extra features completed in the same timeline, and I as the engineer, have a relaxed work environment, free of the stress of cramming every story point possible into 40 hours a week.
This might be okay in isolation, but eventually as the entire team of engineers start to underdeliver, the team and company does get affected in terms of feature rollouts / velocity, and it's difficult to recover from it. People won't want to suddenly correct / do more work even if it's crucial, and they can point to their previous underestimated commitments and say that is a full week's worth of work. YMMV as with anything, but not knowing a team's true velocity does affect planning and sales.
The actual work doesn't change, it just changes your point estimations. Either the boss is happy with the actual pace and quality of the work, in which case you don't need points to begin with, or the boss doesn't understand the difference between story points and actual time, in which case it's all a dog and pony show anyway.
All this teaches employees is to lie to make themselves look good. If you really want to increase development velocity, implement better coding practices and devops and tooling and training and invest in your employees instead of making jump through stupid hoops like circus animals.
No, you aren't. You just either suck at estimation, or you deliberately underestimate to shine brighter in the eyes of your slavemaster. And if the rest of your team also "overperforms" consistently, there's a conspiracy, which means I will stop making you commit on stuff and will just ram more tasks down your collective throats, abandoning another aspect of the agile way of work.
See how easily such an abuse of standups can be turned around to make the very same person look bad? If that is possible, is the approach a good one?
> most dev teams don't give a whit about Agile and just do stand-ups to keep the PMs and SMEs appraised of progress
This is mostly related to PMs and SMEs pushing a perverted interpretation of Agile.
You estimated that you would do x amount of work. You only did y. Or, you did x + z - wow, you are a great performer. You should verbalize your success more often.
A part of confronting reality, is confronting the prospect of under-performing employees.
I think your 'ideology' is blinding you a little bit OP, at least - if you want to base your concept of standups based on how they were formulated in the original Agile manifesto - 'At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.'
Frankly, most dev teams don't give a whit about Agile and just do stand-ups to keep the PMs and SMEs appraised of progress and to check in on a couple of things here and there.