I will try to remember him for his far too relatable Dilbert comics about corporate office life, and not his, uhm, later work.
One of my favorite strips was Dilbert in the 90s only being given a 286 PC for 3D rendering work, with the boss saying "besides, how often will you do 3D rendering in your career?"
It refers to "being at work", not "actively heads-down working on something".
If you come in at 9am, do work, have lunch, make coffee, work more, suffer meetings, work, chat at the water cooler, work again, and leave at 5pm, you're working 9-5.
"Agile" means different things to different people.
I would argue it's agile if you release early&often to continuously incorporate feedback, even if you don't play Planning Poker in Scrum Sprint Planning every two weeks.
I feel really bad for the service reps. If you hate doing this every time you cancel, imagine how they feel having to do this all day every day, always with the threat of being fired from their minimum wage job if they're accidentally too helpful.
Did it need all 20 seconds? If so, the docs were definitely wrong and useless and I see your point.
My suspicion is that it works fine with 5 actual clock seconds (instead of "a short while"), and that they just said 20 so that even the most chronologically challenged would end up holding it for at least 5.
It's fair to assume that the docs are simply wrong/outdated about the specific duration and color when it works, but I would start to question those assumptions when it doesn't.
Pedantically proving instructions wrong (e.g. with a stopwatch and colorimeter) is a great way to submit a useful bug report with solid steps to reproduce, and a lot of the time it ends up solving the problem as well.
This has also been my experience writing documentation.
You write "hold button for 5 seconds until light is blue", and someone will hold the button for 3 seconds until it turns white and ask why it's not working.