I hear a lot about scrum these days, not the least of which because WPF/E uses scrum. Personally, I dislike any capital M Methodology, and there's something about the scrum vocabulary that really irks me. But I'll grudgingly admit, it works. There's several useful ideas in scrum and agile methodologies, but I think by far the most important is this: build the simplest thing that might possibly work -- then give it to the customer and iterate. If it's too simple, you can always make it more complicated later. It's rarely as hard to add functionality later as we think it is -- nor do we ever understand the customer's needs as well as we think we do.

One of the scrum criticisms I've heard is that it can't work for building platforms. That agility means breaking changes, and breaking changes are catastrophic to your customers. That's a legitimate concern, breaking changes really are costly, but I think it's manageable provided you aren't too religious about scrum. I think when building a widely used API, you need to be very cautious about exposing more surface area than you are prepared to support. (For example, not making methods virtual unless you really mean it) And of course, build the simplest thing that might possibly work. If the simplest thing doesn't fit in a milestone ("sprint"), build it anyway -- there's no point in building something simpler if you know it won't work. Nor should you let scrum be an excuse not to do requirements homework -- the better you understand what the customer needs, the faster you can build it. Just be very humble about how well you can predict what will be needed, and when in doubt, start simple and iterate.