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"? [...]The PM doesn't know who to listen to
The PM should listen to the person/people they trust the most. Do they know you well? Do they know your track record as a high-performance team? Did they hire the contractors to change they way the company works?
Track the bugs you're fixing, and do an analysis of where they're coming from; who's introducing them, and at what stage (i.e. implementation error, should have been caught by simple unit tests, API design problem, misunderstood requirements, etc). Then you can take that to your PM, and say, "look... we're spending 30% (or whatever) of our time fixing problems they're creating, because of X, Y, and Z. If they did A, B, and C the way we've been asking them to for the last year, most, if not all of these bugs could have been avoided, and we would have been able to ship earlier/add additional features/etc."
Previous Topic
Index
