[p1necone]

In my experience the more fine grained an organizations issue tracking/planning is the more this is a problem vs a reasonable process.

If you have to convince someone of all of those things in order to build some reasonably large thing over the space of a few weeks, that's probably reasonable.

If you have to convince someone of all of those things in order to allocate a few hours to fixing some tech debt or minor bug then your codebase is going to slowly deteriorate until the same someone is asking you why there's so many bugs and everything takes so long to develop.

[elevatedastalt]

Usually most engineers have some slack time and can pick things up to fix. The problem is not in them doing that. The issues arrises in one of two things—

[1] They either use the fact that they are fixing that thing as an excuse to not work on or deliver on time a different, more important task. If that happens, obvious questions about prioritization occur.

[2] They want a substantial amount of credit or recognition for doing it. Usually such fixes don't receive exec attention (since execs are tracking more important projects) and so don't get the same due as a properly tracked project does.

[wbl]

3: the fix is easy but the integration testing and deployment cannot happen without allocated time.

[titusjohnson]

In my experience this aspect is chronically underestimated by devs. The change needs testing. Change Management might need to create artifacts. Help articles might need updating. Certain clients may need a heads-up. All the PMs need to be briefed (this change is outside of their roadmap so it'll be a fun surprise).

As an org grows the piece of the Effort Pie that is Development gets smaller and smaller. It's not that development gets easier, it's that every other part of the process grows in size and importance faster than the Development piece grows.

It takes about an hour of developer time to incidentally produce 20 hours of work elsewhere in the company.