There are a lot of issues layered in here, a bunch of complexity that might not be obvious just by scanning the article. Does a good team deliver solid, qualit

There are a lot of issues layered in here, a bunch of complexity that might not be obvious just by scanning the article. Does a good team deliver solid, quality code? What if it's code the user doesn't want? Conversely, what if the team excels at delivering what the user wants, and they love it, but the code is so buggy that it only works 50% of the time? Would that be better than a solid app the user hates? (Probably yes) Should a team working inside a large company deliver faster than the organization is able to accept change? Just what is a good project, anyway? One in which we all had a good time and thought we did a great job? Or one in which the person paying us thought we were awesome? No matter the criteria, everybody seems to agree that having good people is something like 70-80% of the secret. The big debate is what goes into that other 20-30% ADD: An interesting thought experiment to play here is to posit that the team sucks -- wrong guys, wrong personalities, whatever. In that case, what would you want to happen? The answer to that should be an important part of whatever you want your process to be. Explicitly define your failure mode. (Because failure is still more often the norm than success in software development)