There’s a secret lie lurking behind agile methods. ‘Agile’ suggests fast. At Comcast, we’re using a scrum process that throws around terms like “team velocity”. And the agile literature does promise better, faster. It’s no wonder that when organizations hear this, all they hear is faster.
Of course, the secret lie is that agile isn’t necessarily faster. It’s driving tenets are to help people stay happy and create better software. The namesake agility is meant to allow teams to change product direction every few weeks instead of every six months.
How do you make these kinds of agile changes? You test: Build, push, evaluate, tweak (rebuild).
Unfortunately, the iteration cycle, “agile”, and phrases like “team velocity” were confused with “fast”. The biggest problem with lots of user experience methods is that they’re not necessarily fast. They’re not necessarily slow, but they do take time.
At Comcast, even though user experience work is seen as valuable and important, its also seen as a slow point in the process.
How do you handle this? You have six options.
1. Synchronize UX with development
My previous post on parallel workstreams touches on this. You run a UX sprint ahead of the development sprint. You figure out what dev will work on next sprint, and you work on that stuff this sprint.
In the parallel workstreams post, I go over some of the problems and realities you see with this approach: parallel workstreams, more UX than fits in a dev sprint, etc. (Check out that post for more detail.)
Continue reading this article at: Agile + UX: six strategies for more agile user experience (Austin Govella at Thinking and Making).