Personality-based pair programming: toward intrinsic motivation alignment in very small entities

Research approach

The study combines deductive (theory-driven) and inductive (data-driven) approaches to theory development in a mixed-methods strategy (Johnson, Onwuegbuzie & Turner, 2007). Quantitative experiments, informed by established theories (e.g., Self-Determination Theory, Ryan & Deci, 2017; Big Five Personality Traits, McCrae & Costa, 2008), tested hypotheses about personality-role interactions. In contrast, an essentialist thematic analysis (Braun & Clarke, 2006) inductively derived themes from participant interviews without imposing preconceived frameworks. This approach enabled deeper insights into experiential aspects of role assignments and motivation, allowing emergent results to surface (Seaman, Hoda & Feldt, 2025).

By merging critical realism with essentialism, we aimed to identify cause-effect relationships in motivation and role assignments while also acknowledging that participants’ personal accounts reflect essential features of their psychological experiences.

Mixed-methods quasi-experimental design

Due to practical constraints, we adopted a quasi-experimental design with convenience sampling in a classroom setting of advanced undergraduate software engineering students at the Prague University of Economics and Business. This pragmatic design enabled us to investigate how personality traits interact with assigned programming roles (Pilot, Navigator, Solo) to influence intrinsic motivation. We integrated quantitative and qualitative data as follows:

1. Quantitative phase: Participants undertook controlled programming tasks under varying roles. We collected repeated measures of intrinsic motivation and personality profiles.

2. Qualitative phase: Semi-structured interviews explored participants’ subjective experiences, adding contextual depth to the statistical findings.

3. Cross-study integration: We compared and integrated new findings with previous research (Valový, 2023a, 2023b) to build a comprehensive understanding of motivational dynamics in pair programming.

Participants and ethical considerations

We drew on two cohorts of advanced undergraduate software engineering students: 40 participants from a Winter 2021 study (WS’21; Valový, 2023a) and 26 participants from a Summer 2022 study (SS’22: the current PeerJ dataset), totaling 66 experimental participants who completed all required sessions and were included in the quantitative analysis. For the qualitative interviews (phases 2 and 3), we recruited participants from three studies: twelve participants from the WS’21 cohort, six participants from the SS’22 cohort, and seven participants from a Winter 2022 study (WS’22; Valový, 2023b). This yielded a total of 25 interview participants. Counting these additional seven interviewees from WS’22, the overall pool across studies included 73 unique individuals (66 from the two main quantitative cohorts plus 7 from WS’22).

All studies were carried out under similar conditions in quasi-experimental settings with advanced undergraduate software engineering students at the Prague University of Economics and Business. Although these students are not seasoned professionals, prior empirical software engineering literature supports using advanced students as proxies for novice practitioners in controlled experimental conditions (Falessi et al., 2018; Feldt et al., 2018). This limitation is further discussed in the Limitations and Generalizability section.

In accordance with the ethical guidelines of the institutional review board, a consent waiver was obtained due to the minimal risks posed to participants and the educational context. Nevertheless, participants were fully informed about the nature of the study, and ethical principles, including anonymization of data and voluntary participation, were strictly followed.

Experimental context and task design

The quasi-experiment took place in a classroom setting. Participants worked on 24 programming tasks across four sessions (six tasks per session). Tasks were designed to have similar complexity and duration, covering various areas of software engineering, such as creating graphical user interfaces for adventure games, implementing 2D animations in JavaFX, and developing multi-user Spring Boot web applications. Ensuring task comparability aimed to attribute observed motivational differences to role assignments rather than task difficulty variations.

We manipulated the key factor—assigned programming roles—while controlling confounding variables (e.g., task difficulty, time allocation) at a constant level (Wohlin et al., 2012). Across both control and test sessions, a total of 1,092 intrinsic motivation inventories were collected from 66 participants.

Roles, role rotation, and experimental conditions

Participants assumed three roles:

• Pilot: wrote the code and implemented solutions,

• Navigator: provided conceptual oversight, feedback, and high-level guidance,

• Solo: worked independently without a partner.

Regular role rotation at fixed intervals (every 10 min) ensured balanced exposure to all roles. Initially, participants paired with the students sitting next to them (convenience sampling). To address occasional absenteeism (four absences due to illness) and ensure continuous participation, we sometimes formed three-person groups. This group reconfiguration minimized missing data but introduced variability. By focusing on repeated measures at the individual level, we reduced the impact of these configurations on motivational comparisons.

Paired design

A pilot session familiarized participants with the roles and the psychometric measures. In the following two experimental sessions, participants were split into control (Solo only) and test (Pilot/Navigator rotation) groups. This arrangement with enforced rotations prevented “free-riding” and ensured balanced participation in both coding and reviewing tasks (Forsyth & Elliott, 1999; Gallis, Arisholm & Dyba, 2003).

In the final (fourth) session, all participants were moved into a test condition (Pilot/Navigator rotation), allowing each participant to experience all three roles—Solo, Pilot, and Navigator—in equal measure. This structure ensured that every participant had a comprehensive exposure to each role, enabling more reliable comparisons of intrinsic motivation across roles.

Instruments and data collection

Standardized psychological measures are increasingly recommended in empirical software engineering, aligning with our essentialist stance that treats personality and motivation as stable constructs amenable to empirical assessment (Graziotin et al., 2021; Feldt et al., 2010). We therefore used:

• Personality traits: The Big Five Inventory (BFI-10; Rammstedt & John, 2007) assessed Openness, Conscientiousness, Extraversion, Agreeableness, and Neuroticism. Though shorter scales can reduce interpretative depth (Felipe et al., 2023), the BFI-10 generally maintains acceptable validity (test–retest reliabilities ≈ 0.62–0.75, convergent validity ≥0.83 with BFI-44). Participants completed the BFI-10 once at the beginning of each session, and mean trait scores across sessions were computed to enhance stability and reduce transient fluctuations.

• Intrinsic motivation: The Interest/Enjoyment subscale of the Intrinsic Motivation Inventory (IMI; Ryan & Deci, 2024) measured participants’ intrinsic motivation at the end of each programming round (six rounds per session). This subscale is widely recognized for its robust psychometric properties and for capturing intrinsic motivation directly.

  (Note: The IMI ranges from 7 to 35 per round, reflecting the sum of 7 items on a 5-point Likert scale.)

All participants had at least B2 English proficiency, ensuring comprehension of the original instrument items. Data collection proceeded without task interruptions—if participants had not finished a previous task, they could continue working in the next round, with instructors available for assistance.

Repeated measures, nested data structures, and analytical approach

Each participant performed multiple programming rounds in each role, resulting in repeated measurements of intrinsic motivation. Consequently, the data had a nested structure: multiple observations (rounds) per participant. To address such non-independence and repeated-measures design, we employed linear mixed-effects (LME) models (Pinheiro & Bates, 2000) using R’s nlme package.

In these models, each participant received a random intercept to account for individual baseline differences in motivation. Fixed effects included Role (Pilot, Navigator, Solo) and continuous Big Five personality traits (scaled 1–10). Interaction terms (e.g., Role × Openness) tested whether specific traits moderated the motivational effects of each role. The LME approach properly addressed the hierarchical nature of the data and the within-subject correlations, ensuring more valid inferences.

Two LME model specifications

1. Interaction model (traits as covariates): The first model incorporated Role and the continuous Big Five traits, along with their interactions, to examine how individual differences in personality influenced intrinsic motivation across roles.

2. Cluster model (personality-based clusters): We also performed a simple cluster analysis on averaged trait scores to assign each participant to a dominant trait cluster (O, C, E, A, or N). A second LME model replaced the continuous trait interactions with a Role × PersonalityCluster interaction, assessing distinct motivational patterns by personality cluster.

Post-Hoc comparisons

We used the emmeans package for post-hoc comparisons, estimating marginal means and pairwise contrasts. These clarified differences in predicted motivation among roles and trait (or cluster) configurations. Effect sizes (Cohen’s d) were computed via the eff_size() function in emmeans, referencing the model’s residual SD.

Experimental validity and control factors

We endeavored to control key factors like task difficulty and session length; however, some contextual variables—time of day (9:15–12:30 AM) or occasional three-person group reconfigurations due to absenteeism—were not fully constrained. Such factors may influence motivation and performance and are acknowledged as limitations. The primary manipulated factor was the assigned programming role. Rather than aiming for a fully isolated laboratory environment, our goal was a robust quasi-experimental design that minimized major confounds.

Tasks were carefully designed to maintain equal size, complexity, and duration (Sjøberg et al., 2002; Vanhanen & Lassenius, 2005). Participants were informed that no external rewards (e.g., course credits) were tied to their performance, maintaining focus on intrinsic motivation (Vinson & Singer, 2008). Although partner compatibility may matter (Katira et al., 2004; Williams et al., 2006), previous studies suggest minimal confounding from partner personality when roles are clearly defined. Additionally, by measuring motivation rather than performance, we reduced potential confounds of varying individual ability (Arisholm et al., 2007; Latham, 2012).

Hypothesis testing

The LME models tested main and interaction effects of roles and personality traits (or clusters) on intrinsic motivation. Our key hypotheses included:

• H1 & H1-Cor: Role-based differences in intrinsic motivation exist and remain stable within individuals.

• H2 & H3: Distinct personality configurations (clusters) align with role preferences.

• H4–H6: Specific traits (e.g., high Openness) differentially modulate motivation across roles.

All statistical analyses and visualizations used R version 4.4.1 (with RStudio 2024.04.2). Scripts, anonymized datasets, and computed outputs are publicly available as Supplemental Material.

Interview procedures

Shortly after the final experimental session, participants in the Summer 2022 cohort were invited via email to partake in recorded semi-structured interviews (n = 6) via MS Teams. These interviews, led by the authors, aimed to unfold naturally and garner in-depth insights into the participants’ experiences and perspectives (Creswell & Creswell, 2022). They ranged from 20 min (Subject S1) to 34 min (Subject S6), featuring a structured protocol of ~25 open-ended questions spanning seven thematic areas, encouraging participants to reflect on their motivations, challenges, and perceptions regarding the three programming roles.

To distinguish sources across our three cohorts, we adopt the following notation:

• I# for participants from the WS’21 data set (12 interviews),

• P# for participants from the WS’22 data set (7 interviews),

• S# for participants in the SS’22 data set (6 interviews).

Each study reached saturation with respect to its original research questions, yet new or revised topics in subsequent interview protocols allowed for emergent insights and further refinement of the thematic framework.

Qualitative thematic analysis and inter-coder reliability

We adopted a reflexive thematic analysis approach (TA; Braun & Clarke, 2006, 2019) from an essentialist perspective, allowing themes to emerge inductively from participants’ accounts rather than imposing predetermined categories. The essentialist stance assumes that participants’ descriptions directly convey stable underlying “essences” of their experiences (Creswell & Creswell, 2022). In contrast to the quantitative approach, which was theory-driven, our qualitative analysis was data-driven, focusing on participants’ subjective viewpoints about pair programming roles and how personality shapes intrinsic motivation.

Initially, Coder 1 transcribed all six SS’22 interviews using Descript (v67.1.1) and performed open coding in MAXQDA (v22.3.0). Approximately 70–80 codes were generated at this stage. For instance, we had a broad code like “Difficult personality interactions” that conflated various personality-related conflicts. Another example was “Time management issues,” which mixed positive and negative views on time constraints without differentiation.

Inter-coder reliability procedure and code refinement

To strengthen interpretive rigor, we applied an iterative inter-coder reliability (ICR) process (O’Connor & Joffe, 2020):

• 1. Pilot coding:

We selected two interviews (~33%) from SS’22, two (~17%) from WS’21, and two (~29%) from WS’22 for the pilot phase. Coder 2, who was blind to Coder 1’s assignments, independently coded these interviews. The unit of coding was the sentence, and codes were applied in a mutually exclusive manner to maintain clarity in code boundaries.

• 2. Refinement of codes:

Discrepancies between coders prompted splitting or merging of codes. For example, the broad “Difficult personality interactions” code was replaced by more specific labels, such as “Extraversion contrast leads to conflict” (I3, S2) and “High neuroticism restricts flow” (I4, P1), capturing distinct personality-related challenges more explicitly.

Similarly, codes like “Time-limits cause confusion,” “Participants ask for more time,” and “Desire to rotate after finishing tasks” were unified under “Mixed perceptions of time limits” (P5, S2). After consensus discussions to improve discriminant capability by splitting or merging redundant codes, the set was reduced to 60 well-defined codes (Campbell et al., 2013).

• 3. Coding process overview:

• Transcription & familiarization: Coder 1 listened to all audio recordings, transcribed them via Descript, and performed open coding.

• Sampling prior data for calibration: Two random interviews from SS’22 and two of the longest interviews from WS’21 and WS’22 were selected and coded separately by both coders.

• Immersion & merging: Coder 2 listened to select audio recordings (Bird, 2005) for thorough immersion, and we merged each coder’s initial codes (~70–80) to resolve naming conflicts.

• Refinement rounds: After two isolated refinement rounds, ICR remained below 0.70, prompting further adjustments in code definitions; a third iteration achieved ICR > 0.72.

• Final consolidation: In this final iteration, multiple fine-grained or duplicative codes were merged, while broad or ambiguous codes were split into more precise categories. Coder 2 verified which quotes best exemplified each refined code, and any remaining discrepancies were resolved through a negotiated agreement (Campbell et al., 2013).

• Full application: Once the scheme was stabilized, Coder 1 applied it to the remaining four SS’22, ten WS’21, and five WS’22 transcripts.

• 4. ICR Computation (Krippendorff’s Alpha):

We exported the coding assignments into a CSV file, ensuring a nominal scale representation suitable for the K-Alpha online calculator tool (Marzi, Balzano & Marchiori, 2024). Three iterative refinements achieved Krippendorff’s α > 0.72, indicating substantial reliability (Hayes & Krippendorff, 2007). Any remaining discrepancies persisting after the third round were reconciled via negotiated agreement.

Cross-study thematic integration and re-coding previous data

To integrate new findings with prior interview data (WS’21: 12 interviews; WS’22: 7 interviews), we selected two additional interviews from each past dataset and re-coded them using the newly refined framework. A further check yielded α > 0.70, confirming coding reliability. Next, Coder 1 re-coded all remaining prior interviews. Upon cross-analytical consensus discussions, some original themes were merged, re-labeled, or dropped if unsupported. For example:

• “Attention and focus deficits” (from WS’21) folded into “Context switching & other factors” or “Mixed perceptions of time limits.”

• “Mentorship & Helping” was separated from general “Feedback/Teaching” (WS’21 & WS’22) based on the more explicit mentor-like behaviors identified in SS’22.

Themes and saturation

Each study reached saturation within its respective scope and interview guide (Guest, Bunce & Johnson, 2006), yet the protocols evolved over time to address novel dimensions of pair programming. Consequently, the SS’22 study was deemed saturated after six interviews, surfacing two new themes—Theme 9 (“Perceived Task Difficulty & Project Stages”) and Theme 10 (“Context Switching & Other Factors”). Although we designed tasks to have uniform complexity, participants’ subjective perceptions varied. Some found certain tasks easier or harder, noting how pair programming reduced perceived difficulty or benefited particular project stages. Furthermore, context switching was addressed through an expanded set of interview questions.

Following these refinements, the final thematic map contained 12 overarching themes, each representing a facet of participants’ psychological, social, or technical experiences. These themes are reported in detail in the next Empirical Findings section.

Overall role effects (H1 & H1-Cor)

To assess whether intrinsic motivation varied by Role (H1) and remained stable within individuals (H1-Cor), we fit a linear mixed-effects model with Role (Pilot, Navigator, Solo) as a fixed effect and Participant as a random intercept, accounting for repeated measures. Post-hoc Tukey-adjusted comparisons (Table 2) showed a clear hierarchy of means: Pilot > Navigator > Solo. Specifically, Pilot was significantly more motivating than Solo (estimate ≈ +1.60, p < 0.0001), and Pilot also surpassed Navigator (estimate ≈ +0.56, p = 0.0328). This pattern remained consistent across all experimental rounds, indicating stable role-based motivation differences (supporting H1 & H1-Cor).

Interpretation: Participants generally found Pilot the most motivating role, Navigator intermediate, and Solo the least. This satisfies H1 (role differences exist) and shows stability over repeated rounds (H1-Cor).

Model fit and variance

We computed marginal and conditional R² (Nakagawa & Schielzeth, 2013) to assess how much variance in intrinsic motivation was explained by fixed effects (Role, Big Five traits) versus random intercepts (Participant). In the Role × Big Five interaction model, the marginal R² was approximately 0.11, whereas the conditional R² rose to ~0.42–indicating that participant-level differences add ~31% more explained variance. A similar pattern emerged for the simpler Role + Big Five model (marginal R² ~0.085; conditional R² ~0.39). Hence, while Role and Personality account for a meaningful portion of intrinsic motivation, about half of the variance remains unexplained. In the Discussion, we elaborate on potential situational and measurement factors.

Supplemental Material S1 provides additional distributional and diagnostic plots, including Q–Q and residual-vs.-fitted checks that confirm the model residuals are approximately normal and exhibit no notable heteroscedasticity, supporting the appropriateness of our LME assumptions. That material also includes interaction predictions for Openness, illustrating that individuals at +1 SD in Openness show a stronger preference for the Pilot role, while Solo appears less demotivating for those at −1 SD.

Interaction effects of Big Five traits and personality clusters (H2–H6)

To explore how personality modifies these role preferences, we ran two interaction models:

1. Role × Big Five: Treating each trait (O, C, E, A, N) as a continuous predictor.

2. Role × PersonalityCluster: Assigning participants to whichever trait they scored highest on (Openness, Conscientiousness, Extraversion, Agreeableness, Neuroticism).

Table 3 merges these core results, focusing on the key comparisons of Pilot vs. Solo, Navigator vs. Solo, Navigator vs. Pilot, and the “Cluster Insights” (Role differences within each dominant-trait cluster). We interpret these results in light of H2 (distinct personality configurations exist), H3 (role preferences differ by personality cluster), and H4–H6 (trait-specific hypotheses).

Openness (H4): Big Five interactions show a positive difference for Pilot vs. Solo among those high in Openness (+0.53, p = 0.0254), suggesting that creative, exploratory mindsets thrive in the Pilot role. The PersonalityCluster model hints at a smaller, non-significant boost for Navigator. Overall, high-openness developers are particularly motivated in Pilot roles.

Conscientiousness: A discrepancy arises: the Big Five model indicates Navigator is less motivating for conscientious developers (–0.99, p = 0.0006), whereas the cluster model suggests a positive effect for Solo (+1.93, p = 0.0044) and even a mild benefit for Navigator in some cases. Likely, conscientious individuals thrive in structured tasks (Solo), though cluster assignments can overemphasize a single trait at the expense of secondary dimensions.

Extraversion (H5 part): In the Big Five model, Extraversion yields small, non-significant improvements across roles. However, in the cluster model, Extraversion is significantly beneficial for Navigators (+1.58, p = 0.0403), implying that extraverted participants particularly enjoy guiding and communicating at a higher level.

Agreeableness (H5 part): Agreeable participants see negligible differences in the Big Five model, but in the cluster model, Navigator emerges as significantly more motivating (+2.22, p = 0.0002) than Solo. This aligns with the view that cooperation, feedback, and synergy are critical to the Navigator role.

Neuroticism (H6): The Big Five model shows that high-neuroticism developers are less motivated in Pilot or Navigator roles (compared to Solo). Correspondingly, the cluster model strongly supports a Solo preference (+1.87, p = 0.0033), indicating a preference for structured, solitary work that is less anxiety-provoking.

Integrating personality cluster insights with Big Five interactions

The PersonalityCluster model emphasizes each participant’s dominant trait, simplifying the interplay of multiple traits. Despite such reductionism, it largely confirms the Big Five interaction findings:

1. Openness: Both models agree that open-minded individuals excel in the creative, hands-on Pilot role.

2. Extraversion & Agreeableness: Both approaches highlight the advantage of sociability and cooperation for Navigator.

3. Neuroticism: Both suggest emotionally sensitive developers prefer the structured independence of Solo over dynamic, real-time collaboration.

4. Conscientiousness: The key discrepancy arises here; in the Big Five model, conscientious developers find highly dynamic roles (e.g., Navigator) less rewarding, but sometimes thrive in them if they can impose their own structure (per the dominant-trait cluster approach), priming the dyadic collaboration. In practice, conscientious programmers may excel anywhere but especially in Solo tasks, which allow meticulous focus.

Notably, Pilot had the highest overall motivational baseline (Table 2). Therefore, it is possible that the Role × PersonalityCluster interaction model detects fewer “positive boosts” for Pilot because many participants already rated Pilot favorably, leaving less variance to be explained by personality. Nonetheless, Pilot still emerges as a prime choice for those high in Openness.

In short, the cluster approach and the trait-interaction approach converge on most findings, reinforcing that personality-based assignments can amplify or attenuate the inherent motivational differences between Pilot, Navigator, and Solo. Nonetheless, real-world developers often exhibit multiple strong traits—an aspect that pure clustering may oversimplify. This dual-model approach thus provides complementary insights.

Individual variation and example

Beyond group-level effects, certain individuals displayed pronounced shifts in motivation across roles. For instance, a participant under the pseudo-ID “xtoj” experienced a 64.6% increase in intrinsic motivation when moving from their least motivating role (Solo, mean = 13.7) to their most motivating role (Pilot, mean = 22.5). Such a case underscores the practical prospect of role alignment based on personality-driven preferences.

Summary of quantitative findings

In summary:

• H1 & H1-Cor were supported: Pilot proved most motivating, Solo least, and these differences remained consistent across repeated rounds.

• H2 & H3 were validated by cluster-based results showing that Openness, Agreeableness, and Neuroticism meaningfully interacted with Role.

• H4, H5, and H6:

  • Openness (H4) strongly favors Pilot.

  • Extraversion & Agreeableness (H5) show the clearest benefits for Navigator.

  • Neuroticism (H6) finds Solo comparatively less demotivating.

Overall, the results support the value of personality-based role assignments. In very small entities (VSEs), careful role alignment may be–after validated generalizations and adaptations—especially critical given the high impact of each individual’s performance and motivation.

Having established a quantitative basis for personality—role alignments, we next explore how participants subjectively experienced pair programming through a thematic analysis of interview data.

Narrative of themes

While all twelve themes are noteworthy, the following discussion highlights how the final mapping extends or refines earlier findings:

• Pairing constellations (Theme 1). This theme remains among the most frequently mentioned. Participants emphasized that social compatibility and similar skill/work pace led to more honest communication, new friendships, and longer productive sessions. Conversely, extremes in certain traits could create tension, reflecting the interplay of personality and social alignment.

• Feedback (Theme 2) & mentorship & helping (Theme 3). Previously, feedback and teaching codes were often blended under a single umbrella. The new dataset revealed an emergent “mentor-like” role, prompting us to tease out a separate mentorship category. Feedback remains crucial, but participants also described deeper “I felt like a teacher” experiences that enhanced self-efficacy and knowledge sharing.

• Soft & social skills (Theme 4) & psychological aspects (Theme 5). These categories reaffirm earlier insights—e.g., the Hawthorne effect for motivation, emotional well-being, and communication challenges—but the data also illustrate how some students found pair programming a method to practice real-world simulation skills in a more psychologically safe environment than professional settings.

• Role-specific insights (Theme 6). Although identified previously, new interviews more strongly underscored the navigator as leadership aspect and how the solo role offered a mental “breather” for advanced coders. This nuance clarifies why certain traits—introversion and extraversion—might better align with specific roles.

• Time constraints & progressivity (Theme 7). Participants were divided on strict time limits: some valued them for efficiency and fairness, while others were frustrated by unfinished tasks. The merging of multiple time-limit codes (e.g., “Need extra time,” “Rotate after finishing tasks”) into a single code, “Mixed perceptions of time limits,” acknowledges participants’ varied stances.

• Perfect pair programmer’s traits (Theme 8). The new data and re-coding confirm earlier beliefs that high extraversion, agreeableness, and emotional stability are valued. However, the emphasis on “willing to compromise with others” also hints at a synergy between conscientiousness and adaptability in successful pair programmers.

• Perceived task difficulty & project stages (Theme 9).* Newly articulated, it captures how participants found pair programming especially beneficial for complicated tasks or early project phases to avoid disorientation. Despite uniformly designed tasks, subjective difficulty varied, prompting some to note a boost in perceived productivity when working in pairs.

• Context switching & other factors (Theme 10).* Also emerging anew, it highlights that personal health, external stress (exams), or abrupt role changes sometimes hinder focus. This clarifies the prior “attention and focus deficits” theme from CIMPS–WS’21, showing how context switching specifically triggers disruptions.

• Pair-forming processes (Theme 11) & essential software engineering improvements (Theme 12). Both represent re-defined or newly recognized expansions:

  • The Pair-Forming Processes theme explores speed dating for matching, personality-based assignments, or skill balancing as ways to optimize pair dynamics.

  • Essential Software Engineering Improvements emphasizes early defect detection, synergy of differing roles, and a broader range of alternative solutions discovered through pairing.

Overall, the qualitative data corroborate our quantitative results and elaborate how personality alignment not only influences intrinsic motivation but shapes social dynamics, feedback quality, and coping strategies under time constraints or complex tasks.

Seven new tasks (T1–T7) for ISO/IEC 29110 Software Basic Profile and Agile Guidelines

To integrate personality-based pairing into the ISO/IEC 29110 Software Basic Profile and Agile Guidelines’s PM and SI processes, we propose the following seven tasks, mapped onto the relevant PM.1–4 and E1–E7 events:

• T1. Integrate personality assessment in hiring (PM.1)

• – Objective: Ensure new hires fit well with existing team dynamics and motivational needs.

• – Implementation: Administer a Big Five assessment toward the end of recruitment; interpret results to guide role preferences and synergy with current staff.

• T2. Assess multidimensional work motivation (PM.2)

• – Objective: Track the baseline and periodic evolution of each team member’s motivation, e.g., with the multidimensional work motivation scale (MWMS; Gagné et al., 2015).

• – Implementation: Conduct these assessments at major milestones or sprint boundaries to identify shifts in intrinsic or extrinsic motivators.

• T3. Define the Big Five Assessment Strategy (PM.2)

• – Objective: Formalize how and when Big Five assessments are conducted, ensuring ethical handling of personality data and clarifying how it informs role assignments.

• – Implementation: Document procedures for administering BFI-10, safeguarding privacy, and mapping trait profiles to potential roles responsibly.

• T4. Pairing task (SI: E3, E4)

• – Objective: Introduce a dedicated “Pairing Task” into the sprint backlog and track and execute it like any other task during Sprint Execution (E4).

• – Implementation: During Sprint Planning (E3), list pair programming sessions as formal tasks. Pair roles are selected based on personality alignment, but remain flexible if the project or personal circumstances change mid-sprint.

• T5. Measure intrinsic motivation impact (PM.3 & SI: E4, E7)

• – Objective: Evaluate how pairing and role assignments affect developers’ intrinsic motivation, typically using the Intrinsic Motivation Inventory (IMI).

• – Implementation: Administer short IMI surveys after pairing sessions (E4) or longitudinal MWMS at sprint’s end (E7). Summarize findings in the project’s assessment artifacts.

• T6. Review and update pairing strategies (PM.3 & SI: E6, E7)

• – Objective: Continuously refine personality-based role assignments based on feedback from retrospectives and quantitative measures of motivation.

• – Implementation: Combine sprint retrospective discussions (E7) with any relevant data from T5 and sprint reviews (E6), then revise the project plan and the next sprint’s Pairing Tasks.

• T7. Support future planning and knowledge transfer (PM.4)

• – Objective: Document lessons learned about personality-based pairing so that future projects or other VSE teams can benefit.

• – Implementation: Include a final summary in the Project Closure (PM.4), focusing on best practices, pitfalls, and recommended improvements for future cycles.

Mapping to ISO/IEC 29110 PM and SI processes

Figure 1 illustrates how these seven tasks integrate seamlessly into ISO/IEC 29110:

1. PM.1 Project Planning: T1 and T3 help define the role assignments before coding begins.

2. PM.2 Project Plan Execution: T2 remains ongoing to track motivation changes.

3. PM.3 Project Assessment & Control: T5 and T6 measure how well pair programming is working and facilitate adjustments.

4. PM.4 Project Closure: T7 compiles the final lessons learned.

5. SI (E1–E7 events): T4 instantiates pair programming in the sprint backlog (E3, E4), T5 collects daily/weekly motivation data (E4, E7), and T6 uses sprint reviews and retrospectives (E6, E7) to refine approaches.

By embedding these tasks into the existing PM and SI activities, VSE teams can gradually adopt personality-based pairing without overhauling their entire software process.

Triangulation across three datasets and demographics

To enhance robustness, we cross-analyzed three triangulated datasets: WS’21, SS’22, and partial WS’22, observing stable trait–role alignments. In total, 66 participants contributed to the main quantitative analysis (WS’21 + SS’22), averaging 2.21 years of experience (counting academic experience at half), with six females and 60 males. While regionally limited, these samples offer cautious generalization to junior professionals with similar backgrounds. We addressed potential author bias through reflexive thematic analysis (Braun & Clarke, 2022) and maintained high inter-coder reliability (O’Connor & Joffe, 2020).

Future work

Given these limitations, several avenues for future research and development emerge:

1. In situ evaluations: Testing ROMA with professional VSE teams in multi-month sprints would clarify how role reassignments fare under real project scopes, shifting requirements, and potential distributed collaborations.

2. Integration with different personality frameworks: Beyond the Big Five, exploring other trait models (e.g., HEXACO) or combining interest inventories (e.g., RIASEC) might reveal deeper layers of role alignment.

3. AI partner paradigms: Investigating how advanced AI “co-pilot/navigator” tools might offset certain personality mismatches could refine or expand the ROMA framework’s utility, especially for developers high in Neuroticism or Introversion.

4. Cultural and cross-organizational diversity: Testing the ROMA framework in VSEs across various regions and organizational cultures would enhance the framework’s adaptability.

5. Behavioral outcomes and software metrics: Extending beyond motivational constructs, future studies could correlate personality-based role assignments with objective performance indicators (code quality, defect density, lead time) to quantify the overall impact on projects.