Software development has some fundamental challenges that have been faced since the start, and always will. Understanding them matters. Here are some of the big ones.
1. Developers need to communicate with each other. A lot. This takes time. The amount of time goes up non-linearly with the size of the team. (The Mythical Man-Month claims a scaling law of n^2.)
2. Adding process + documentation of various kinds can turn that from unbounded time spent speaking to a large but bounded written effort.
3. Nobody is good at predicting schedules.
4. Good news travels, bad news doesn't (until the last moment).
The traditional solution was to solve #1 with #2, put a lot of effort into schedules for #3, and get blindsided over and over again by #4. The average result was that the average delivered software project took over 2x what was estimated, cost over 2x, and was delivered with under half the promised features. But, no matter how delayed, usually didn't start slipping the promised deadline until about 2 weeks before the first official release deadline. And these were the success stories, since most software projects never really got delivered.
What Agile opened up was the perspective that there were other approaches possible. For example we can solve #1 by having small teams, which makes #2 unnecessary, solve #3 by making projects small enough to not need good prediction, which creates a feedback loop to avoid #4. And that is not the only valid tradeoff.
But this is not a one size fits all. Real world data shows that a team hits peak throughput at 5-8 people, declines, and doesn't get back to the same overall throughput until 20+. (After which it is almost linear, but with much lower individual productivity.) The teams as drawn on the org chart don't matter. The teams as they actually interact, do.
If you understand your options, and understand the tradeoffs, you can figure out how to customize the right solution to the people/organization. If you don't understand the tradeoffs, the best that you can do is blindly copy what worked somewhere else and pray that you got it right. And if it turns out that you didn't, develop superstitions about what you should have done instead.
1. Developers need to communicate with each other. A lot. This takes time. The amount of time goes up non-linearly with the size of the team. (The Mythical Man-Month claims a scaling law of n^2.)
2. Adding process + documentation of various kinds can turn that from unbounded time spent speaking to a large but bounded written effort.
3. Nobody is good at predicting schedules.
4. Good news travels, bad news doesn't (until the last moment).
The traditional solution was to solve #1 with #2, put a lot of effort into schedules for #3, and get blindsided over and over again by #4. The average result was that the average delivered software project took over 2x what was estimated, cost over 2x, and was delivered with under half the promised features. But, no matter how delayed, usually didn't start slipping the promised deadline until about 2 weeks before the first official release deadline. And these were the success stories, since most software projects never really got delivered.
What Agile opened up was the perspective that there were other approaches possible. For example we can solve #1 by having small teams, which makes #2 unnecessary, solve #3 by making projects small enough to not need good prediction, which creates a feedback loop to avoid #4. And that is not the only valid tradeoff.
But this is not a one size fits all. Real world data shows that a team hits peak throughput at 5-8 people, declines, and doesn't get back to the same overall throughput until 20+. (After which it is almost linear, but with much lower individual productivity.) The teams as drawn on the org chart don't matter. The teams as they actually interact, do.
If you understand your options, and understand the tradeoffs, you can figure out how to customize the right solution to the people/organization. If you don't understand the tradeoffs, the best that you can do is blindly copy what worked somewhere else and pray that you got it right. And if it turns out that you didn't, develop superstitions about what you should have done instead.