will_sargent
If a project that uses Agile fails, the participants have no incentive to blame each other.
If a project that uses Waterfall fails, the participants have an incentive to blame each other.
Because Waterfall in the failure case gives people an incentive to blame each other, it's a poorer methodology than Agile.
If I haven't confused your argument, then the weakness is that you have not shown that Agile is a methodology in which people have no incentive (or ability) to blame each other if the project fails.
I'm sorry, but measured against the number of times I've heard the phrase "Doing Agile Wrong", this sound disingenuous.
I'm the OP.
What I'm describing is my experience Pair Programming in one organization, and why it didn't work for me. To tell the story, I needed to provide the context and the background to say why it didn't work for me. They're distinct issues, but the only way we could relate to those issues and work through them was through the lens of pair programming.
Keep in mind that I'm not trying to say that Pair Programming is a flawed practice in principle, or even that their approach was flawed _in practice_ for the company -- there are other metrics besides code quality that a startup needs to consider if it's going to survive, and sometimes "good enough" code is good enough.
I'm well aware that pair programming works very well for some people, and that my experience may not be typical. However, just because my experience wasn't typical doesn't mean it didn't happen.