Innovation vs. Incremental Improvement

Not all teams build products in highly uncertain environments or try to create cutting-edge new features. Many incrementally improve existing products and try to do so in a way that doesn’t alienate large existing user bases. Neither of these tasks is particularly easy, and they often require very different approaches to research and design. Let’s take a look at how things differ depending on a team’s goals. 

Often, product teams, regardless of how agile they are, don’t have a very good distinction between “how to do research for a brand new, innovative product” vs “how to do research for an existing, successful product with customers.” You’ll notice we said “product teams” don’t have that distinction. Typically user researchers have a very good idea of the different sorts of research required, but they’re not always the ones making the decisions, unfortunately. 

The reason that this is worse in agile environments is that many teams have largely gotten rid of the big, dedicated “discovery” phase that was used to do early research on new products or new versions of products. 

Since this phase happened before engineering started work on the product, and often before the product manager started writing requirements, there was generally more time to do things like contextual inquiry and deep ethnographic research. Did this always happen? No, of course not. But it was accounted for in the waterfall process, and in organizations that believed in user research, there was time built into the schedule for more in-depth research than you often see in agile environments now. 

Doing early research into user needs and problems before building a product obviously doesn’t prevent us from having to continue to do research once we’ve shipped a product—nor does it exempt us from doing usability testing on prototypes or designs. However, when we were all working in a waterfall fashion, we would ship a new version, and then start all over again with early research, often studying how people were using our product and finding all the different ways we could improve it. 

With agile teams, on the other hand, we are constantly building, constantly shipping, and constantly learning. How, then, do we distinguish between the kind of foundational research that delivers big, innovative changes and the kind that helps us identify small, incremental improvements? And are the techniques and methods we use really that different? Let’s find out from Laura Klein, UX designer and author of Build Better Products, in this video!

Why This Matters

In companies that already have existing products or that might have longer time horizons for building new features and introducing new products, we often have to balance the time we spend on the different sorts of research. But the longer, more in-depth research studies can be a challenge in agile teams, because they don’t fit neatly into one or two sprints. 

Also, it can be very tough to do both sorts of research at the same time, especially if you only have one researcher on an agile team, which is often the case. Running a large contextual inquiry or diary study can be time-consuming, and if you’re also expected to run weekly usability test sessions or implement a Voice of the Customer program at the same time, that can be a quick recipe for researcher burn-out. 

In many ways, this is similar to any sort of split between foundational, generative research and more incremental, evaluative research. Sometimes folks call this researching the problem space vs researching the solution space. It’s also similar to discovery research vs delivery research. 

The important thing to remember, no matter what you call it, is that there is a difference in the kind of research you do depending on the kind of thing you want to learn. Some research is simply more open-ended than other types of research, and this type of early, exploratory investigation can end up being much more difficult to integrate into an agile team, especially if the team is practicing Scrum and everybody is operating in one- or two-week sprints. 

How to Fix It

Unfortunately, there’s not a single easy solution to this problem, but there are several different approaches you can take. In many instances, simply knowing the problem exists can help, because you’ll be able to talk about the different time horizons of the research with your team. If a product owner wants to work on a feature that requires some of the longer-term research, you can help them prioritize other, less research-heavy features first to give you the time you need. 

Another approach, sometimes adopted by larger organizations, is something called Dual Track Agile. In a 2005 paper, Lynn Miller, then the Director of User Interface Development at Alias, wrote about “interconnected parallel design and development tracks.” Later, in 2012, Marty Cagan and Jeff Patton named something called “dual track scrum” where the delivery track and discovery track would work in parallel, with the discovery track validating new product ideas and then feeding them into delivery. 

Of course, separating out discovery from delivery can end up looking an awful lot like a Waterfall, or possibly an AgileFall. 

That might be perfectly acceptable, or even necessary, for your team. Trying to fit everything into a sprint in pursuit of some ideal “agile” solution can lead to some extremely poor outcomes, especially if bigger, more exploratory research is being sacrificed. 

The Take Away 

Explicitly acknowledging the fact that there are different types of research with different time horizons and different logistical requirements can be the first step toward reconciling research with agile methodologies. Having separate teams responsible for the different types of research can be an important step in not burning out all the researchers on the team! 

Unfortunately, not all teams have the sorts of resources necessary to have separate teams devoted to different tracks. In that case, researchers need to learn to work at different levels and find the best research methodology suited to the questions they’re trying to answer. 

References and Where to Learn More

Learn more about Lynn Miller’s Dual Track Agile approach here.

Images

© Daniel Skrok and Interaction Design Foundation, CC BY-SA 3.0