The methodologies don't, "suck," and the author points out in eir conclusion that not having any methodology is bad.
It's the organization part that's important. Methodologies will work differently depending on the make up of the team. The important part is discussing what works and eliminating what doesn't. Only then can you flush out the gremlins of the mind and focus on the work.
That being said -- too much methodology is a gremlin of another kind. There needs to be enough process and practice to ensure everyone understands what needs to be done and how to consistently go about it. My favorite motivator is responsibility. Let the team members in the trenches make the decisions and make them own the consequences of their decisions. Winning feels so much better that way compared to being led by a dogmatic agile-XP-scrum-master.
I think (and have argued: http://xrl.us/bmeqcm) that the problem with most development teams - Agile or not - is that the people who are on point to make the deadlines (the Project Manager and/or Product Owner) usually don't have the agency to increase resources or move deadlines - they normally just have the ability to bully programmers and decrease software quality (pressure on tests and documentation)
Let me just say this flat out: if the product manager can't change scope and deadlines, then they are not doing anything I recognize as Agile. Fixed scope/fixed date approaches are the exact opposite of what every Agile pioneer had in mind.
> Let the team members in the trenches make the decisions and make them own the consequences of their decisions.
This! And this:
Maybe itβs an extension of the deeply held view that from an economic viewpoint, it would be ideal if people were interchangeable.
People are unique, each person has her own talent: you can profit from it and get a nice product, or you can try and annihilate it into a strict methodology and get a sloppy result - but you'll have obtained it with your favourite methodology!
It's the organization part that's important. Methodologies will work differently depending on the make up of the team. The important part is discussing what works and eliminating what doesn't. Only then can you flush out the gremlins of the mind and focus on the work.
That being said -- too much methodology is a gremlin of another kind. There needs to be enough process and practice to ensure everyone understands what needs to be done and how to consistently go about it. My favorite motivator is responsibility. Let the team members in the trenches make the decisions and make them own the consequences of their decisions. Winning feels so much better that way compared to being led by a dogmatic agile-XP-scrum-master.