In the best scenario the developers are also active users of the software they produce. Then a design flaw or an error that affects the users will also affect the developers and will (hopefully) motivate the latter to correct it.

▲

roguecoder 4 hours ago | parent [-]

XP putting a customer on the team was the best thing in the methodology. Replacing those with business representatives is one of Scrum's original sins.

	▲	bitwize an hour ago \| parent [-]
		> XP putting a customer on the team was the best thing in the methodology. Recently my boss said to me: "Customers want something that WORKS. If you deliver something, and it doesn't work, what's the customer going to think?" The huge drawback to putting a customer on the team is that the customer probably doesn't want to know, let alone be involved with, how the sausage is made. They want a turnkey solution unveiled to them on the delivery date, all ready to go, with no effort on their part. Generally what you want is a customer proxy in that role, who knows or can articulate what the customer needs better than the customer themselves can. Steve Jobs was a fantastic example of someone who filled this role.