But, back to the original point: I suspect (based on my experience) that the ideal Agile team size is 4-5 devs with 2-3 QA. I also suspect that success is really governed by the quality of your team. The Agile process can't turn bad programmers into good programmers, but it does remove all of that waterfall crap so that good programmers can get on with being good programmers.
The problem is, who is the judge of what makes a "good programmer"? There isn't an objective measure of what makes a good programmer and we end up in "religious" debates all the time over our ideas about software development. I obviously have my beliefs- but the PM doesn't know who to listen to, and our two TAs are divorced enough from the actual coding they don't always have a solid handle on what is causing issues.
The thing about waterfall is that a LOT of effort gets put into controlling weaknesses. In Agile, you have to be flexible to react to weaknesses and deal with them appropriately. Thus far we have reacted to every issue that has come up by putting more and more controls around the process, rather than expecting people to do better. Every day we approach waterfall, but without having put effort into a big upfront design (welcome to "Code Like Hell Programming").
Previous Topic
Index
