[phuff]

I know this has been discussed and rediscussed but the notion of thinking about human organization blackboxes trading work with each other the same way we think about how distributed systems blackboxes trade work and communication with each other I think is a huge insight for helping software engineers understand the complexity of human organizations.

You want to avoid single points of failure, optimize bottlenecks, build in redundancy in similar ways etc. Etc. It's a great insight.

[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.