Don’t say UCD is incompatible with agile
Consultancy is great, you get to see lots of different problems that different organisations and people have. You get to apply the learning’s built up through experience to help solve problems, and sometimes help organisations realise opportunities that they may not have realised possible.
I was recently working with a new client and sat through a presentation by an agile coach from a different consultancy on what agile is. It was great to hear a different slant on the agile proposition and how it delivers business benefit early and regularly. The presenter really honed in on human behaviour. She was suggesting that despite our best efforts and beliefs otherwise, human behaviour is fundamentally unpredictable. The best plans in the world are held hostage by human behaviour…
At the end of her presentation there were a number of great questions from folk more happy in the waterfall space. People who have seen agile and it’s like before – RAD, DSDM etc etc, “yeah, yeah, heard it all before. Agile’s just another passing fad. Then one of the HCI guys asked the question: “in what you have said, it sounds like you would have little time for doing low-fidelity or paper prototypes; a fundamental tool in the interaction designers arsenal of techniques to ensure usability (and acceptability) in design”.
To give her credit, the presenter explained that agile practices are by nature pragmatic and there may be instances where such prototypes may be valid, but in principle she suggested that they should be eschewed.
Something bothers me here. We are quite happy to “spike” technical problems, but possibly the most important part of any software implementation, the user interface, we are happy to let emerge according to the developers’ preference? For it to be refined following feedback from each showcase? What if we call the lo-fi prototype, the wireframes a “spike”. Does that make it acceptable to the agile zealots? What if rather than writing code, testing and refining it, we draw storyboards, test and refine them? Get the UI right quickly and cheaply before a line of (costly) code needs to be developed. It helps you to have a shared vision of how the application will be manifest to the customer. It helps you to show what they will be getting in an iteration, what the goal is for a release.
To say that user-centred design is incompatible with agile (which was certainly the impression the presenter left the UI team I was working with) is nonsense. Which reminds me. I’m supposed to be writing a paper to this effect.
I’m slightly baffled that someone would claim them to be incompatible. I’d always assumed that low-fi prototypes and the like (as opposed to expensive semi-functional but ultimately throwaway demo apps) were a core agile technique – all part of customer collaboration.
Well said. As a UCD practitioner who has thrown himself into the Agile Dev foray, I’ve definitely found that the Agile Methods that I’ve run into in practice thus far are as User Centered as one cares to make them. My only ongoing worry is that UCD (and even just plain ol’ Design) methods don’t necessarily have a set place in XP, Scrum, etc. Though, I guess it’s the same for other Dev processes…still, I’d like to see a little less emphasis on Customer satisfaction, instead putting more weight on User satisfaction. I think then we’ll see UCD+Agile start to act as a cohesive unit and as a standard practice.
[…] So, Marc says User Centered Design is compatible with Agile. I think I agree, but with a caveat or two. […]
A lot depends on the fidelity of the prototype. I’m more than happy to sketch wireframes on the whiteboard and do paper prototyping when it helps get the job done.
However I’ve seen people take weeks to produce lovely bound wireframe documents, where I would already be working on the second iteration.
Prototypes are great – but I feel some people think producing them is their reason for existing. It isn’t. Their job is to help build software.
I think we can move to code a lot sooner than many folk in the UCD profession do. Changing the UI is a lot cheaper than it used to be – and working code gets me more effective feedback more quickly in certain areas.