I currently work at a FAANG and we have a chaotic, low-touch approach that honestly seems to work pretty well. There are only two issues I see with it: it requi

I currently work at a FAANG and we have a chaotic, low-touch approach that honestly seems to work pretty well. There are only two issues I see with it: it requires a high degree of trust in the engineers from management, and it could be possible to skate by doing the bare minimum without it being noticed (it is noticed usually, it's just not publicly shamed in regular standups). This has the major benefit of allowing developers to manage priorities as things change/pop up/assumptions change, and gives them the latitude to take on complex tasks that aren't easily decomposed or estimated a priori. I think part of the issue is that Agile is meant to be a Process imposed from top down to improve productivity by X%, a way for management and a small army of backlog/task managers to say they are doing Something and having impact (or literally the only thing they actively do). Not only can it easily get in the way of that, it almost always fosters an environment of shaming and lack of trust, because it is too tempting for estimates to be taken too seriously or productivity/performance measured "objectively" by invoking the task-tracking system (in which case you incentivize only taking on very easy, very well understood tasks). It doesn't always devolve to that, but I think at many places if anybody Important up in the management chain starts thinking that way, it will inevitably trickle down. Thus any sufficiently large organization will corrupt Agile. Perhaps some companies need that level of accountability and visibility, even knowing and disliking the drawbacks, but not all of them. I am honestly not convinced that a rigid process is necessary at all. Yes it makes sense to have a system where you keep track of things that need to be done, but if there's a culture of trust, I don't think the system needs to be gamified or fetishized as much as it usually is.