[SketchySeaBeast]

I noticed that as well. That'll be pushed back against, and the leadership is going to decided that they must respond to SOME issues to appear responsive, and let's be honest, it's going to have to happen regardless of project ideology. There'll be some silly rule put in place that only priority "X" issues get looked at mid sprint, and suddenly every issue is going to be priority "X", and now someone gets to spend the time they would have spent fixing the issue going "Ok, is this really a priority 'X' issue?" and fighting with whoever raised it.

[beat]

Decent iterations cannot be done without immediate management playing defense, period. As long as anyone is allowed to interrupt the iteration, then iterations are just going through the motions and won't solve any actual problems - because the problem is a lack of control.

The engineer's response to unplanned work should be "Go talk to my manager", and the manager's response must be "Wait til next iteration". If the team can't defend its own boundaries, it's hosed, period.

[oasisbob]

The problem I've seen with this approach is when issues cross org boundaries and have externalities.

Say the event subsystem is shared or is under control of another group. They do maintenance, and the app doesn't restart and stays down because it had bad retry logic and won't retry after the connection is closed. Stupid bug, easy fix.

You're now hobbling that other group from doing their work, and depending on the discipline of the app team to fix it, and that bug may stay in the backlog a long time. Meanwhile, it's going to come up in a handful of meetings with a handful of people as it gets estimated, prioritized, assigned, touched again and again...

Coming to someone after diagnosing and helping them recover from a problem, only to be told "we're busy, come back three weeks from now" sucks.

[SketchySeaBeast]

I've never know immediate management to understand the business nor the system as well as the ones with boots on the ground. I've yet to see a situation where the manager doesn't end up coming out of his office and asking someone on the team "so, what's this mean?"

[beat]

It's not management's job to understand details of the code (and it's probably a problem if they do). And it's not their problem to understand the business perfectly (and it's probably a problem if they do). It's their job to facilitate getting work done. That means helping their developers work as effectively as possible. And in most cases, that means keeping customers from end-running around whatever work management process is in place. If you're doing agile, the manager's job is to protect the iteration, and shield the developers from politics and pressure so they can work well.

I often use a bread-baking analogy here. Making software is like baking bread. This iteration, we get some flour, water, yeast, and salt, mix them together, knead, rise, and bake. And if someone comes in five minutes before baking is done and says "Can't you just add some raisins now? It's just a handful of raisins, it's not much work". No. It means starting over.