When Agile means nothing
Recently I had what I believe is a relatively common experience in the UX field right now.
I was invited to assist on a website design project, for a well-known organisation, via an agency. The website requirements were already known and agreed to, the project timelines were tight but achievable, and everything was set to roll.
When I asked what the process was, I was told it was an agile project. Fine, I thought, I’ve delivered on plenty of these. “So,” I asked, “what’s the approach? How are you integrating UX into the sprints?”
And that’s where it started to fall apart.
The answer to my question was “Well, we just want you to bang up the wireframes as we go”. Hmm.
At this point, I asked what the end customer had been sold – in terms of the UX process. The agency explained (a little less than patiently) that they had sold what they always sell – usability built-in, a design built around the user. I asked them how, in that case, they were going to deliver on this – since it didn’t look as if any user research had been run, and there was no plan to include any form of testing in their sprints. Amidst looks of mixed confusion and frustration at my inability to understand such a simple concept, I was told “This is an agile project – we don’t need to follow the waterfall UX steps.”
The agile methodology is a good one, when it suits your needs. That won’t always be the case but when it does, the user can still easily be at the center of everything you do. There are extremely simple ways to ensure that research, testing and design all sit together both across and within the sprints.
Agile doesn’t mean doing nothing at all. I’ve heard from some others in the industry that they’ve encountered the same thing, companies where agile is an excuse to do nothing but ‘just build it’, in chunks. Agile means good – but cut out the valid steps in any design process, and all you have left is a whole lot of nothing.