My implementations are for a specific customer and I don’t have to worry about that type of scale where a mistake or miscommunication in requirements can be costly and affect hundreds of customers.
I have made mistakes as a contributor to a popular company sponsored open source project. Even that caused headaches beyond the scale I was use to dealing with.
When I started in AWS, I watched customers implement hack solutions for themselves because it would take our team too long to deliver a proper solution (so hard to give specifics on HN :) ). That was the hardest thing for me to handle. The mindset is what works best over the next N years, not what works best for a set of customers right now.
Honestly that is the right mindset. Early adopters know they are early adopters and will have to work around problems.
I think the take away from this conversation, for anyone still following, is that a lot of developers (like myself) want to move really really fast. AWS has processes in place to prevent this movement from breaking customers. While it is so annoying for me, it really is a win for customers.
In this case I'm talking about the tasks in each sprint. I think 1 day of planning per sprint is a lot. We are supposed to be agile. If we missed a task, swap it with another. If something isn't actually important, bring in something new. We end up doing this anyway... so why all the upfront planning each sprint?
Related back to the above comment, (my opinion) people really love to establish rules and processes and are not able to handle ambiguity. I spend a lot of time (remember the 4 hours a week) arguing whether a story is a mouse or a hedgehog.
IMHO it's splitting hairs, let's just do the work and we estimated a little wrong it just isn't that important.