When I described a daily standup to my father and brother, a physician and a university professor, they shuddered a bit. Many people from outside software do. I've heard this described as violent transparency, and if it seems intimidating to people on the outside, that may just mean that we, as software developers, have grown so accustomed to a fundamentally unfair work environment that we no longer question it. Similar to "interviews" that are actually whiteboard exams. Did you know that most job types don't interview this way? Again, my friends who work outside software shudder a bit when they hear about this practice. It sounds awful, because it is kind of awful.
Now, in spite of my stated belief that it is awful, I did explain (or at least tried to) why we do it. Software is highly unpredictable, and difficult to estimate. We pick a task, and work on it, and report on it. This, at least at first, was to me the essence of agile. Waterfall wasn't working. It is difficult and, ultimately, unproductive to try to spec out everything in advance. You have to evolve toward a solution, through repeated iteration and constant communication. Not a bad idea.
Here's the problem - agile turned out to be a particularly insidious version of waterfall. The point of all this "violent transparency" was that we embraced the essential futility of estimates. We make them at as granular a level as we can get away with, but what we are really doing is reporting in every day on how things are going, and embracing the fundamentally uncertain nature of what we do. Well, these standups turned out to be an irresistible opportunity for micromanagement and a daily application of pressure deadlines.
I view agile as the Nitroglycerine of the software development methodologies. At some point, you can't keep saying "it would be safe if they'd just use it more carefully." The inherent instability of nitroglycerin is the flaw. And agile is just too damn unstable. Any dev who things the customer (could be a project manager, a boss, a stakeholder from a different department) is going to "collaborate" if the spec isn't met by the deadline is just shaking a big bottle of nitroglycerine. And at this point, the daily "standup" will be a person patiently waiting for the developer to finish making excuses (which is what these three questions will be interpreted to be), followed by "so are you going to make your new deadline, or will this be pushed back even further).
In many ways, if hard deadlines are involved, I prefer standard old waterfall. The original agile manifesto says "customer collaboration over contract negotiation". Indeed! Sounds great. Let's work together with trust, rather than lawyering up at every occasion.
Here's the thing - if you're committing to a deadline but the customer (who is often internal, with "litigation" being complaints to the bosses), doesn't commit to a spec, well, your customer is protected by a contract, but you, the dev, are completely exposed. Yes, change is common and must be embraced. If you'd like to change the contract, I'm all ears, but that will require - yes - a renegotiation of the contract, including the deadlines.
Otherwise, the agile manifesto, almost seems like it encourages software developers to be pacifists in the middle of a war zone. Look, if a customer is going to hold my feet to the fire on a deadline, I am going to hold the customer to the original spec.
Personally, I got out, found a job in software development where deadlines aren't a big part of what I do. Not sure if everyone can get a job like this, but it seems product oriented companies are more likely to work this way than contracted development projects. Deadlines under conditions of uncertainty are a pretty hellacious source of stress for me, feels like a kind of roulette, and while agile in theory had the promise of making it better, the methodology turned out to be nitroglycerine.