Agile Research

Posted by Professor Orit Hazzan & Sergey Tozik on May 14, 2014 |


Agile development methods that spread in the software development industry attract academic and corporate researchers that try to pin down the social processes that characterize the agile teams and the impact of these processes on the teams’ performance.

We have asked ourselves whether the application of the Agile principles may benefit the researchers that investigate the Agile development methods and teams (or any other research community).

No researcher has yet, to our best knowledge, suggested a method for conducting research “the agile way”; in other words, no “academic agile process” has yet been laid out.

Developing the principles of the Agile Research

"Twelve Agile Principles" of the Agile Software Development can be mapped to the language of academic research – as in the following table:

Agile Research Principle

Agile Software Development Principle

When research is the "product", the "customer" is either a) the editor of the peer-reviewed journal you submit your paper to (representing the journal readership) or b) the committee examining your thesis. Your advisor should act as the perfect proxy for these customers. Prior publications of partial and intermediate results will increase probability of success.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Organize your work around the draft of the final product paper, research proposal or thesis. Achieve an "almost publishable" product every couple of months, more or less, even when there are not enough "features" to actually submit the draft.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Welcome critique from your advisors, reviewers and peers. Welcome changes in the research direction even when the deadline looms closer–they may improve the final product.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Update your advisors very frequently, seek valuable advice, and don't be afraid of looking foolish (you don't) or unprofessional.

Business people and developers must work together daily throughout the project.

A researcher is inherently motivated. Research assistants may not be so eager. Assign them valuable and exciting research tasks, give them the environment and support they need, and trust them to get the job done. If you perform your research alone, motivate yourself by alternating exciting tasks with routine ones, and don't overstretch the boring periods.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Meet with your advisors, peers and assistants face to face. Meetings are better than the phone; the phone is better than e-mail, Google docs or Dropbox.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Evolving drafts are the primary measure of progress.

Working software is the primary measure of progress.

Try to maintain a constant pace – don't procrastinate or rush. Create some kind of Kanban-like system that will help you keep work-in-progress at a manageable level. Finish tasks; don’t let them linger and weigh on your conscience.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Writing style is not a luxury. The ability to write clearly and organize your research workplace and notes enhances the quality and the agility of the research/

Continuous attention to technical excellence and good design enhances agility.

Focus on your research goal and research questions.

Simplicity–the art of maximizing the amount of work not done–is essential.

Discuss the methodology and results with your peers and colleagues frequently.

The best architectures, requirements, and designs emerge from self-organizing teams.

Learn to reflect. Write yours reflection down in your journal. Discuss your insights with your advisors and peers. Your self-improvement as a researcher is no less important than the progress of your research.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Applying the tools of the Agile Development in the research practice

In order to test our ideas in real-life research setting, we have applied the Agile principles and tools to the Grounded Theory qualitative research methodology that was proposed by Glaser and Strauss in the 1960's and developed ever since into the family of research methods (see the humorist and accurate summary of the method by Hoda in "Grounded Theory for Geeks").

The Grounded Theory methodology emphasizes the emergence of a theory from the field data as opposed to using the data to support or falsify a priori hypotheses, and thus is inherently evolutionary and flexible. In our opinion, these methodologies are the first to benefit from the proposed application of the Agile Principles.

We have developed the following set of practical guidelines that may be used to perform the Grounded Theory research in the “Agile way”, using the tools similar to those used in the Agile Software Development:

  • Focus on the delivery of the working product to the customers or their proxies

In academic research, the product is either a PhD dissertation or a paper submitted to a peer-reviewed journal or a conference. In the former case the customers to be pleased is the dissertation committee; in the latter case, it is the reviewers and editors of the journal. When junior researchers are involved, senior advisors may act as proxy for these customers and play the role of the “customer-on-site”.

  • Deliver in iterations, work in sprints

Agile principles call for frequent deliveries of useful product prototypes. In the case of research, the prototypes are the drafts of the final document. It is useful to complete a draft every couple of weeks or months so as to minimize procrastination and makes the research ready for presentation at any seminar or conference – the opportunity that may arise at any time.

  • Focus every sprint on the specific research activity

The researcher focuses on a single sprint at a time and thus limits the amount of work-in-process, as specified below.

  • Data-gathering sprints focus on scheduling, performing and transcribing a single or a small number of interviews, recording and transcribing observation sessions, or analyzing a batch of documents. During these sprints, the researcher also performs a preliminary data analysis. The results of data-gathering sprints are used to update the “Research Data” chapter of the evolving document.
  • Theory-building sprints focus on advancing the grounded theory by performing deeper data analysis, writing the theoretical research diary, and gradually updating the “Theory” chapter of the evolving document, as the theory emerges from the data.
  • Literature survey sprints focus on reading and critically summarizing a single or a small number of research papers. The critical summary may focus on identifying relevant claims and ideas and positioning them in the relevant body of knowledge. The results of these sprints enable to update the “Introduction” or “Literature Survey” chapter of the document and can also be used in the theory-building sprints.
  • Product-stabilization sprints focus on document editing (refactoring). During these sprints, the researcher reflects on the completed iteration and tries to implement the lessons learned in order to improve the performance of the next iteration, to steer the project toward its goals, and if needed, even to change the goals. As the researcher reviews the iteration, he or she updates the “Methodology” chapter of the evolving document, which in grounded theory research means reflecting on the actual pathway towards the theory rather than following any specific methodology. 
  • Use project backlog and progress tracking

While the sprints advance the project, a backlog is created by identifying the informants to be interviewed, scheduling interviews and events to be observed, and gathering documents and papers to be perused. The researcher then pulls the tasks for the next sprint from this backlog. An empty backlog will block the project, but since there are always papers to be read, the literature survey sprints will advance the project even during “dry seasons”, when no other information sources are available. The researcher may even devote an entire sprint to boosting the backlog, creating a kind of backlog-building sprint.

  • Reflect on what was and use it to improve what will be

The agile way calls for reflections and retrospections in order to guide the project and increase effectiveness, efficiency and professionalism. The researchers, especially part-time ones, often work in isolation and it is, therefore, important to seize every opportunity to reflect and receive feedback. Since reflection has an inherently emotional component, the researcher must use face-to-face meetings with advisors and colleagues for reflection rather than for discussing the research itself – the later can easily be conducted online or by phone. In grounded theory research the researcher's reflections are considered part of the methodology, so the documentation of reflections in a research diary may even contribute to the "Summary" chapter of the evolving document.

  • Archive the information that supports the evolving product

As the research proceeds and the manuscript evolves, many notes and memos are left behind. As the researchers focus on the final product, they should not forget that pieces of information that were not perceived as important may become critical as the research evolves. Eventually, the manuscript must be supported by an organized and searchable archive that will help locate past information.

This archive includes:

  • Knowledge maps of various kinds that reflect the researcher's understanding of the body of knowledge at different stages, and links to information resources such as research papers, theoretical memos and so on.
  • Interview and observation transcripts, informants’ consent forms, documents used for data extraction.
  • Intermediate data analysis and researchers’ memos that reflect insights and ideas revealed by the data.
  • Research diary documenting the research progress and the researchers' reflections.

Since we are still experimenting with the implementation of the archive, at this time we propose only one useful option for organizing the archive, namely according to the structure of the evolving manuscript.


Both academic research and the software development produce information-focused artifacts – either the logics captured in the computer code or the knowledge captured in the research publications, so similar principles may be applied to both endeavors.

In this article, we have applied the Agile Principles to the field of the academic research, generating the first draft of the “Agile Research” principles; we have also presented practical guidelines for the application of these principles to the Grounded Theory qualitative research methodology, utilizing tools that are similar to those that are used in Agile.

We hope that as the “Agile Way” promises faster delivery of better and cheaper software, so doing research in similar ways will bring to life faster and cheaper development of rich and relevant knowledge, for the benefit of both the scientific community and the community of the practitioners.

About the Authors

Professor Orit Hazzan has four degrees from the Technion - Israel Institute of Technology. Three degrees from the Department of Education in Science and Technology (B.Sc in 1989, M.Sc. in 1991, Ph.D. in 1995) and an MBA from the Faculty of Industrial Engineering (2000(. She joined the Department of Education in Science and Technology in October 2000 and starting January 2011 she is the department head. Her research focuses on computer science and software engineering education. Professor Hazzan has published about 100 papers in professional refereed journals and conference proceedings, co-authored three books.


Sergey Tozik holds an MSc degree in physics from the Weizmann Institute of Science and an ME degree in Systems Engineering from the Technion -Israel Institute of Technology. He is currently enrolled in apart-time PhD program at the Department of Education in Science and Technology under the supervision of Professor Orit Hazzan His research interests focus on the professional characteristics and the training of Systems Integrators. The research is interleaved with carrying out the role of a Chief Integration Engineer that is responsible for a) the development of Systems-of-Systems Integration and Test methodologies and b) the training of Integration Engineers.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

What is the "what" (the "problem") you want to solve with this "how" (the "solution")? by Hans-Peter Korn

You start with this question - addressing "agile" as a proposed solution:
"No researcher has yet, to our best knowledge, suggested a method for conducting research “the agile way”; in other words, no “academic agile process” has yet been laid out."
But: What is the issue in what context which can be solved with "agile"?
If there is no such issue it sounds to me like "hurrah - we have "agile" as a silver bullet solution and now lets apply it everywhere independent from the "what" we have to achieve!"
All what you propose is not new for R&D - all this are well known practises since centuries! Of course: Often it is not so easy to apply them, for example in a context where you have to show, that the investment (of maybe some millions of $) makes sense compared with investments for other research initiatives funded by universities, governments or even big companies with restricted budgets for R&D-investments.
On the other hand in such situations "small steps" to proof the potentially important outcome are a broadly accepted way of work already.

So please: What problems in what context do you want to solve? How have you handled them until now? What is really *new* concerning your new ("agile") way to handle them? For what problems in what contexts did you apply them successfully?

Academic research is long overdue for an agile overhaul, IMO by Chris Riesbeck

I did a Prezi ( a couple years back pushing a few aspects of this. Now to get the faculty advisors on board!

Simplicity–the art of maximizing the amount of work not done. by Miguel Gouveia

This sentence is correct?
"Simplicity–the art of maximizing the amount of work not done–is essential.". If is correct then I can't understand it.

Agile in the lab by Piotr Burdylo

You might not have heard about an implementation of agile in one of Polish biochemistry labs. Check out the video of a presentation done last year on AgileByExample conference in Warsaw, PL. Let me know what you think.

So true! by Jack Carlton

Loved the article, and I have to agree with other readers - applying Agile to academic and R&D works was possible for long years now and it's a shame it's only now taking off. I work as a researcher myself and had been nagging my boss to try it large-scale for years (my partner is a software developer, so I know the methods). Going to show this to my manager now - hoping for good results. I read this introductory post on it here: so this will be a start, then move to your article for more details.
Thank you so so much! Great work.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss
General Feedback
Marketing and all content copyright © 2006-2015 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy