The daily standup ("scrum") did make some sense in the context of agile development. The idea is that you embrace the unpredictability of software and respond to change. So you take on a task, but you accept that the task is likely to not go as you expected. You may need to change direction. You may need to take a different approach. Or you may need 10 weeks instead of 1, and even that is getting fuzzy… under these circumstances, it can be useful to remain in frequent contact with the development team and business/end users users.
But as you pointed out, daily scrums can essentially devolve into what is essentially a policing of developers to make sure they are staying the course and are reminded daily of their deadlines.
It's actually just an unusually unfriendly version of waterfall. Why? Cause at least in waterfall, the business users are forced into something unfair and impossible as well. It's impossible for developers to accurately estimate completion dates, but it's also impossible for business units to accurately and fully spec out a software application. "You didn't meet your estimate"... "Yeah, well, you changed your mind".
It's a nasty business, but there you go. Best to avoid the entire thing and work on projects that are very high value but aren't deadline dependent, where the value of a developer is measured by working software at reasonable intervals rather than daily discussions of sprints, stories, and deadlines.
Actually, in some ways, that sounds more like what agile is supposed to be than all this scrum/velocity/stories stuff that isn't in the manifesto in the first place.
But as you pointed out, daily scrums can essentially devolve into what is essentially a policing of developers to make sure they are staying the course and are reminded daily of their deadlines.
It's actually just an unusually unfriendly version of waterfall. Why? Cause at least in waterfall, the business users are forced into something unfair and impossible as well. It's impossible for developers to accurately estimate completion dates, but it's also impossible for business units to accurately and fully spec out a software application. "You didn't meet your estimate"... "Yeah, well, you changed your mind".
It's a nasty business, but there you go. Best to avoid the entire thing and work on projects that are very high value but aren't deadline dependent, where the value of a developer is measured by working software at reasonable intervals rather than daily discussions of sprints, stories, and deadlines.
Actually, in some ways, that sounds more like what agile is supposed to be than all this scrum/velocity/stories stuff that isn't in the manifesto in the first place.