Agile Usability

Agile Software Development has the effect of constraining the amount of design detail discussed to what is critical to plan the current release or iteration, or to design the current feature being built.  Agile development relies on verbal communication and tacit knowledge built inside the development team.  For UCD/usability techniques to be best applied they must be changed to be more collaborative – to improve increases in tacit knowledge inside the team; they must be changed to limit the amount of detail they produce to be appropriate to the needs of the current work ongoing in the agile development lifecycle.

Challenges and Strategies for Using User-Centered Design and Usability Techniques in Agile Development - Jeff Patton - June 2005

Usability professionals cannot sit on the sidelines and wait for the suits and the geeks to fight it out. They must get involved and ensure that the methodology adopted allows for User Centered Design practices to flourish and give the software development process the human aspect that is needed to create great software.

You cannot sit back and complain that the development process doesn't allow usability testing results to be used to improve the software because the geeks say it's too late to change the design.

The Software Engineering War : What does it mean for Usabilty? - Chris McEvoy - February 2006

The more I examine this issue, the more I think that it is we, the HCI community, who are wrong. This includes me, for I have long championed the “study first, design second” approach. Well, I now suggest that for many projects the order is design, then study.

Let’s face it: once a project is announced, it is too late to study what it should be – that’s what the announcement was about. If you want to do creative study, you have to do it before the launching of the project. You have to be on the team that decides what projects to do in the first place – which means you have to be part of the management team. (HCI bug one: not enough HCIers are executives.)

Most projects are enhancements of already existing projects. Why do we have to start studying the users all over again? Haven’t we already learned a lot about them? Shouldn’t we be studying them all throughout the adoption period? Once a project starts, it is too late. Think about it.

But note too this contradiction: All of us usability theorists have long argued for iterative design, trying to get rid of the lengthy, inflexible linear project schedules that stymie flexibility and change, that slows up projects. Instead, we have championed iterative design, with frequent, rapid prototyping and frequent, rapid test.

But wait a minute, our continual plea for up-front user studies, field observations, and the discovery of true user needs are a step backwards: they are a linear, inflexible process inserted prior to the design and coding stages. We are advocating a waterfall method for us, even as we deny it for others. Yes, folks. By saying we need time to do field studies, observations, rapid paper prototypes and the like, we are contradicting the very methods that we claim to be promoting.

The programming community has long struggled with similar issues. They too are trying to eliminate the lengthy, inflexible linear project schedules that slow up projects. They are experimenting with a variety of new methods, for example Agile, XP (Extreme Programming), and other rapid, iterative programming methods. Hurrah for them.

The linear project procedures (also called “waterfall methods”), with lengthy setting of objectives, followed by design, coding and then test, is dead. Thank goodness. The new programming styles practice iterative design, and promulgate multi-disciplinary teams: everything we should be striving for. Now it is time for the UI community to follow their lead – to do what we ourselves have been preaching.

Why doing user observations first is wrong - Don Norman - April 2006