In 1997 I worked for a small cell phone provider. One day my boss rounded up all the devs that weren't maintaining the billing system, and told us to write a customer care and account activation system.
That's all he told us.
We asked for requirements and were told to figure it out. So we did. We delivered a first version in three months, and a final product in 8.
Afterwards he told us about a paper he'd found after reading Wicked Problems, Righteous Solutions.
That paper describes what SCRUM was before it got butchered into what it is today.
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.
If you're thinking that all of this sounds a bit like programmer anarchy without the stand-ups, you'd be right.
It kills me that almost 30 years after this was proven to work, we're still trying to come up with new ways to differentiate existing processes.
> 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.
I used to work in scientific research, and the concept there is exactly the same. And it works, I can confirm that!
> It kills me that almost 30 years after this was proven to work, we're still trying to come up with new ways to differentiate existing processes.
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!