In programming we frequently use principle of atomicity, trying to implement things as small as possible. SRP principle in SOLID forces us to make responsibility atomic. Micro-services also reflect this idea. Agile methods use the same approach for changes, instead of one huge "change" in waterfall workflow, we split into smaller changes from a couple of weeks in SCRUM to several daily releases in Kanban, etc.

This approach has many benefits. For example, one of them I temporarily called "locking". Changes to the smaller systems cause less locking than to a huge one. For example, deployment of micro-service cause less availability problems than deployment of the huge monolithic application. Unexpected requirement for an agile workflow is much easier to integrate than for waterfall.

Another one is "distribution". If you split system into N subsystems then you can employ N workers to handle them. For distributed computing systems this is obvious, but such principle also makes agile project management highly collaborative.

I feel me like reinventing a wheel and wonder if this idea is already described somewhere with all pros and cons.