Source-linked AI summary
Group development and group maturity when building agile teams: A qualitative and quantitative investigation at eight large companies
Lucas Gren, Richard Torkar, Robert Feldt
TL;DR
The paper examines how group maturity relates to building agile teams, a connection the authors describe as underexplored in agile research. It combines qualitative practitioner interviews with survey-based analysis and finds overlap between agile-team descriptions and mature-group characteristics.
Problem
The paper addresses limited research on how group-development psychology connects to building agile teams.
Source: §1 · p. 3, §5 · p. 29Method
The authors analyze practitioner interviews and survey data relating agility and group-development measurements.
Source: §1.1 · p. 3Results
Practitioners identify group issues as key success factors, and agile teams share characteristics with mature groups.
Source: §5 · p. 28Takeaways & Limitations
Adding group maturity to descriptions of agile teams could help explain agility and partly define an agile team.
Source: §6 · p. 30Both measurements were self-reported at the individual level, so the connection reflects individuals’ perceptions of group work and agility.
Source: §5 · p. 28
Abstract
from arXiv · showhide
The agile approach to projects focuses more on close-knit teams than traditional waterfall projects, which means that aspects of group maturity become even more important. This psychological aspect is not much researched in connection to the building of an "agile team." The purpose of this study is to investigate how building agile teams is connected to a group development model taken from social psychology. We conducted ten semi-structured interviews with coaches, Scrum Masters, and managers responsible for the agile process from seven different companies, and collected survey data from 66 group-members from four companies (a total of eight different companies). The survey included an agile measurement tool and the one part of the Group Development Questionnaire. The results show that the practitioners define group developmental aspects as key factors to a successful agile transition. Also, the quantitative measurement of agility was significantly correlated to the group maturity measurement. We conclude that adding these psychological aspects to the description of the "agile team" could increase the understanding of agility and partly help define an "agile team." We propose that future work should develop specific guidelines for how software development teams at different maturity levels might adopt agile principles and practices differently.
1. Introduction
The paper asks how group maturity connects to building agile teams, a question motivated by the limited research on group-development psychology in software engineering. It investigates practitioners’ work and the relationship between group development and agility using interviews and survey analysis.
1. Introduction
- Agile work relies on cooperation and self-organizing teams, while distance can complicate communication, trust, culture, and knowledge management.The study targets group-development aspects that could help explain why some agile transitions succeed and others do not.Source: §1 · p. 2
- Group-development aspects are underexplored in software engineering, despite research linking mature groups with effectiveness and project performance.The authors note that only one article had addressed agile work-groups and group psychology, while prior research associated maturity with faster project completion and other performance outcomes.Source: §1 · pp. 2–3
- The authors define group development as a work-group’s process of maturing over time and distinguish project success from project-management success.They propose studying the connection between group maturity and agile teams as a potential source of guidance for agile project management.Source: §1 · p. 3
- The authors report that practitioners address group-development issues and that survey results support adding this perspective to agile-team models.Their stated contribution is an analysis of practitioner work alongside survey data from 66 employees.Source: §1 · p. 3
1.1. Research Question
- The study asks how group maturity is connected to building agile teams.It aims to describe connections found in qualitative and quantitative data and explore whether group-development psychology can inform agile implementation.Source: §1.1 · pp. 3–4
- The study combines in-depth practitioner interviews with survey-based correlation analysis of agility and group-development measures.The authors chose Sidky’s survey tool because it targets behavior connected to agile processes rather than simply asking which practices participants use; they also describe agility measurement as difficult and context-dependent.Source: §1.1 · pp. 3–4
2. Related Work
The related work frames teams as groups with shared goals and effective ways of working, and presents Wheelan’s four-stage model as a way to understand group maturity. It also reviews tools for measuring group development and agility, noting challenges in measuring agility consistently.
2.1. Groups and Teams
- A team is a work group with shared goals and effective methods, and the authors report no prior studies of group development in software engineering.The cited Wheelan and Hochberger study classified 17% of groups as teams; the authors say they lack an estimate of software-engineering teams’ maturity relative to other fields.Source: §2.1 · p. 4
2.2. Wheelan’s Integrated Model of Group Development
- Wheelan’s Integrated Model of Group Development describes four stages, from dependency and inclusion through work and productivity.The model is connected to the Group Development Questionnaire, which measures group maturity across the four stages.Source: §2.2 · pp. 4–5
- Stage 1 groups seek safety, inclusion, leader direction, and predictable interaction; Stage 2 conflict helps clarify roles, goals, and norms.Stage 2 disagreements require participation and conflict resolution to develop shared values, procedures, trust, and cohesion.Source: §2.2 · pp. 5–6
- At Stage 3, roles increasingly reflect competence, communication becomes more task-focused, and conflicts are managed more effectively.Stage 4 emphasizes task accomplishment alongside sustained cohesion, participatory decisions, feedback, and continued performance.Source: §2.2 · p. 6
2.3. The Group Development Questionnaire (GDQ)
- The 60-item Group Development Questionnaire measures energy invested in each stage; its GDQ4 scale has been associated with effectiveness measures across fields.Examples cited include project completion, student test performance, and intensive-care staff outcomes.Source: §2.3 · p. 7
2.4. Agility Measurement
- Agility is difficult to measure consistently, and the authors define agile maturity as a spectrum of behavior they consider more agile than traditional project approaches.They use behavior-oriented measurement rather than simply counting practices, while noting that different agility tools have produced different results for the same teams.Source: §2.4 · pp. 7–8
- The study uses categories derived from a partial validation of Sidky’s Agile Adoption Framework, treating quantitative agility results as supplementary to interviews.The framework organizes agile levels, principles, practices and concepts, and items or indicators; the authors caution that quantitative agility measurement is difficult.Source: §2.4 · p. 8
3. Method
The method section describes assessing agility and group maturity, then correlating those measurements.
3. Method
3.1. Participants
Participants were recruited through contacts mediated by SAP America, while the study includes interview and survey participation across companies. The company accounts describe different starting points and challenges in adopting agile approaches.
3.1. Participants
- SAP America mediated most participant contacts through an online internal experience forum; researchers did not select particular teams or have prior relations with participants.Table 1 is identified as the participant and data-collection overview.Source: §3.1 · p. 8, Table 1 · p. 9
3.1.1. The agile journey at Company A
- Company A had ten agile projects underway using tailored Scrum and Kanban, with the main challenge being a shift toward agile principles and organizational thinking.The company had initially intended to start three teams but launched ten, and retained some project-management control mechanisms.Source: §3.1.1 · p. 9
3.1.2. The agile journey at Company B
- Company B had four agile projects underway after beginning with one pilot, and was formalizing its process with release planning, user stories, and tracking tools.Its challenges included starting with a single low-profile pilot and integrating the sprint team into the surrounding organization.Source: §3.1.2 · p. 10
3.1.3. The agile journey at Company C
Companies C–E describe agile transitions from varied prior processes, using practices such as Scrum ceremonies, lean adaptations, pilots, and cross-functional coordination.
3.1.3. The agile journey at Company C
- Company C reported higher throughput, shorter delivery cycles, better alignment with end-user needs, and stronger partnership between IT and business.The transition was supported by agile coaches and external experts before the company improved its process internally.Source: §3.1.3 · p. 10
3.1.4. The agile journey at Company D
- Company D moved from long waterfall projects that often missed requirements or budgets toward a lean journey and adapted agile practices.A third-party consultant supported a pilot, with developers pairing with vendor developers; the organization retained a culture of defining requirements before development.Source: §3.1.4 · pp. 10–11
3.1.5. The agile journey at Company E
- Company E began with low transparency and ad hoc prioritization, then piloted Scrum and applied agile concepts across multiple areas.Its portfolio backlog identified the department acting as product owner, and sprint planning separated backlog review from task planning for three-week sprints.Source: §3.1.5 · p. 11
3.1.6. The agile journey at Company F
Company F used supported start-up squads during its transition, while Company G’s teams varied in composition, practices, and experience with agile.
3.1.6. The agile journey at Company F
- Company F’s start-up squads initially worked alongside teams, sometimes facilitating ceremonies until Scrum Masters could take over.The organization cited visibility and accountability as its largest benefits and had both waterfall and agile projects.Source: §3.1.6 · pp. 11–12
3.1.7. The agile journey at Company G
- One Company G team used Scrum to increase customer contact and delivery speed despite challenges from developers being non-collocated and not fully dedicated.Its requirements remained fairly stable during projects.Source: §3.1.7 · p. 12
- Another Company G context used one product owner across two teams and clarified “done” as finalized, tested, and reviewed.The teams used two-week sprints and regular meetings with the product owner.Source: §3.1.7 · p. 12
- A third Company G project was business-driven and innovative, with continuous improvement helping refine an initially undefined agile process.The business organization came to support the process and actively check and accept the backlog as the leading project artifact.Source: §3.1.7 · p. 12
3.1.8. The agile journey at Company H
Company H’s safety-critical enterprise-system project worked within fixed waterfall stage gates while using agile methods between them.
3.1.8. The agile journey at Company H
- The project was stopped shortly after the survey when top management included it in a broader cost-saving effort.Its background was based on a short, unrecorded phone interview with the Scrum Master.Source: §3.1.8 · p. 13
- The Company H project used two-week sprints between fixed stage gates, with end-cost calculation required for the overall safety-critical system project.Requirements were documented at a day-five meeting rather than as user stories, while prototypes were shown to the customer early.Source: §3.1.8 · p. 13
3.2. Interviews
Semi-structured interviews investigated agile transitions and group development, using comparative questions and content analysis of interview transcripts.
3.2. Interviews
- The interviews sought transition details that might not appear in the survey and deeper insight into group development and maturity.Questions compared earlier processes with changes after agile was introduced.Source: §3.2 · p. 13
- Interview questions covered organizational agile history, prior and current methods, training, team maturity, cohesion, job satisfaction, and organizational fit.They also asked about geographically distributed members and what was working or not working.Source: §3.2 · pp. 13–14
- Recorded interviews were transcribed verbatim, then content analysis categorized transition statements by group-development aspects and counted how many interviewees raised each aspect.The interview results were summarized in Section 4.1.Source: §3.2 · p. 14
3.3. Surveys
The surveys combined an agility questionnaire with GDQ Scale 4, using six groups of items in total. They measured responses on five-point agreement scales and covered work and productivity alongside five agility factors.
3.3. Surveys
- The online developer survey combined an agility measurement tool with GDQ Scale 4 in 31 items rated from 1 to 5.Managers selected teams with varied performance or maturity; the survey included collocated and distributed team members.Source: §3.3 · p. 14
- This study added 21 quantitative responses—47% more than the earlier dataset—and introduced factor-level correlation analysis.Earlier data overlapped with Gren et al. (2015a) and Gren et al. (2015b).Source: §3.3 · p. 14
- GDQ Scale 4 measures effective group work through organization, culture and norms, and external relations.The scale contains 15 items; the full 60-item GDQ is required to identify a group’s developmental stage.Source: §3.3 · pp. 14–15
- The agility measurement grouped items into Dedication to Teamwork and Results, Open Communication, Agile Planning, Leadership Style, and Honest Feedback to Management.The survey’s example items address such topics as teamwork, planning, manager input, and constructive disagreement.Source: §3.3 · pp. 15–16
3.4. Procedure
The researchers conducted manager interviews to understand organizational experiences with agility and group maturity, and anonymously surveyed employees across the participating companies.
3.4. Procedure
- Ten open-ended interviews lasting 30–45 minutes were conducted with managers from seven of the eight participating companies.The interviews sought qualitative insight into organizational journeys toward agile work and group maturity.Source: §3.4 · p. 16
- Of 109 employees emailed the online survey, 66 responded, a 61% response rate; responses were anonymous to managers.A manager sent one email reminder in one organization, and completion took about ten minutes.Source: §3.4 · p. 16
3.5. Quantitative Data Analysis
The quantitative analysis treated its results as a complement to the qualitative findings, given the relatively small sample. Because factor scores showed non-normality, the researchers used Spearman rank correlations.
3.5. Quantitative Data Analysis
- The quantitative findings were treated as a supporting complement to the qualitative analysis because the sample was relatively small.The study included 66 responses from four company contexts; its agility measurement had not been validated, although GDQ was validated.Source: §3.5 · p. 16
- Significant Shapiro–Wilk tests indicated non-normality across all six factors, so the analysis used Spearman’s ρ rather than Pearson’s r.The researchers examined frequency histograms for the factors and used a rank-based method that also accommodates tied ranks.Source: §3.5 · p. 16, Figure 2 · p. 17, Figure 3 · p. 17
4. Results and Analysis
Interviewees connected successful agile teams with group development, while survey measures showed a significant positive relationship between agility factors and group maturity. The findings also highlight how leadership, team interaction, and context shape the transition.
4.1. Summary of the Results from the Interviews
- All ten interviewees reported higher job satisfaction after adopting agile, commonly attributing it to empowerment and team spirit.Interviewees cited autonomy, ownership, influence, and involvement in decisions; seven named team spirit as the main reason for increased satisfaction.Source: §4.1 · pp. 20–21
- Interviewees described leadership as stage-dependent: newly formed teams may need direction, while conflict management and continued guidance help teams progress.One account linked task volunteering problems to a group’s lower maturity; the paper says early directive leadership should not be viewed as failure.Source: §4.1 · pp. 21–22
- Interviewees generally favored collocation, but teams also used virtual ceremonies, technology, and site visits to build team spirit across distributed settings.Distributed teams continued to face challenges with camaraderie and team identity; daily stand-ups and intensive meetings were among the practices described.Source: §4.1 · pp. 22–23
- Agile’s daily rhythm and ceremonies were described as disciplined, increasing visibility and accountability while surfacing problems such as over-allocation and delayed work.Interviewees differed on stress: one attributed lower stress to a stable rhythm and manageable increments, while another connected increased stress to prototyping and product-owner behavior.Source: §4.1 · pp. 21, 23, 24
- Some teams were already working in ways compatible with agile before formal practices began, and interviewees said high-performing teams adopted those practices easily.One company used indefinite agile teams focused on products, in contrast with project teams that could disband just as momentum developed.Source: §4.1 · pp. 24–25
- Nine interviewees explicitly connected group development with building agile teams, but the authors describe the relationship between practices and maturity as an overlap or interaction, not a settled causal direction.Interviewees also identified behavioral challenges involving communication, negotiation, feedback, responsibility, and adapting to change; the authors caution that agile practices alone do not make a team high-performing.Source: §4.1 · pp. 24–26
- Interviewees valued both individual and teamwork skills, while accounts also suggested that behavior and personality can vary with group context.One interviewee reported that introverted members took more space on an agile team; the authors caution against attributing integration difficulties solely to individuals.Source: §4.1 · pp. 25–26
4.2. Correlation between GDQ4 and the agile measurement
- All agility factors were significantly correlated with GDQ Scale 4 mean values, with participants’ higher agility scores accompanying higher group-maturity scores.Table 3 presents the correlation matrix; the supplied passage does not provide its individual coefficients.Source: §4.2 · p. 26, Table 3 · p. 27
5. Discussion
Practitioners describe group-development work as central to building agile teams, and the study finds overlap between agile-team descriptions and mature-group characteristics. The discussion also qualifies these findings by measurement and sampling limitations.
5. Discussion
- Practitioners identify group issues as key success factors, and describe agile teams in ways that overlap with high-performing teams in social psychology.Interviewees indicate that group development needs sustained attention during an agile transition, beyond implementing a concrete process.Source: §5 · p. 28
- The authors suggest group-development psychology could help explain team agility and inform agile implementations, while acknowledging that this potential remains to be explored.They propose that defining an agile team partly as a high-performing team from a psychological perspective could make the concept easier to understand.Source: §5 · pp. 28–29
- The correlation analysis reported that the highest correlations between agility and group development were for GDQ4: Dedication to Teamwork and Results (ρ = .416), Open Communication (ρ = .462), and Agile Planning (ρ = .473).The authors state that agile factors try to pinpoint much of what is captured in group maturity; their internal correlations support their internal consistency.Source: §5 · p. 28
- Group-development theory gives six months as the mean time for a group to become high-performing; groups meeting for less may also be less agile.The paper presents this as a possibility based on group-development theory, not as a measured study result.Source: §5 · p. 28
5.1. Validity Threats
- The study's connection is between individuals' self-reported perceptions of group effectiveness and agility, rather than independently assessed team-level outcomes.The authors also caution that the agility measure was not thoroughly validated, the survey included 66 participants from four organizations, and both study components have low external validity.Source: §5 · p. 28, §5.1 · p. 29
5. Discussion
- The discussion notes that behavioral software-engineering topics are often absent from computer-science curricula, and interviewees said successful coaches acquired such knowledge through other education or independent reading.Source: §5 · pp. 28–29
- The authors argue that immature groups may need clearer, more directive leadership before a Scrum Master can withdraw and allow self-organization.Early-stage groups are described as needing safety, inclusion, order, and structure; the discussion also notes lower correlations for Leadership Style and Honest Feedback to Management with GDQ Scale 4.Source: §5 · p. 29
5.1. Validity Threats
- The authors describe the work as an exploratory, descriptive first step and caution against generalizing individuals' perceptions to groups.The qualitative interviews support asking practitioners about their perceived connections, while the survey is presented as a complement rather than a basis for broad generalization.Source: §5.1 · pp. 29–30
6. Conclusions and Future Work
The study concludes that agile teams share characteristics with mature groups, offering a psychological perspective that may help explain and partly define an agile team. It proposes further measurement and research to develop maturity-sensitive guidance for software teams.
6. Conclusions and Future Work
- Interviews and survey data indicate that agile teams share many similarities with mature groups, which the authors say could partly help define an agile team.Source: §6 · p. 30
- Future work could develop guidelines for how software teams at different maturity levels adopt agile principles and practices differently.Source: §6 · p. 30
- The authors propose studying additional group-development stages, code quality or productivity, larger individual- and group-level samples, concrete agile practices, and team communication.They suggest So and Scholl's validated survey tool (N = 227) for studying concrete agile practices, and mention verbal-interaction analysis or chat-log mining for communication research.Source: §6 · p. 30