I came across an interview - Similarities Between Interaction Designers and Agile Programmers - he gave at Agile 2008 and once again I was captivated. If you like Alan you'll love this interview. If you don't know of Alan you're in for a treat.
I like Alan's focus on quality and the need to define the problem before creating the solution. Some quotes that stood out for me:
The fundamental goals of Agile programming are to let programmers who are knowledge workers get to the core of their motivation and the core motivation of all knowledge workers is to do good work. And I think there are a lot of people around the fringes of the Agile movement who don't get that yet and who think that Agile is about productivity, and it is not about productivity, I think that productivity is a byproduct, but if you set that up as your goal you will fail
[agile's core is] introspection, it's doing it and then make sure we did it right, and then pay close attention to what parts of it we didn't do right, and bringing some questioning analysis to that so to increase the proportion of rightness in what you do in the future. So the essence of Agile is reflective, it's transformative and it's on going, and it's self correcting.
The economics of software are qualitatively different than the economics of industry...In software there is no on-going cost, there is no manufacturing cost there is no material costs, so driving cost down just reduces the desirability of the product...What you want to do is create your number one goal, to say what do we have to do to elevate the quality, the desirability, of the end product. And when you worry about costs, you hurt that. And one of the great things that I see in Agile is an understanding that says "Hey mister businessman, stop worrying about the costs and start worrying about the quality"...don't start thinking about delivery times and don't start thinking about costs reduction and don't start thinking about ROI, think about the quality because that's why we are all playing this game.
And one of the great weaknesses in the process is that there is nobody figuring out what the problem is and what the solution is. There is lots of good people figuring out how to build the solution, and there is lots of people figuring out actually building the solution....it is considered normal in the software business, that building the solution to the wrong problem is normal, and you will go on from there.