> there is a study or set of studies which shows that, for software projects within a certain broad size range, a team size of 5-7 gets the project done fastest, and that larger teams not only take more man-hours for the same size project but more calendar days
I'd like to read those studies. Do you have a cite?
Re:The End of Agile
by dragonwriter on Friday August 23, 2019 @03:48PM
(#20781838)
That specific finding was from what appears to be the 1997 QSM study [0], though the description I am familiar with it from (Mike Cohn’s Succeeding in Agile: Software Development Using Scrum, 2010, describes it as covering projects in 2003-2005 (the author, organization, and number of projects in the analysis, and the one result chart from the study that is in the article on the web [1] match between the book and the 1997 one, though, but the chart showing time to complete by team size isn't shown in the article.)
[0] https://www.qsm.com/blog/2019/4-key-studies-team-size
[1] https://www.qsm.com/articles/team-size-can-be-key-successful...
That's not the core principle of the Agile Manifesto. In fact, nothing even vaguely like that is included in the Manifesto for Agile Software Development [0] or the Principles behind the Agile Manifesto. [1]
Now, to be fair, there is a study or set of studies which shows that, for software projects within a certain broad size range, a team size of 5-7 gets the project done fastest, and that larger teams not only take more man-hours for the same size project but more calendar days, and that study is broadly influential in setting team sizes in teams that claim to be practicing Agile or Lean development; that's not a, much less the, core principle of Agile, though, just a piece of empirical evidence that became available when Agile (at least the name, of perhaps not the actual philosophy) was becoming popular.
Agile has kind of the same problem as Marxism; the theory is, and the is quite critical in both cases, bottom up, but most of the practical implementations throw that out and are top-down.
With Marxism, this might seem like a bigger problem because it is every single implementation that claims the name has the problem, but in a sense it's a little easier to distinguish the problem in practice as being separate from Marxism itself because at least all the real world implementation point to a particular revision of the theory which contains the diversions from the original (Leninism). So at least you can point to Leninism and say it's the problem distinct from Marxism. While there are a few bottom-up Agile implementations where the teams really are self-organizing and empowered, the norm is top down implementation of something that at least superficially resembles Scrum, without any real control of process in the team, but there is no clearly diverging theory that unifies the top-down one; they don't claim to be practicing Agile-Leninism but instead plain, vanilla Agile, though their practices are in no way grounded in the Agile Manifesto or Principles, but instead the same canned-process management approach against which Agile was a reaction. So it's a little harder to distinguish based on what the implementors say is their philosophy, though it's still possible to distinguish the substance.
[0] https://agilemanifesto.org/
[1] https://agilemanifesto.org/principles.html