Experience Report

What have we learned from recruiting and onboarding for agile teams?

About this Publication

Recruiting for an agile team and ensuring a decent onboarding for the new recruit, are not trivial activities in a world, where turnover statistics indicate that professionals change jobs more often than before. As agile teams strive for continuous improvement, we wanted to share our experience on how teams can also improve recruitment and onboarding areas, which will definitely have an impact on their success and happiness. Our message is, recruitment and onboarding are too important to be left solely to managers and human resources. Agile teams can get the most value by being more active in both recruitment and onboarding.

1.     INTRODUCTION

Ding! You receive an invitation to a breakfast meeting for a new colleague joining your team! But wait a minute… who/what/why?“.

Traditional recruiting and onboarding efforts—which were purely managerial tasks—disregarded the knowledge teams had, and treated all newcomers with the same onboarding plans designed per role. This surfaced as a problem, when we reformed our organization a few years back.

In the beginning of our agile journey, we had observed cases such as a manager, with all good intentions, kept adding more people to a well-functioning team with the expectation of increasing velocity, until the team ended up in a suboptimal state in terms of performance. Suddenly we observed that team members were complaining about becoming idle despite team had a properly refined backlog, communication quality dropped, and ability to swarm around work items impaired. We also observed cases, where managers could easily make wrong hiring decisions simply because they missed the needs and the insights due to not being close enough to the teams any more. Finally, we also observed decent recruitments being ruined by rigid and one-size-fits-all onboarding plans, which didn’t match the teams’ reality.

In this report, we will tell the story of how we addressed these challenges, and how we brought our agile teams into the heart of recruitment and onboarding process.

2.     Background

SimCorp is an investment management software producer, which is a successful player in the market, having 49 years of history with software development and organizational approaches. We, Christian and Ender, have been lucky and proud to be able to contribute to changing the mindset around how SimCorp delivers value to clients. Practical effects and results of these efforts can be seen in many different areas, as explained in a former experience report by our colleagues in SimCorp [Cook et al].

In SimCorp, managers and human resources traditionally took care of creating job advertisements, posting them in different channels, conducting interviews, and deciding on the new employee. They could as well involve a subject matter expert and benefit from automated tools, in order to help with the assessment. After the recruitment, managers made sure that there was an onboarding plan for the new employee.

Although traditional methods are based on good intentions and get improved by time, we experienced that they failed to meet the needs of the agile teams that we worked with – regardless of software development or not. We also realized that the text-book approach of keeping the teams intact for relatively longer periods were not easy in practice, as professionals tend to change jobs more frequently than in the past, hence recruitment and onboarding became more important than before for our team’s well-being and success.

We have recognized the challenges in recruitment and onboarding areas, and started experimenting with different approaches at an early stage in SimCorp’s agile journey. We have been wearing hats of Scrum Master and Development Manager—both roles being associated to agile teams—though we never limited us to our role definitions and took initiatives with a relentless improvement mindset. In this report, we would like to share our experience and provide a faithful account of our initiatives that took place in the last several years.

3.     Our Story

In an ideal world, after an agile team is formed, preferably by self-organization [Harre and Lohmann], a certain level of stability is expected in terms of team membership. Yet the world is far from being ideal in that sense, and it is normal to expect team membership changes due to various reasons, and our company and teams were no exception. Being aware of the effects of membership changes, such as the Tuckman’s stages of group development, helped us in understanding the consequences, yet we were sure that there were more we could do about it. We decided to put a little extra effort in finding a better fit for both the candidates and the teams, followed by ensuring a better onboarding. We experienced positive returns such as a healthier team atmosphere. Our story is about what we did before, during and after recruitment.

3.1        SimCorp Organization

We are following the Scaled Agile Framework (SAFe) in the majority of our product development organization, though we also have a part that is heavily inspired by the Large-Scale Scrum (LeSS). We have over sixty agile teams, most of them being Scrum teams, and the remaining are using Kanban.

On top of the agile roles that are defined by SAFe and the Scrum Guide, we have a role called Development Manager (DM) that is dedicated to growing teams and individuals, and ensuring focus on long term and strategic initiatives as opposed to short term interests and daily operations[1]. A DM typically works with four agile teams, and serves as the line manager of those complete teams. The DM has the responsibility to recruit and onboard new team members.

3.2        Before Recruitment: Continuous dialogue on the needs

Agile teams and DMs have an ongoing dialogue on team’s wellbeing and capabilities. Regarding identifying the skills and capabilities needed for a team, DM can follow different practices.

One of the practices that Ender uses as a DM is, Team 1:1s, which resemble individual 1:1s though the focus is on the teams’ collective needs and growth. This provides a healthy continuous dialogue and alignment. Learnings and outcomes of Team 1:1s, are the points that are not covered in agile ceremonies, but still relevant to improving the team formation. For example, needs for certain technical skills, or possible improvements in the team composition, even topics such as whether the Agile Release Train (ART), that the team is part of, is the best fit considering the team’s capabilities. We should stress that these periodical meetings have no intention of overlapping with the existing meetings such as iteration reviews and retrospectives, and similar to the DM role, they intend to cover gaps in the frameworks that we are using.

Another practice that one of our colleagues promoted is called the Dream Team Exercise, where the team can regularly express, how a dream team would look like, focusing on the skills and capabilities. This exercise can be facilitated physically or virtually, by collecting team members’ inputs on how, they individually would like to see the capabilities of the team for the future, followed by open discussions to understand each other better and converge on the team’s needs. In the end, DM will be equipped with the team’s own perspective of the team’s future formation, which is a very valuable input for upcoming recruitments or training investments. We should as well, based on experience note, that this will only paint one side of the picture and similar inputs from other stakeholders such as ART leadership team[2] in this case.

Obviously, the DM also interfaces upper management and maintains similar communication with stakeholders in terms of defining the needs. For example, in the SAFe setup, DM also collects information regarding the needs based on the product roadmap and strategy from Product Managers and System Architects, and other roles. Thus the traditional reflex of replacing a leaving team member or ramping up when suddenly client requests surge is replaced by an ongoing dialogue with all the stakeholders including the agile teams, at the same time avoiding cognitive biases that the DM might have.

3.3        Before Recruitment: Team Preferences

After we identify the needs and get a green light with recruitment, the next step is finding the right candidate. Assuming that the candidate will be part of a certain team, we perform a Team Preferences Workshop with the team, so that we can identify the details in terms of the needed profile and tailor the recruitment process based on the team’s preferences. A practical approach we use, is to collect all the sought after qualities and then prioritize those, using voting. The result is used in the recruitment process, especially in screening the applications and interviewing the candidates. In Figure 1, you can see a real output of a Team Preferences Workshop that Ender ran with one of his scrum teams, Cirrus. Here, a virtual board is used to collect inputs, which are categorized and numbered, and the items with most votes are selected in the right most column.

Figure 1: Artifact of a team preference exercise.

An often overlooked part of recruitment is the preparation of the job announcement. Reusing old job announcements and not paying attention to drafting a good text are examples of pitfalls. In our practice, DM prepares the job ad and then asks for feedback from the team and the stakeholders. We have also tried to do mob-writing—team and DM—of the ad. In our experience, the DM might not have the best insights, hence involving the team would produce a much more accurate job ad.

We suggest also asking feedback from the applicants at the end of the interview round. Our experience shows that the feedback from especially the team members and the applicants make a huge difference in reaching the right profiles and finding a better fit. We observed higher number of qualified candidates applying to our positions, after involving teams and asking for feedback from the real applicants.

Another overlooked part is the power of collective ownership and the team’s network. In SimCorp the recruitment is a DM responsibility, however we encourage all the team (and “team of teams”) members to co-own the recruitment in the sense that they also activate their network and actively look for their next colleagues. This approach paid off especially when we recruited for a recently formed mission-critical ART, called Phoenix, that is aiming to enable cloud transformation of our product, where we reached to qualified candidates from our own colleagues’ networks.

Our feeling is that leaving recruitment to only DMs’ efforts and simply relying on job ads, prolong the process and risk not reaching strong candidates.

3.4        During Recruitment: Recruitment Canvas and Team Interview

DMs typically collect applications using dedicated software, together with skilled professional recruiters. Using the organization’s needs and preferences, DM’s screen the applications and identify the candidates to be invited to interviews. An important point is the awareness of cognitive bias and using systems to avoid that [Dabrytski]. Using a Recruitment Canvas where all the candidates will be evaluated based on the same criteria and given a numeric score on each criterion (no matter how subjective the score is) ensures avoiding intuitions and biases. Our experience shows that, our memory and intuitions can easily trick us and having a recruitment canvas did surface such situations. Below is a sanitized example of a recruitment canvas, where the names are artificial and sensible data is removed. Assigning the scores in each cell is subjective, yet the total scores and visibility of all the criteria and the process gave the value for us.

Figure 2: A Recruitment Canvas for a team member recruitment.

The DM takes the first round of interviews where the aforementioned tools such as team preferences and recruitment canvas will be utilized along the way. After the first round, the most promising candidates— decided by DMs assessment, as well as agile teams’ opinion based on the application and test results—are invited to the second round which is run by the team. Obviously, the team’s time is very valuable and should not be wasted, hence the DM will make sure that only the best candidates are invited, and the team can be represented by members who are both volunteering and interested in running the round. As Scrum Masters (SMs) we also orchestrated this process of team interviews without the involvement of the DM at all. In the beginning it was questioned if this was a good use of our time and the team’s time. We always explained the potential consequences of ending up with suboptimal recruitments who would leave the team soon and damage the team dynamics. We also reminded prolonged frustration of going through repeated recruitment processes, when such suboptimal recruitments happened.

We call the second round of interview as Team Interviews, and these rounds get better with practice. We have found that having a preparation workshop where the interviewer group (that is a subset of the agile team) would go through their interview strategy is very beneficial. This gave us more fluent and structured interviews. For the teams which never had tried to do interviews, the DMs would facilitate and coach this workshop. We saw as soon the team had some experiments in recruitment the DM’s presence was not needed. When running the interviews, we have tried different strategies such as:

  • time-sharing (every interviewer has a fixed period of time to ask questions),
  • topic-sharing (every interviewer covers a different area),
  • picking from a list of questions/areas that is agreed upfront, in a preparation workshop,
  • mob programming with the candidate,
  • pair-programming and pair testing with the candidate,
  • collectively working with the candidate on an artificial assignment.

Regardless of the strategy the team used we always tried to clearly communicate to the candidate about the format and the purpose, and encouraged a two-way dialogue where the candidate can also ask all questions about the way the team works. Our experience shows that, absence of a recruiting manager and giving full ownership to the team results in easier decisions with the candidates and a more satisfying applicant experience. Note that involving a technical expert (that is chosen by the manager) is already a known practice, whereas it is not even comparable to involving the team and avoiding confirmation bias or overconfidence effect.

In our experience, the DM does not continue with a candidate that is not found eligible by the agile team based on resume and test scores. Besides, DM will eliminate the candidates based on team interview results. This approach ensured a higher degree of trust between DMs and teams. We have had situations that the DM and the team disagreed, and in such cases the DM funneled the candidate to other potential recruitments within the company.

Typically, there is a third round for the top candidates where more stakeholders are involved (and they may consider the fit with company values, and focus on alignment with the rest of the organization). Finally, the DM will ask the team to express preference on the candidates that passed all three interviews. Team can for instance make a voting or take a short discussion, and often easily converge on which candidate to choose. DM takes over after that and makes the job offer.

3.5        During Recruitment: Recruitment Metrics

Inspired by lean and flow concepts, and forced by the competitive job market and the scarcity of talent, we use recruitment metrics. We define lead time as the time passed between recruitment started and ended, measured in days. Similarly, we define cycle time per measured activity. For example, the time between a candidate is contacted and answered with a rejection or job offer. We also use first-year attrition as a metric to indicate the success of the recruitment, and number of applications to indicate the success of job ad preparation and the channels/networks used.

Using a Kanban board can also help visualizing the process and surface delays and blockings. We use a common Kanban board for all the recruiting managers in Denmark, and benefit from shorter cycle times and higher chance of swarming and helping each other. Before this practice, managers were recruiting in their own silos, with their own job ads and separate candidate pipelines. Then surfaced problems such as losing candidates that could fit other parts of the organizations, as well as virtual competition over good candidates in the market. Besides, managers were not able to help each other in terms of improving the flow. After the new approach, managers worked as a Kanban team where we improved the flow and experienced much shorter cycle times in the recruitment process.

A DM might have personal Objectives and Key Results in recruitment, and this will significantly help in improving the results that would affect the whole organization’s performance. In Figure 3, you can see a set of measurable key results that Ender’s used for the first quarter of 2020. One concrete lesson we learned from our previous mistakes, is to measure recruitment success together with retention rates, for example having a key result associated with retention rate; in order to have a more balanced and conscious result.

Figure 3: A set of Key Results that Ender had in the past.

3.6        After Recruitment: Onboarding a new team member

Starting a new job is full of emotions, such as excitement and fear. SimCorp always recognized this fact, and has a proud history of having a very comprehensive onboarding program. Nearly all new employees are sent to a three weeks training program—SimCorp Dimension Academy—to make them familiar with our software product SimCorp Dimension. This ensures that they have a solid foundation to understand the product. After the academy it was the manager who created an onboarding plan or most of the time simply pull a standard plan out of the drawer. However, this standard plan would not take the unique qualifications of the new employee or the team’s opinion about what is most relevant to learn into account.

In the early days of our agile journey a group of DMs got together, armed with all their previous onboarding plans and knowledge, and set out to create a new onboarding concept in SimCorp. The result was a card deck and a new concept. Each of the cards in the deck would outline an onboarding concept/tasks e.g. “Complete your first coding task”. These cards not only contained ‘hard’ skills, like coding, but also soft and behavioral skills like “a mob-program session”, “time management”, “social event” and “introduction to the company culture”.

Figure 4: A sample of onboarding cards

The most important cards were the blank cards which the team and newcomer would fill in. In total the deck contained around 35 cards. The new concept was that the newcomer, the team and the DM should collectively create an individual onboarding plan which would take the unique strength of the newcomer and the team specific challenges into consideration. This plan should be owned by the newcomer but the team and the DM would have the responsibility of support and coaching.

Figure 5: Posters we used at an onboarding workshop

In mature teams, it will typically be the SM of the team that will run the onboarding workshop. We typically run the onboarding workshop in the first week after the newcomer has started. The goal of the workshop is to create a unique plan for the newcomer which defines must have and nice to have activities. We usually follow a pattern where the participating team members would also create their own cards with activities. This is an important step because the team knows best about the area they work in and what the newcomer exactly needs to learn. These onboarding workshops have both been run as physical and virtual meetings. In the latter case, we use remote collaboration tools such as Padlet.

A slightly altered approach is running a pre-workshop, which takes place before the newcomer joins, where the team produces the cards that they think would be most relevant for the newcomer. After the newcomer joins the team, the main workshop is held where the new team iterates the previously created cards; and the newcomer is confirming or rejecting based on his/her own assessment for the needs.

Outcome of the onboarding workshop would be documented and added to our application development lifecycle management system, VersionOne. One approach has been to create a work item (e.g. a user story) in VersionOne for each of the onboarding cards and then plan these stories just like any other stories. This would also mean talking about them at the team ceremonies such as daily scrum, iteration planning, and iteration review.

We at some point realized that the onboarding card deck worked fine for roles as a developer and tester but for other roles like SM and Product Owner there were too many irrelevant cards. A group of SMs in SimCorp took the task to create an onboarding card deck for the SM position. The result was not a card deck but an onboarding tree. A snapshot of a recent onboarding tree is available on Figure 6, as inspiration. The general concept of onboarding remains the same. Only the onboarding activities changed to be more relevant for the role. Again each onboarding was tailor made for the newcomer.

Fi
Figure 6: Onboarding tree for a new SM

We start to discuss who is a newcomer? Only a person hired from outside the organization? The answer we came up with was: anybody joining the team. We are creating onboarding plans for anybody joining a team. The plan for one who has been in the organization for many years might look different from one who just joined. But even for an experienced insider you want to make the transition to the new team as smoothly as possible.

We have now done this type of onboarding for several years. The conclusion is that making the plan is very good especially for people joining from outside the company. It gives a mental ease to know that there is a plan and what is expected that you should learn. We have also seen several times the first weeks team has focused on the onboarding, and then the attention starts to drop. Often the reason is that the team forgets the newcomer is still new and needs to learn. One pitfall is failing to sustain the onboarding execution, especially when facing stressful times. In that case, both DM, SM, and the team need to remember that successful onboarding of a new employee will have long term returns compared to short term gains.

We want to emphasize that the newcomer owns his/her onboarding plan, and therefore needs to push for the onboarding items to be completed. In a way, this is not a spoon-feeding approach like the one-size-fits-all plans of the old times.

4.     Discussion and key learnings

We are often asked, whether the way we recruit and onboard is a good use of an agile team’s time. In our experience spanning last three years; even though teams feel they invested precious work time into the hiring process, they at the same time expressed, that it was a good investment with decent returns. Besides, newcomers are in general very happy with the onboarding plans that they co-created and they executed—simply, the onboarding that they owned.

We concretely observed that some team members and teams grew significantly in terms of influencing their future colleagues. In the end, some teams were able to conduct their own interview rounds without the presence of neither DM nor SM. As an example, we have observed a team member who was more nervous than the candidates in the interviews, yet after a few rounds she evolved into a very skilled interviewer.

Another point that we would like to discuss is whether these concepts and practices can be applied to every situation. Frankly speaking, we have observed teams and individuals that were both uncomfortable with such involvement and ownership, as well as leaders not ready to give away responsibility. From the beginning we have learned and practices not forcing or even insisting people to do things this way, especially if they feel that they do not have the competence, time nor wish. Hence our mantra is, this is a process which should not be forced before all parties are ready for it.

We would like to itemize our key learnings below:

  • [General] A refined set of practices for involving teams in recruitment and onboarding; are essential ingredients towards collective ownership in both areas.
  • [General] Using our new practices, we observed boosted engagement levels in the teams when welcoming new colleagues.
  • [General] Changing the traditional ways of “finding the right candidate” and “ensuring a successful start” proved to be challenging.
  • [General] Understanding basic psychology such as avoiding cognitive biases, engaging prefrontal cortex and put the reptile brain at ease, is a game changer in many steps of both recruiting and onboarding,
  • [Recruitment] Creating confidence in the teams to interview potential team mates is not trivial.
  • [Recruitment] Successful recruitment is the result of a collectively-owned recruitment activity.
  • [Onboarding] Pitfalls, including sustaining the onboarding execution especially when facing stressful times.
  • [Onboarding] The benefits of making the newcomer own the plan and the whole team responsible for executing it.
  • [Onboarding] Awareness of the fact that starting a new job is full of emotions, such as excitement and fear.

5.     Acknowledgements

We would like to thank Nathalie Hammering for her great support and valuable guidance, together with her always positive and constructive approach. We would also like to thank the track reviewers and co-chairs for believing in and supporting our journey of sharing experience. Special thanks to Vadym Volkovynskyi, who was the Development Manager for both of us when we were Scrum Masters and who supported us in most of the initiatives that we have explained in this report. Last but not least, we would like to thank SimCorp Scrum Masters and Development Managers, who have helped us with some of the concepts and exercises we have shared, including but not limited to Christian Runge, Daniela Lück, and Oleksandr Kramarov.

REFERENCES

[Cook et al] Neil Cook and Piet Syhler and Frank Olsen, 2018. What SAFe doesn’t tell you. Experience Report, XP 2018.

[Dabrytski] Pavel Dabrytski, 2019. Scientific Method to Hire Great Scrum Masters. Leadership Track, Agile 2019.

[Harre and Lohmann] Niels Harre and Martin Lohmann, 2019, Is team self-selection the obvious choice? Experience Report, XP 2019.

[Less] Large-Scale Scrum. 2019. Role of Manager. [ONLINE] Available at: https://less.works/less/management/role-of-manager.html. [Accessed September 2019].

[Safe Leadership] Scaled Agile Framework. 2019. Lean-Agile Leadership. [ONLINE] Available at: http://www.scaledagileframework.com/lean-agile-leadership/. [Accessed September 2019].

[Safe Managers] Scaled Agile Framework. 2020. The Evolving Role of Managers in Lean-Agile Development. [ONLINE] Available at: https://www.scaledagileframework.com/the-evolving-role-of-managers/ [Accessed April 2020].

[1] Both LeSS and SAFe provide guidance regarding role of managers [LeSS, SAFe Leadership, SAFe Managers], yet the Development Manager is a role defined in SimCorp.

[2] ART leadership is composed of three SAFe roles: Release Train Engineer, Product (Portfolio) Manager, and System Architect. In SimCorp, we also had the DM role in this team until early 2020.

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks
XP 2020

Your Bookmarks

No favorites to display. You must have cookies enabled to add bookmarks.

Have a comment? Join the conversation

Related Agile Experience Reports

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now