Action research as a model for industry-academia collaboration in the software engineering context

Abstract

Background: Action research is a well-established research methodology. It is following a post-positivist research philosophy grounded in critical thinking. The methodology is driven by practical problems, emphasis participatory research, and develops practically useful solutions in an iterative manner. Objective: Two objectives are to be achieved: (1) Understanding the state of the art with respect to action research usage in the software engineering literature, and (2) reflecting and providing recommendations of how to foster industry-academia collaboration through action research. Method: Based on our experience with two action research studies in close collaboration with Ericsson lessons learned and guidelines are presented. Results: In both cases presented action research led to multiple refinements in the interventions implemented. Furthermore, the close collaboration and co-production with the industry was essential to identify and describe the required refinements to provide an in-depth understanding. In comparison with previous studies, we required multiple iterations while previous software engineering studies reported mostly one iteration, or were not explicit regarding the number of iterations studied. Conclusion: We conclude that action research is a powerful tool for industry-academia collaboration. The success of the method highly depends on the researchers and practitioners working in a team. Future studies need to improve the reporting with respect to describing the type of action research used, the iterations, the model of collaboration, and the rationales for changes in each iteration.

Challenges and best practices in industry-academia collaborations in software engineering: A systematic literature review

“…When we did the data extraction, we did one level of coding by applying the open coding. All authors independently conducted the open coding on two included papers [21,31] and thereafter compared and discussed the coding results to align their understanding of the coding process. The remaining papers were coded independently by the authors.…”

“…It was recommended in multiple sources to employ the researcher (e.g. full employment [31], internships [64,55], or at least part-time [59]) (BP87).…”

“…The challenges reported were context dependence and lack of generalizability [31] (also internally in the company when using pilot studies [21]), lack of control in the industrial environment [31,66], lack of the ability to create repeatable results [42] and bias and subjectivity of the researcher [31]. The technology transfer process itself has been highlighted as a validity threat [67].…”

“…During the design and evaluation of the solution, it is also important that researchers and practitioners work as a team [31,45,31] (BP51) with the mindset of collaborating to improve a situation rather than transferring a research solution [45,23]. Thereby, multiple stakeholders from industry across department boundaries should be involved [65,21].…”

Concept analysis in programming language research: done well it is all right

“…There are detailed methodological expositions of at least case studies [88], controlled experiments [104], systematic reviews [54], action research [79], and grounded theory [38,94]. The information systems and human-computer interaction research fields have their own methodological traditions (see, e. g., Järvinen [44], Lazar et al [56]).…”