Just read up on the spotify model, which sounds really great, and I don’t doubt that that organization style, when achieved, works well. I’d also separate agile as deployed in organizations from the ideal practice, which assumes longer timelines and more trust than (at least my experience) suggests is common. I think “accountability” runs in more than one direction, and this is a big part of where I differ.
The tension between external demands and internal standards isn’t even necessarily unhealthy; I’ve worked in places where I thought somebody else was a stick in the mud, where my team was the stick in the mud, and “not saying the board’s going to fire the CEO unless we ship on Wednesday, but …”. Agile as taught by trainers doesn’t address these situations well.
Agile teams often start from aspirational definition of done goals and let them go as a whole (the good and the bad) because agile doesn’t have a great way of giving them context. At the same time, organizations have very poor score keeping overall, and often make unnecessary demands that seem prudent or reasonable at the time in the absence of information. Teams can get caught up in their own KPIs and forget that others are depending on them for “the normal stuff” too.
Having a shame counter that runs both up and down the org lets us see how well we’re serving others and forgive ourselves when there are demands. Letting definition of done be a set of tools we go to when this service is out of balance makes it indispensable. Conceiving it as a separate part makes the inevitable decision not to dot every aspirational ‘i’ and cross every ‘t’ shameful. Hanging it on the wall in the face of strong counter-forces makes this effect worse.