[emmelaich]

Increasing parallelism and optimising bottlenecks is the way to performance.

Put this way, be careful how much redundancy you add; as it is likely to increase complexity and reduce parallelism.

As an aside this is one of the major goals of Agile. Having smaller tasks increases the potential for parallelism. As well as the more obvious ability to change direction.

Lastly, regarding applicability of distributed systems thinking to people, see https://en.wikipedia.org/wiki/Neil_J._Gunther#Universal_Law_...

which is applicable to both imho.

[Spivak]

Agile's main innovation is organizing projects as a (mostly) always shippable series of iterations (i.e. "what do you want next"). But the actual "how" with cards, points, sprints, boards, workstreams leaves a lot to be desired if parallelism is the goal. Communication costs are really high when every one is micro-siloed, hand-offs, which are serial, are costly and involve a lot of relearning the same context, and there is more integration work which is also serial.

I think it's possible to have good parallelism within Agile but I don't think it's the Agile that makes it happen.