Welcome Changing Requirements

Here's another post about one of the 12 agile principles. Enjoy!

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Does that make anybody else cringe?

This is clearly for our customer's benefit. They're listed explicitly in the second sentence and implicitly in the first. It's a nice goal, but really, what's the deal with changing the requirements so late in the game? How is that supposed to work, really? How do we do that?

Self-Organizing Teams

​The best architectures, requirements, and designs emerge from self-organizing teams.​

This is one of those 12 Principles that raised doubts in my mind when I first read it. Most of the other principles seem patently valid. This one, though, begs a deeper dive. I'll give you my definitions and you're welcome to point out the flaws:

• Architecture - the structure of the underlying components of a system 
• Requirement - the description of functionality of a system 
• Design - the user's experience of a system 
• Self-Organizing Team - the set of people who decide to build a system

There's another word in this principle that give me the willies: Best. What does it mean to have the "best" architecture, the "best" requirement, or the "best" design? How do you know you have such a thing? How can we know that such a thing even exists?