What is Agile Research?

Agile research is research organised to fit iterative, incremental product development: small studies scoped to sprint-sized questions, run continuously rather than as occasional large projects, with findings delivered in time to shape the next increment. The tension it addresses is structural. Agile methods optimise for shipping working software frequently and adapting to feedback; traditional research optimised for comprehensive studies delivered as reports, on timelines that spanned several sprints. Teams that kept the old research model found it irrelevant by the time it arrived; teams that dropped research found themselves iterating quickly toward things nobody wanted. Agile research's answer is to change the unit of work: from the study to the question, from the report to the conversation, from the phase to the habit.

The Practices That Work

1. Research one sprint ahead.
The dual-track pattern: a discovery track investigates what should be built next while the delivery track builds what was decided last time, so evidence arrives before commitment rather than after. Research is never blocked by the sprint it informs, because it runs ahead of it.

2. Keep a standing cadence of contact.
A fixed weekly slot of participant sessions (the continuous discovery practice associated with Teresa Torres, among others) turns recruitment from a project into an appointment: users are always coming in, and the team decides each week what to put in front of them. Standing panels and fast recruitment are the infrastructure; a screened panel that can fill a study in a day (a Ballpark study fielded to panel participants runs on this timescale) is what makes the cadence sustainable.

3. Scope questions to what a sprint can use.
"Does the new filter design work?" is a sprint question; "what do enterprise buyers need?" is not. Big questions get decomposed, and the pieces run in sequence, each round informing the next, the iterative logic applied to inquiry itself.

4. Deliver findings as they land, in the room.
Sessions observed by the team (live or as clips), same-day summaries, and findings discussed in planning rather than presented after it. The report that arrives after the decision was research for the archive.

5. Match the method to the speed.
Unmoderated prototype tests, short surveys, quick concept checks, and five-person usability rounds are sprint-native; multi-week ethnography and large representative surveys are not, and belong to the discovery track's longer horizon rather than being abandoned.

6. Maintain the repository.
Fast research produces many small findings that lose value if they scatter; a lightweight repository lets sprint-sized insights accumulate into something larger than any one of them.

The Corners That Must Not Be Cut

Speed pressures three things that speed cannot excuse. Recruitment quality: the fastest participants to find (colleagues, friendly customers, whoever is available) are not the audience, and sprint research with the wrong people is quick, cheap, and wrong. Claim discipline: five participants find design problems; they do not establish prevalence, and agile readouts are chronically tempted to report "users want X" from a Tuesday's sessions. Method hygiene: neutral tasks, unleading moderation, and honest scoring take no extra time and are the first things dropped under deadline. The distinction between fast research and rushed research is precisely whether these three survive.

The Takeaway

Agile research fits evidence to the rhythm of delivery: a discovery track running a sprint ahead, a standing cadence of participant contact, sprint-sized questions, findings delivered in the room, sprint-native methods, and a repository that makes small insights compound. Speed is bought by changing the unit of work, never by recruiting the convenient, overclaiming the sample, or skipping the hygiene. Research that keeps pace with the sprint and keeps its standards is the version that earns a seat at planning.