Similarities Between Agile and UCD Methods
Let’s start by exploring the similarities between the two approaches.
I particularly like Alistair Cockburn’s comparison of an agile development process to a cooperative game: “Software development is a (resource-limited) cooperative game of invention and communication. The primary goal of the game is to deliver useful, working software. The secondary goal, the residue of the game, is to set up for the next game.” Thus, according to Cockburn, an agile development method, at its core, is about delivering useful software. According to Rassa Katz-Haas, user-centered design is about understanding people’s needs—so we can provide useful software. She writes: “[User-centered design] places the person (as opposed to the thing) at the center…. UCD seeks to answer questions about users and their tasks and goals, then use the findings to drive development and design.”
A human-centered design approach allows us to better understand the people who use our products, while agile development techniques let us build, test, deliver, and revise our products faster. This is what software design and development is all about: delivering meaningful products to people. So, if these two methods seem to complement each other so well, why is there so much friction and frustration when it comes time to integrate them? A surface examination of the issues can’t answer this question. We must dig into the details of these methods, where integration gets more complicated.
Differences Between Agile and UCD Methods
Defining a development process is a tricky thing. The most challenging aspect is that of defining how people are going to work together. People who have egos and opinions. People whose skills may be undervalued or who may not be fully committed to the process. Define a process too strictly and it becomes unbearable and unadaptable; define it too loosely and there is a risk of not including the right people at the right time.
Agile’s iterative development cycle is one of the method’s strengths, but it also makes for some tight deadlines. As the now infamous interview between Alan Cooper and Kent Beck [2] shows, the timeline is perhaps the most controversial aspect of agile methods. In such a high-speed development cycle, do we have time to fully understand users’ needs? The short answer is no. The long answer: If we’re defining users’ needs during development—even in an agile development process—something has gone horribly wrong.
Case in point: One of the engineering teams I’ve worked with used six-week cycles and two-week iterations. My original plan was to stay one iteration ahead of them, but that proved problematic—especially when I got to the second iteration. By that time, I was supporting revisions to iteration 1, supporting development on iteration 2, while designing for iteration 3. Needless to say, I drank a lot of coffee and burned the midnight oil for several weeks.
Redesigning a Development Process
What to do? I started out by taking a deep dive into agile development methods. I needed to better understand the theory behind these methods before I could even begin to resolve the friction between the two processes. In doing this study, the first thing that became apparent to me was that agile is a method of development. It’s certainly not a research process, and it’s only loosely a design process. Despite what many proponents of agile development methods would have you believe, they cannot replace the need for some up-front user research or design. Agile proponents may cringe at that statement, but I stand by it. That said, though, while agile methods can significantly reduce the amount of up-front design that’s required, it does not, in any way, reduce the time user research requires.
User Research
User research and agile do not play well together. The time to conduct field research is not during development. Research should occur before any design or development work begins. This may seem obvious, but is an extremely important point—especially when you consider that agile development is about writing code as early as possible and delivering working software as often as possible. Conducting user research slows things down. However—and I’m probably preaching to the choir here—user research provides insights into customers and their needs that will help a product team to identify useful new features and products as well as to prioritize those features and products for development.
The outcome of user research is documentation that describes users and their needs and goals—for example, personas that represent a product’s primary and secondary audiences. Many agile development methods employ user stories—which are somewhat similar to scenarios—and personas can become the main actors in these user stories. By creating behavior and goal-based personas, you can make your user stories much more effective. At this stage—before design has begun—user stories should be fairly high level and detail only how people will generally interact with your product.
I recommend involving a representative from engineering in your field research. By seeing users in the wild, engineers will develop some empathy toward them. Of course, doing this is helpful no matter what type of development method your team is using. Also, include this engineer in the process of developing personas and user stories. Getting buy-in from engineering is critical to the successful use of personas and user stories during the development cycle.
