There's a Hacker News thread today pointing to a blog posting on Programmer Anarchy which itself points to presentation on the topic. It's fairly interesting. The basic idea is that the best way to get a job well done out of a group of developers is to give them a task, give them a customer and leave them alone. Agile stripped down to the bare essentials.
I tend to think this is (ought to be) fairly obvious stuff. Motivated people will collaborate effectively if they build the shared language, understanding and goals required to get moving. Once started on the right foot, they will move.
There's a comment on the thread containing this:
In 1986, SCRUM consisted of choosing an elite team of experts, throwing them into a room, and telling them to solve a problem with seemingly impossible goals. This unsettles them somewhat, but you persevere. You tell the team how they do it is their business. Your business is to support them by providing all the resources they need. Management is decidedly hands-off, so you leave them alone but give advice when asked. After a while magic happens, the team self-organises, and a product starts taking shape. Soon after the project starts a leader naturally emerges. As the project progresses, leaders change, because the initial leader may not have the expertise required in later stages of the project.
with this crucial follow up:
The problem is, in 1986 you talked about experts. What people have been trying to do lately, is to apply whatever methodology to average (or sub-average) developers and expect that the methodology itself increase substantially their productivity and the quality of their work.
But it doesn't work, simply because it cannot work. Buying a book on Agile/SCRUM/whatever is much cheaper than investing on the competency your team, and you simply get what you paid for!
Methodology can never make up for competence much like a requirements document can never make up for engaging in the real context of the customer or problem space.