This study investigates the relationship between self-efficacy and participation in software development team meetings among computer science students. Drawing on Bandura’s theory of self-efficacy, the study explores whether students who rate themselves higher in confidence also contribute more frequently and in different ways during group meetings. Using a mixed-methods approach, data were collected from three project teams in a second-year Software Project course at TU Delft. A domain-specific self-efficacy survey was filled in by all participants, and their meeting contributions were thematically coded into categories such as planning, technical input, and social interactions. Quantitative analysis revealed a positive correlation between self-efficacy and overall contribution frequency, particularly in technical and planning discussions. Qualitative observations showed that group dynamics—such as dominant speakers and team culture—can moderate this relationship, sometimes overshadowing confident team members

In this project, the topic of collaboration in computer science education was researched, specifically regarding the correlation between prior programming experience and task distribution in student software development projects. Students selfreported prior programming experience, including their years of study, years of coding experience, their experience rank from 1-10, and their experience compared to their classmates via a survey. A thematic analysis of transcriptions of weekly sprint meetings was then conducted to capture students’ reasoning behind task allocation. Additionally, a quantitative analysis correlated self-reported experience levels with Git metrics including task types (taken from tags), task difficulty (weight), and task reassignment frequency (assignees). While the quantitative analyses found no significant correlation between prior experience and task distribution, the thematic analysis found that students often cited prior experience, in addition to personal interest and time constraints as common reasons for task distribution decisions. These findings suggest that task allocation is affected by multiple factors. While prior experience may have an influence, other factors are likely more impactful.

One of our first observations working on this study was that all teams used their own form of Agile, borrowing elements from frameworks like Scrum, but ultimately adapting their collaboration methodology to fit their own projects and preferences. This led 2 of the 3 teams to have a mix of both technical and organisational subjects planned for discussion during meetings.

One of the groups went a step further and employed regular 2--7 hours long in-person working sessions (including breaks). The first hour of one of these sessions was recorded and analysed, since it was in preparation for an upcoming TA meeting and consisted predominantly of organisational discussions akin to a daily Scrum meeting. This made it harder for us to interpret their recording, as many of their discussion threads had started before and ended after our observation periods.

Cyclomatic complexity often serves as a proxy for code quality. While it has been previously studied within education, its relationship with prior programming experience remains unclear. This study analyzed the correlation between different experience metrics, including total years of programming experience, years of experience in industry and in academia, and cyclomatic complexity in student projects. A thematic analysis of task difficulty further contextualized the findings. Results indicated mostly no significant correlations between prior experience and complexity metrics, with only two significant correlations found. While total years of experience and experience in industry showed to be negatively correlated, experience gained in academia showed no consistent findings. The findings suggest that experience alone does not explain complexity scores, indicating that when used as an evaluation method in collaborative projects the results may be influenced by contextual factors such as project settings and task types