For me, most of agile thinking derives from two fundamental realizations.

First, we must be realistic about our inability to predict the future, and therefore shorten and strengthen feedback cycles. We strengthen feedback by putting working software in the hands of real people, and by test-driving the process of writing code at multiple scales. We shorten cycles by delivering smaller changes more often. We stop trying to be blindly and perfectly proactive, and instead reconceive large projects as a series of rapid, highly effective reactions.

Second, we must stop thinking about building software as an activity centered around technology (machines, tools, processes), and instead appreciate that humanity and human communication lie at the heart of software making. Software is made by people for people, and those people better communicate and work well together if they have any hope of succeeding other than by dumb luck.

I’ve gotten tremendous value out of the principles and practices I’ve learned from other members of the agile community. At the places I’ve worked (generally small teams on long-term projects), we’ve applied them to great effect on the quality, malleability and maintainability of our code, our ability to release early and often, and the quality and “at-home-ness” of my team members (making our practices suit the people we are, etc.). It also bears pointing out that profound thinking continues to come out of the agile community (it never ceases to amaze me how deep the practice of TDD is), so it’s well worth continuing to pay attention.

At least as I’ve practiced agile, however, communication with those who use the software has always been wanting. The “on-site customer” has never really fully worked for me, either because it wasn’t feasible (in a product company) or because simply asking someone what they want isn’t the best way to make software design choices. I think these issues are not uncommon. And this failure goes to the heart of what agile is: We’re failing to communicate effectively with the people who use our software, and therefore failing to get all the right feedback.

There are people out there who’ve seen this for years (Jeff Patton and I’m sure many others), but I didn’t really get the message until I attended the first Agile UX/Balanced Team retreat early this year. I learned that the agile and UX communities, largely separately and in parallel, have been developing transformative ideas that, with a little increased awareness and mutual appreciation, go so much better together than they do apart.

From this agilist’s perspective, UX helps me understand how to connect with the people who might and do use my software, and to turn what we learn into a rich shared context across my team. It has also helped me realize that because my teams have always outsourced (or worse ignored) design activities, my teams have been out of balance (“on-site designer”, anyone?). I suspect similar ahas await UXers coming to agile.