I think an important point is that anything higher up the chain rarely gets attention. Every agile training I have attended has emphasized that agile implementation should transform the whole organization. In practice I have never seen this happen so the devs work in a sort of agile environment within a non-agile environment.
Implementations bear no resemblance to Agile Manifesto, XP or even Lean. "Scaling it up" seems to build only on processes and rituals, which always bogs down into beuracrazy and politics. Lastly, management seem hellbent on restricting the ideology to Development, forcing "Agile" over siloed teams rather than practicing and understanding agility themselves. =Fail on all accounts for 15-20 years.
This is well observed and understood, the motives behind as well, which doesn't ever seem to change.
Agile bumps up against misaligned incentives and conways law so fast. It doesnt work for anything other than executing on a predefined problem that needs to be split up. After that you end up needing to use so many “non agile” techniques to force it to work, and then youre in a purity contest.
Isn't it rather the case that non-agile is how you deal with a predefined problem? Agile (incremental and iterative development, as opposed to big design up front, big bang delivery) is how you deal with a problem where the requirements are unknown or changing.
> Since communication overhead increases proportionally the square of the number of people on the team—a fact illuminated by Brooks in the 1970s—what you actually want is as little collaboration as you can get away with.
It's an important point that warrants repeating. It comes from an observation that if there are N people communicating directly with each other, every one has to communicate with N-1 other people, which leads to N*(N-1)/2 simultaneously open bidirectional communication channels, which is O(N^2).
I think this point plays a crucial role in why hierarchies form, both in teams/companies and societies. A hierarchy is what lets you turn an O(N^2) relationship into O(N) one, at the expense of creating O(log n) hops.
I think that the root cause for the complaints is that the Project Management Institute (PMI) has rolled out Agile as a new way to ask developers for status every day, rather than as discovery tool. PMI comes by it honestly as their bread and butter was always handling tasks that have a well-known duration, such as organizing folding textiles to be loaded on a truck.
Creation of new software isn't compatible with that approach, and I think the author calls the reason out clearly and succinctly:
>The problem is that you and/or your team can only eliminate a fixed-ish number of bits of entropy per unit time, and at the outset you don’t know how many bits there are in the problem to eliminate.
This is a really wonderful piece, written with a clear voice, style, and appreciation for history. Pieces like this make me glad to read HN, if only for a straightforward way of finding pieces like it somewhat regularly.
9 comments
[ 2.6 ms ] story [ 22.7 ms ] threadThis is well observed and understood, the motives behind as well, which doesn't ever seem to change.
It's an important point that warrants repeating. It comes from an observation that if there are N people communicating directly with each other, every one has to communicate with N-1 other people, which leads to N*(N-1)/2 simultaneously open bidirectional communication channels, which is O(N^2).
I think this point plays a crucial role in why hierarchies form, both in teams/companies and societies. A hierarchy is what lets you turn an O(N^2) relationship into O(N) one, at the expense of creating O(log n) hops.
Creation of new software isn't compatible with that approach, and I think the author calls the reason out clearly and succinctly:
>The problem is that you and/or your team can only eliminate a fixed-ish number of bits of entropy per unit time, and at the outset you don’t know how many bits there are in the problem to eliminate.