UX in an agile process

About 50% of the work I do these days is Agile. While I like some aspects of the approach, I have to confess I am not a big fan. I think it has a lot of potential to smother vision and innovation, because its easy to take a couple of small steps in the wrong direction and find that the destination is a few miles adrift of the original goal. The iterative nature of the Agile process allows key elements to get accidentally dropped or forgotten, which can take the project in a subtly different direction. 

Given its “just enough” strategy, Agile also promotes short term goals ahead of long term thinking, so that you end up with what is referred to as “debt”, meaning a lot of rework needing to be done. Its usually referred to in a technical capacity, but I think there is a great build-up of shortcuts in all aspects of the development, particularly on the UX side. By not knowing what is coming, its impossible to make anything other than educated guesses about where the product is going. So every discipline in the team is likely to be confronted with rework as time goes on. 

My experience is that getting resource to repay an accumulation of “UX debt” is often impossible, unless there are pressing commercial issues - in which case they shoot right to the top of the backlog. So the product limps along, hobbled by an ever increasing technical and UX burdon. 

But, there are some great aspects of Agile, which should be celebrated and embraced. I love the great communication that comes from daily scrums and the innovation that results from working in mixed teams. From a UX perspective, the more the different disciplines collaborate, the better the outcomes will be.