Onboarding: How Newcomers Integrate into an Agile Project Team

To frame the onboarding processes discussed in this paper we used the six functions described in Bauer’s framework for successful onboarding [5, 12]. Bauer’s framework is generic to all onboarding environments and situations. We selected this framework to structure our study because it is empirically based, highly cited in many fields, and currently no substantial framework or model exists for agile software development project team onboarding. The six functions in Bauer’s framework [12] are as follows:

Bauer’s [12] framework also includes adjustments that newcomers move through during onboarding. These adjustments are self-efficacy, role clarity, social integration, and knowledge of the culture. We have restricted our study to the six features in the framework because evaluating adjustments requires longitudinal research.

The agile software development team was a unit based in a UK university within the IT services section (ISS). Over six years, the unit increased from two members at inception to 15 at the time of the study. During the case study, the unit acted as a single team following a whole-team approach regardless of how many staff they had. The unit’s remit was to develop mobile applications for the university and investigate ideas and technology for future innovation. The unit worked on new projects and maintained deployed apps and systems.

Team membership and size changed depending on workload, consisting of full-time, part-time, experienced, inexperienced, student, and apprentice members. At the time of this study, there were 6 full-time staff, 3 apprentices and 6 part-time staff. Of the part-time staff 3 had full-time roles within the university and were part-time in this team. The team lead was full-time and had a duel role as Scrum Master and line manager. Apprentices worked full-time for most weeks but attended block courses, typically for one week per month, at their home institute. Student team members usually studied at the university while working part-time on the project team, typically for 2 or 3 mornings or afternoons per week. Most of the team were in their 20 s with little or no previous work experience except the Scrum Master, Product Owner and Conversation Specialist who were in the 35–55 age group and had a range of previous experience. Many of the full-time staff had started as part-time students and gained full-time posts as new graduates. There was regular staff turnover as students and apprentices left after graduating, and full-time staff were often attracted by jobs outside Higher Education.

The team’s onboarding practices are described in the following sections, organised according to Bauer’s framework [12]. Note that all names are pseudonyms.

Long-term recruitment: The unit had a long-term recruitment approach that involved hiring temporary students and apprentices who would work within the team as part-time employees whilst completing their studies. In some cases, these people would finish their degree and then become full-time permanent staff members on the project. This approach provided permanent staff who required minimal onboarding because they had a pre-existing good team fit, and understood the organisation, the unit’s goals, products, technologies, stakeholders, and the teams’ agile approach.

Onboarding during recruitment: During recruitment interviews, newcomer’s knowledge gaps began to be identified. “One of the things I do is in the interviews when we take people on, I try to understand what their understanding of agile is, to see how much of a gap there is …” [TL].

Agile method pack: The Team Lead informed the newcomers about agile practices by sending them a guide, “New team members, I now send them a guide, the principles behind it. A Scrum Guide. I talk about the fact that this is what they do” [TL].

Socialising: The project team made efforts to socialise with and get to know one another because they found this helped newcomers to trust the team and be more confident in interacting and communicating with one another. “For example, practices that we’ve encouraged in our full-time team meeting, we’ll say ‘what can you present to the team that you think is valuable or about yourself?’, you know breaking down those barriers, it could be about anything. So [a team member] recently did one about e-capture and [another team member] did one about his passion for Rubik’s Cubes” [TL]. The whole team was invited to social events, “the different team members will often be going for lunch, that sort of thing. The odd evening here or there, we’d be going for drinks in town or we do our own team Christmas thing…” [SD3].

Role modelling: The more experienced team members noted that role modelling desired behaviours was beneficial for the newcomer and the established staff, “I try and get rid of the stigma … and set an example, and the rest of the team will realise that it’s fine to say ‘I don’t know how to do that. I don’t know what this is or that is, or I need help with this’” [SD3]. Another type of role modelling was shown by the continuous self-learning of new technologies by the established staff, “I do a lot of learning outside of work at the moment, especially with all the new stuff that we’re doing” [PM].

Ceremonies: As part of the immersion approach, ceremonies were explained to newcomers the first time they attended. For example, just before the stand-up meeting, a newcomer would have the process explained so they knew what they were expected to do, “they were very good at explaining everything they did, explaining why they had stand-ups in the morning, and explain the meetings, you know, before and the end of the sprints. They explained that before they happened” [NC4].

Encouraging teamwork: The established team members encouraged knowledge sharing and helping behaviours among the team, “everyone is very friendly, and ask if you want anything and yeah, you are encouraged to talk to people.” [NC3]. The level of trust between newcomers and established staff was perceived as good, “There’s a lot of trust… especially with the student developers as well, there’s a lot of trust for them to do work, … once they’re part of the team, and they fit and work as part of the team, we trust them to do work”. “Everyone is very helpful, very friendly… it feels very inclusive, very inclusive, it’s not sort-of developers and non-developers” [NC3].

Encouraging learning: One newcomer appreciated being encouraged to try new things, “[The TL] is very good at encouraging you to take on more challenging things. … He’ll suggest, why doesn’t [Sally] do that, why don’t you do that [Sally]? Initially, I’ll go ohhh (shouting in confusion and panic!) and then… But in a good way, it is good to push your staff, isn’t it? It is good to learn new things and yeah. Yeah, it is good. Scary but good. Good scary” [NC3].

Empathy: Because some established team members had previously been student members in the team, they could still recall their own experiences and this helped them to understand newcomers issues, “I’d like to think anyway, that we treat the students, especially with my background as a student developer, that we’re all treated as equals. We don’t really have the junior developer syndrome that some teams suffer from where they’re handed lesser tasks or things like that. …Sometimes if a part-time student is only in for 3 h or something, then there might be a situation where we might suggest things for them, just to maximise that time that they have. But it’s more for their benefit because I know how frustrating it is to get into a piece of work and then have to down tools and go to lectures” [SD1].

Pair programming: The Team Lead recognised that pair programming was useful to support newcomers. “When they first come in, I pair them up with a full-time member … the same full-time member for about 2 to 3 weeks until we then release them to work on their own on a particular area.” [TL]. Pairing was also used to learn new technologies, “Where we want skills on a particular technology or something like that we’ll pair up, or equally if we want to teach someone something we’ll pair up” [SD1].

Reimagining yourself: The Team Lead encouraged the newcomers to reimagine themselves in their new role, “when I’ve taken students on and they’ve transitioned to being full-time members of staff, I’ve tried to coach them to say you need to reimagine yourself in the new role. So [newcomer]…, she was an administrator but now she’s a, well technically her title is [new role], but that’s actually different to what she does and she’s had to reimage herself in those new roles because she’s no longer doing the roles that she was doing earlier on” [TL].

Daily stand-up meetings: These meetings were held sometimes twice a day for the benefit of the part-time staff. One developer, with one year of experience on the team, saw the stand-ups as useful for understanding the project status and as a time for getting help, “If you’re stuck on something, don’t know how to do something or you’re just lost, then it’s a good place to air that and usually, somebody will, oh I’ll help you with that.” [SD3]. One newcomer noted that she did not yet understand the language, “If I understood their language, then I would probably understand more” [NC3]. Established members also saw that stand-ups helped newcomers. “A lot of the communication comes at the stand-up in the morning… We also have another, sometimes, in the afternoon if someone’s come in just to get them on board. So we might have two stand-ups” [SD2].

Co-location: Co-location made asking for help and sharing knowledge easier, “…look at this code, or something like that but also, just asking the person you’re sat next to… If you don’t know something, there’s a good chance the person next to you does” [SD3]. Co-location allowed for conversations to be overheard, which helped newcomers, “It does [give a] general sense of what other people doing, even if it’s just overhearing them have, talking between themselves” [NC1].

Signalling: To signal availability and issues the team had developed methods of communicating so members could understand who could be interrupted and who preferred to focus on their work, or if there was an important issue for the team to address. “Sometimes members of the team will wear headphones when they’re really concentrating so you know to stay clear, or you just from intuition just by knowing each other…And I think we’re all accessible to part-time students as well”. “if it’s a particular barrier in terms of the project, then we have little red notices that go on the Kanban board…so that everyone knows there is a barrier and if anyone has a solution … we can discuss and try to break that barrier down” [SD1].

Immersion: (or experiential learning) Newcomers started working in the team from their first day and much of the learning and socialisation was accomplished by being a productive member of the team. For example, two of the established members described the process in a similar way as, “Generally we try to let them get their hands into a piece of work, learn literally on the job, so we give them a sort of induction into what their sort of expectations are in the team, what they can do to get support and all that kind of stuff and just let them loose and fit right in” [PM]. A newcomer’s perception reinforced this, “I was very much thrown in at the deep end, “Here are some meetings. Yeah, let’s go ahead with it,” and very much learning on a day-to-day basis with the team how they do it”. “it’s really largely practice, or very practical, with some explanations when necessary… before we went into the meeting and we were voting with our animal cards and things, that was explained to me before we went in, we do this, so… I got in there and wasn’t surprised by what happened” [NC3].

Self-study: Newcomers who were not aware of agile methods were asked to read about it before starting with the team and were given links to online resources. “In the interviews, we tend to ask them if they have any experience of agile, and if they say no, we say, ‘That’s fine, but we recommend you look into it’” [PM]. The existing project team expected newcomers to self-learn and would request them to do so, “when we took him on, we said ‘you need to do some learning outside of work if you want to continue with the team’” [TL]. For some newcomers, the self-study was self-motivated, “I did a lot of background work …I did lots of reading [about Alexa] on the internet… A couple of courses on Udemy …At home, I am doing Python and Excel, I am doing a course on Excel. And … I have just signed up for, … user stories” [NC4].

Immediate feedback: The team was able to provide face-to-face feedback, as a newcomer explained after the testing of her work, “people do point things out, but in an ok way… but it is always nicely done”. [NC3].

Meetings: Meetings were used to communicate university, department, and team knowledge and concerns. “everyone gets to say something in there. That’s working quite well. It’s nice and relaxed. It’s breaking down some barriers. People are understanding people better, and new learning is coming into the team.” [TL]

Code reviews: Code reviews were used for providing feedback, “We do a group code review each week to see what we’ve been going over, to learn off each other. That meeting is primarily just for the programmers and the apprentices” [SD2]. A newcomer, who had not yet presented at a code review, thought the code reviews useful, “At the moment I don’t quite understand everything. But it is useful because it can be quite scary to have a look at the [code], it makes it a bit more familiar” [NC1].

Testing: Unit tests were viewed as a feedback mechanism and some test-driven development was used during pair programming to assist newcomers, “We do try pair programming, especially with the students… so, when [Martin] started, we actually added some testing-driven development with him to introduce him to what we’re working on, how we work” [SD2]. A newcomer explained, “which is really good, because that extra bit of testing is, and then I can see whether it does what I hoped it will do and if it works” [NC3].

Retrospectives: Retrospectives were used to adjust and improve the agile process, the established team members viewed them as a valuable feedback tool. “We do it at the retrospectives or we give feedback on how we did, what we liked, what we’d improve. So that’s more feedback as a team” [SD2].

Sprint review: Feedback at the sprint review was concerned with the technical matters, “Feedback’s generally kept back for the sprint review, so before a retro, we do a review session where we demo the build. Hopefully, it works and we can celebrate, or there will be some critique about the way it’s been implemented or the design choices, or that kind of stuff” [SD1].

Sprint refinements: The team used these sessions to discuss and refine user stories before sprint planning sessions. “We have Sprint refinements before we do a planning, where we go through each of the work items and ask a lot of questions” [SD3].

Small tasks: Smaller tasks were given to part-time newcomers for practical reasons. “We’ll give smaller tasks to the students because there’s just not enough time… if we’ve got a small user story, say, getting the next timetable event from an API, that’s something that we could see a student doing” [SD2]. Minor bug fixes were often an entry point for newcomers, “I’ll have like a list of bugs that need fixing because generally, we don’t want to pull the full-timers out of sprint.” [PM].

Task allocation: A mixture of self-selection and supervisor selection was used for task allocation. Considerations of expertise were a factor in allocating tasks. “On the bigger tasks, sometimes [TL] will delegate who to do that … But usually, we just pick up the next task on the board. If there’s no task on the board, then we have to ask [the administrator] or [TL] to bring it in or liaise with the product owner…” [SD2].

Product demo: Feedback on the product was given by Product Owners to the team, “Other bits [of feedback] will be demos to the business. So, as developers, we try to talk to the actual product owners quite regularly” [SD1].

The findings from the analysis are summarised in Table 2.

Onboarding challenged newcomers and established team members. Challenges identified in the analysis included empowerment, mindset change, accommodating part-timers, conveying agile principles, and adjusting to changes in team composition.

Empowerment: was a constant issue within the team. The Team Lead identified a difficulty with onboarding younger newcomers who had never worked in a self-organising empowered team. He thought they needed to be helped, “when they’re just out of university and they’ve come from an academic background that doesn’t teach team work very well, doesn’t teach about empowerment … sometimes in conversations, they may turn to me in terms of a position of authority and I’m like, no you go and do that, so I’ve tried to set up things where they have their own meetings and they run their own meetings so I may well initiate something and step out and say well there you go, you don’t need to talk to me anymore, just sort it out yourselves.” [TL]. However, at times of pressure, a command-and-control approach did emerge, “and then I’ll pull someone out of sprint and go, “This needs fixing,” or I’ll say, “This will be fixed at the end of the sprint, depending on how urgent it is” [PM].

Mindset change: Project team members tended to rely on senior staff to maintain their agile processes, “If me or [the TL] aren’t in the office, stand-ups don’t happen, and so we’re really trying to encourage, ‘This is your meeting, this is for you to help each other’” [PM]. A constant effort was made to empower newcomers, “We try to leave it down to them what they want to do” [SD1]. Related to the issue with empowerment, is the problem of perfectionism. Newcomers found it hard to adopt an experimental mindset, “Because they’re so new, they also don’t understand how to tackle problems. It’s a case of, ‘well just start, just get started it doesn’t matter if you throw it all away’ … it’s a mindset thing about trying to find the perfect solution the first time you do it” [TL].

Accommodating part-timers: A recurrent theme among the team was connecting with, and sharing knowledge with, the part-time newcomers. Both established members and part-time newcomers saw this as an issue, “…for part-time members or [those] who can’t attend, and it’s probably trying to find ways of bridging the gap in the communications that occur. So, it’s kind of every time we’ve had a retro everyone has said, communications need to improve. It’s like you’ve said it, but you’re not actually doing it.” [TL]. A part-time newcomer commented on the difficulty of finding out what had happened in the project after an absence, “because they’ll just talk to each other and just figure something out, and then you won’t find it documented anywhere, or it won’t even be in the [TFS]” [NC3].

Conveying agile principles: The established members had high expectations of newcomers and struggled to convey agile principles. “And we now have a very high bar of workforce that are now the team, are highly motivated and through that, there’s an expectation that you have to fit into that kind of ethos as well, and that becomes a barrier for recruiting new students because the bar is so high.” [TL]. The Team Lead thought the main onboarding issue was integrating relatively young and inexperienced part-time newcomers, “It’s just them being immersed in it, and for part-time that’s hard, because up to 15 h a week, whilst doing other learning, and whilst you’re young and having a social life, and everything else. Finding space in their brain for this is hard, and it’s being able to get over the principles and culture, which is what I want to focus on” [TL].

Adjusting team composition: Over time the team evolved to consist of more established members and fewer newcomers. This balance improved their ability to continuously improve. “We’ve been through a lot of iterations of how we approach our work, and I think we’re hitting a sweet spot of getting things done, …with having more full-time members we thought there was value in doing those [sprint refinements]” [SD1].