I attended CHI 2010 week before last and it was interesting and insightful as usual. There were lots of great ideas, interaction paradigms and insightful research being presented. But one topic was not much addressed by official conference sessions, but was common in the hallway conversations: how to deal with agile software development.

I go to the big Agile conference every year, and when they talk about agile development they talk about how one week sprints are best, unless you do continuous integration, and really everybody should be doing Kanban by now.

At CHI, it didn’t sound quite like that. It was more like: “Our Sprint 0 is really more like bugfix.” Or, “Nobody really iterates. They just implement and go.” Or, “We’re really doing Scrummerfall”—a combination of SCRUM and waterfall—don’t ask.

It was a useful reminder that no matter how much everybody wants to say they’re using agile development, like any new process development teams are all over the map—and many aren’t really getting very close to the theoretically correct agile process at all.

The other realization I had from the various hallway conversations is that what’s missing in a lot of agile development these days is not a new problem at all—it’s the lack of sound user data to drive the process. This should be a no-brainer—agile development is based on the idea that you will iterate and evolve your system with its users. But then the development team tries to rush right into development with no up-front design—which means, no time for user research. And UX people are spread so thin that trying to get out to real users during the sprints is very hard.

And to make matters worse, a lot of teams don’t seem to be doing the other half of agile. Not only do they not work with their real users, but they don’t iterate either. They take a story, implement it, and then move on, with no time for rework or re-thinking if the implementation doesn’t meet their users’ needs.

If this sounds like your situation and you’re feeling frustrated, take heart—you have good reason to be frustrated. But there are solutions to these problems. I’ll be writing more about them over the next few months and I’ll talk about what you can do make your agile team more nimble.