Is there room for UCD in Agile?

I'm a member of an agile usability discussion group. There has been a lot of discussion lately about how and whether designers and UCD people can work within an Agile project. There is a lot of concern that methods and aproaches may not mesh -- that Agile starts developing and releasing stuff long before the designer can complete their diagnosis of the problem and create an effective solution.

for most of my time at ThoughtWorks, we did not have any UCD staff but that has changed over the last year or so. Still, every project is different and we shape it according to what works for the situation.


Sometimes, there is no UCD involvement and business analysts and developers just have to make things up based on what they see as making sense and where the client is coming from (often these are applications for the clients internal use ). Sometimes there are projects where the client hired a designer independently of bringing TW in for the implementation and their design is pretty much a static requirement in place at the start or delivered part way through (not very good). And then there are projects where we can have our own UCD person on-board or the outside design firm is committed to working as part of the team through the life of the project. That's when it gets good.

Ideally, there is one or more UCD-skilled person(s) involved on the team through the life of the project. When you have this, the UCD person is utilizing their skills as they play some combination of other roles: product owner/customer, business analyst/SME, developer. This is very much like the way a business analyst would also fit into team.


A business analyst has to be able to understand the business operationally, grasp the strategic objectives of the stakeholders; interview stakeholders and customers/users to discover and verify requirements; be an advocate on the team for the customer/stakeholders; be an advocate for the strategic objectives (sometimes even stakeholders lose track of the greater goals); know enough about technology to have an intelligent conversation with developers so they can advocate back to the stakeholders when choices get hard; and maybe even sometimes do something technical themselves, plus be able to specify and conduct effective acceptance tests so everyone can be assured the story is Done when it's done.

That is not so very different from what the UCD person wants to achieve. Given that, the UCD member of the team is just another flavor of analyst /developer on the team. They concentrate on their specialty but they also collaborate on other just-in-time project tasks as appropriate. For example, maybe doing javascript coding or conducting showcases with the stakeholders, or writing stories and acceptance tests. Programmers also pair up with the UCD analysts as needed to have conversations, investigate technical issues, or research the business problem.

In my next post(s), I'll discuss three very specific questions about how this can work.