The headline doesn't really reflect the article, though after all its waffling before getting to the point I don't think any of its conclusions are all that revolutionary. It comes down to this: when developing software in a team[1], you have conflicting requirements. Your programmers/designers need to communicate effectively enough with each other[2] to keep them pulling in the same direction, but you want to optimise individual productivity. The optimal balance will depend on the project, team size and of course the individuals involved. It will even fluctuate wildly throughout the project. So really, the best thing you can aim for is to create an environment that's flexible enough to adjust to a balance that is close enough to the optimum of the day.
I'm disappointed anyone still believes any of these Methodologies with a capital M will fix their project. All the techniques mentioned should be part of the toolbox, but it's up to common sense to use them appropriately. There is no substitute for common sense.
Still, I was pleasantly surprised after my considerable initial trepidation about reading a programming article on TechCrunch.
[1] or probably doing anything else creative, but I can't speak from experience
[2] and, let's not forget, communicate with the actual users of the software
I'm disappointed anyone still believes any of these Methodologies with a capital M will fix their project. All the techniques mentioned should be part of the toolbox, but it's up to common sense to use them appropriately. There is no substitute for common sense.
Still, I was pleasantly surprised after my considerable initial trepidation about reading a programming article on TechCrunch.
[1] or probably doing anything else creative, but I can't speak from experience
[2] and, let's not forget, communicate with the actual users of the software