Hacker News new | comments | show | ask | jobs | submit login

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[1] after reading Wicked Problems, Righteous Solutions[2].

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.

EDIT: Improved clarity (I hope).

[1] http://hbr.org/product/new-new-product-development-game/an/8...

[2] http://www.amazon.com/dp/013590126X/




> 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!


Very few things are as effective as telling someone to get something done and getting out of their way.


Alistair Cockburn (of the original Agile Manifesto) defined his Agile methodology "crystal clear" in similar terms - good people, conference room, white boards, leave them alone.

It's my favourite Agile method now :-)


Buffett calls it management by abdication.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: