A true Scrum team recruits its own members.

A true Scrum team is a full partner, if not THE recruiter, when recruiting its new members. This is a must.

Why? Because when you're a real partner, i.e. you're part of the procedure and the decision of recruiting your new partner, with whom you'll need to reach the targets of the team to which you belong and are committed – this creates a real commitment to selecting the best partner for the team, getting him on board and of course making him feel welcome.

He's yours, you recruited him, the decision was yours and not an order laid down by some out of touch manager or another. Only in this way do you feel committed to his success.

Some of you are probably stunned from such a far reaching statement. But sit down for a moment and keep reading, it's not only far reaching but might possibly be unavoidable. I will go so far as to claim that in such a complex world, filled with changes and decisions, where employees are required to be creative to find solutions to the complex demands of their tasks and to work in independent self organized teams (because there's no other choice) - how is it even possible to imagine that they wouldn’t be the ones to recruit the colleagues with whom they’ll work to accomplish the mission that the company assumes they are committed to (and they are committed to)?

This is similar to ‘goal-setting processes’ as part of a ‘performance review process’ as were defined by many organizations in the recent past and unfortunately still exist in many places today. In the past managers would set personal goals for their workers. Whereas nowadays it’s common knowledge that if the employee doesn't play a part in setting his personal goals they simply won’t be achieved. You can’t impose goals on an employee who doesn’t relate to them, or who wasn’t a partner to choosing them (it’s true that today there are more progressive approaches that challenge even the goal-setting method itself, but you can read about that in Get Rid Of Performance Appraisals!!!). So how is setting personal goals for a worker different from recruiting a team member? I believe it isn’t. How could we impose a new member on the team and expect them to “get along”, or to accept the new member and be thrilled to give him the best onboarding process possible?

Why then, resisting the fact that recruitment is being passed on to the team?

I remember how in the long-gone early 2000s, I published a post as part of the newsletter of the company where I worked, in which I turned management and employees’ attention to the fact that it would be much easier if the Scrum team recruits its own people. As a team that had been working in Scrum for a year or so, it was aware of its own shortcomings as well as the skills team members require in order to accomplish their tasks. Certainly this is the case in a Scrum team that for each sprint has to know, manage, commit and reflect is work and its results towards a high-quality release. Obviously, this team is involved, it’s close to the work and the vision and what's more, in the company’s eyes the team is the one responsible for creating high-quality, working software. The post raised many objections, which were expressed in sayings such as: “But they don’t know how to recruit… They’ll make mistakes… They’ll bring the wrong person… How can salary even be separated from recruitment… How could we reveal the salary to them?” etc.

I think these objections are natural in any situation wherein you lose part of your territory as a manager or professional, one which you were responsible for and even formed a significant part of your organizational identity. If this role is transferred to someone else, what will I do? Maybe. And maybe not. Telling executives, as well as HR, that recruitment is being passed on to the team could obviously raise a lot of anxiety: losing responsibility, fear that things wouldn’t be done right, and probably many more… Anyway when it comes to accomplishing organizational goals it’s necessary to work with this group of people and help them make the transitional into a more team-based, cooperative and advanced work mode, more suited to the modern times that we’re living in. All this must be addressed, in part by new procedures and in part by helping them leave their comfort zone into new and more advanced mindsets and practices.

Will the team know how to recruit?

I have another surprise for everyone: a lot of executives and HR also don’t know how to recruit. They think they do but they don’t. They also need to learn and they also make huge mistakes in recruitment.

Recruitment is something you learn how to do, and speaking of learning, it’s something that should be by my view done as a team. Because the team’s power, opinions and learning from one candidate to the next one is much stronger than that of the individual.

By the way, some companies also reveal the salaries to all their employees, and not only that but the workers themselves set their salaries, and these are actually very successful companies (here’s an example: https://www.youtube.com/watch?v=gJkOPxJCN1w&feature=youtu.be&a&_ga=1.207125715.1711051772.1407070028). But that is definitely a more advanced subject for another post.

So why do I insist that the team handles recruitment?

So I already said the first thing which is Because in a world where we expect the team to manage its own affairs, to be responsible and committed to bring results, how could we not give it the full freedom to recruit its members? When an executive recruits, he is in effect responsible for the success. That's the way he’s perceived by his managers, obviously by himself, and certainly by the team. After all, he’s the one who chose the candidate (along with HR and others), from deciding on the candidate’s profile, salary, interviews and deciding to hire, and then he “forces” the person on the group. When the team recruits, they are the ones responsible for the results. Not only is the team a partner, it is in fact committed by its feeling of full responsibility for training the new arrival. It’s similar to my son’s homework: when I'm the one who needs to badger him about preparing his homework they become mine. When he's the one who's responsible for preparing them, they’re his. And so I let go, difficult though it maybe, and refrain from constantly asking him “Have you done your homework?”

I also find immense significance and benefit in the fact that the team handles recruitment in regards to the employee’s onboarding process in the company. The process of the arrival’s acquaintance with his new colleagues and their acquaintance with him starts early in the recruitment process. The team isn’t asked to meet an arrival on his first day at work, but rather already creates the connection and breaks the ice at the interview stags. This makes it much easier for new arrivals and their onboarding in the company. Indeed, there’s nothing better than arriving to a new workplace with a few ‘anchors’ you’re already familiar with. What a relief. Furthermore, a common assumption is that an employee’s initial onboarding in a company is crucial for his future motivation and performance and certainly for his remaining a productive employee for the company (http://www.inc.com/guides/2010/04/building-an-onboarding-plan.html). So recruitment by the team also improves this balance.

This also gives a candidate the ability to form his own impression of team with which he will be working. I think this is incredibly important. After all, recruitment is not a one way street. It also involves “selling” the organization to the candidate. See, the candidate also learns something very important from this process. He becomes more familiar with his future team members. He receives messages of openness and commitment. After all the world isn’t composed only of interviewers and companies, we also want the best candidate to want to come to us.

Some teams do it:

How is it done?

1.       Mindset: First of all the message is that the team isn’t “depriving” anyone else of his responsibility. On the contrary: this is a cooperative process that includes direct communication and team-based decisions between all parties involved. The manager isn’t excluded, HR isn’t excluded, on the contrary they advise the team, teach and guide. Everyone understands what’s happening, the process is completely transparent and consultation is an inseparable part of it. But the responsibility , accountability and “execution” of the process is in the team’s hands, like any other backlog item.

2.       The Scrum team helps define requirements. The Scrum team is completely aware of sprint goals and the method. It determines the position’s requirements and needs as part of an outlook which dictates that the new team member has to have the necessary technical abilities or social and personality related traits.

When it comes to traits, let’s understand – from my experience, when a team member sits with other team members and its leader and they discuss the required qualities of a team member, they are actually discussing themselves. In every such discussion each participant can’t help but look at himself and be reminded of the do's and don'ts in his team. Usually each person will come and present "someone else’s” quality, relating to the person he would like to work with. In fact these are the team’s rules of conduct which are required from each of its members (with some degree of variance).

3.       Coordinating the recruitment process with HR – the team coordinates with HR the process of defining requirements, collecting and sorting CVs and interviewing, and become familiar with the process. In some companies I’ve been in there is no HR at all. So in these cases the team defines the recruiting process themselves.

4.       Sorting CVs – doesn’t matter who does it, usually I see it done by the team manager, because it makes it easier for the team by saving them the need to deal with all sorts of irrelevant CVs that waste time. But I swear it’s not important, of course ideally it would be done by the team. It’s important to stress that this is also a learning process – how to treat CVs, what you can understand from them, what gets screened and what doesn’t, etc.

5.       Summoning candidates for a first interview and an initial acquaintance phone call is done by a team member (or two)

6.       The test:

Writing a candidate test. I’m aware that when the team itself writes the tests, tries it on itself (and afterwards also presents and checks the test) it in effect gets an idea of the difficulty of the test considering the candidate and the team’s needs. This allows the team to improve and change the test according to the feedback received (since the test was written by the team itself) and creates proper content-related partnership for the process of choosing the candidate in light of the required technical skills.

Presenting the candidate with the test, explaining and reviewing it is done by a team member.

·         Building working software

My favorite tests to give are ones whose results can be displayed visually afterwards. Something short which takes the candidate one or two hours to complete, wherein the result can be displayed and discussed. As a Scrum team we try to build software and it’s considered 'done' only when it’s working software, we expect the candidate to also create something that “works”, that can be presented and discussed. And for this reason it’s pointless to let the candidate fill out a paper and review it without seeing the results.

·         The demo of the test results and the discussion

A demo allows consideration of many aspects the candidate views as important. A demo must be accompanied by a discussion lead by a team member. When I accompany a team in recruitment in regards to test-related questions that arose, I always take care to emphasize the discussion. Let the candidate present his work, don’t draw conclusions from the written material, take a deep breath, listen and take in, in this way you’ll convey the message of acceptance and listening along with absorbing information you can later relate in the questions you’ll ask.

In an Automation test developer’s test, for example, we’ll expect to demo running tests, observe them and ask questions related to the candidate’s considerations in developing this way or the other. Maybe we might even be surprised and learn something new? In a DevOps developer’s test, for example, we’ll ask to present a system and ask similar questions regarding the way he chose to develop.

·         The importance of technical discussion:

This meeting creates a technical discussion, which is closely related to the team’s technical tasks. A team member is able to review the most basic communication between himself and the candidate in the closest way possible to day-to-day work, and that’s what we will request him to do. On the candidate’s side, he can recognize initial patterns in the team he is intended to belong to. Furthermore, this empowers the team member who is required to explain, understand and assist in technical matters at the heart of day-to-day work. When you teach and explain, you’re responsible and learn.

The very act of writing and working on the test creates dialogue with others in the team, almost unavoidably, particularly with the manager, e.g. “What do you think? How was he? What was easier for him and what was more difficult? Where do you see difficulties and where did everything run smoothly” etc. – questions which in effect empower the team member.

7.       The interview – I prefer team members interview together, peer interview – it works. It’s true that they don’t really know how to interview but it’s a learned ability. Here too it’s important to consult with others as close as possible to the interview. It’s nice to see, as I do occasionally, how team members get together next to the task board in the team workspace and openly discuss the candidate which has just finished a day of interviews. Since they’re a Scrum team they’re more or less accustomed to creating comprehensive discussions and making decisions.

8.       Lunch with the candidate – its one of the powerful tools I have ever sees in a recruitment of a new team member. it’s preferable that a candidate who passed the test and initial stages will go to lunch with the team. Believe me, I’ve seen this work with my own eyes. There’s no better way for people to get to know each other. It’s a powerful tool that allows dialogue beyond technical details.

9.       A team leader can gather the requirements – but doesn’t have to. He can join at any stage. He can also choose to conduct the technical or last interview. It depends.

10.   Visualize the process. Its easy to use a simple Kanban style board. It’s a good way to get all the team on board, be aware of the status of all candidates and shared the share collective insights. And it’s so simple

In the picture above you can see an example of one of the boards used by a scrum team, reflects the stations a candidate needs to go throe and where everything stands in terms of status. Is visible, not hidden in a manager xls file and it is available for team discussion at any time.

**There’s no problem in arranging a schedule of interview and test + lunch, it’s as simple as any other interview schedule. It’s only a matter of will – you talk to the candidate on the phone, present the test, set a demo date for the test and an interview + manager interview and go to lunch. There’s nothing traumatic about it. And it works, I’ve seen it in my own eyes.

How to guide the team through this process?

Not everyone knows how to recruit, right? So you have to guide and teach.

Obviously the team’s maturity must be considered. But part of a team maturing is letting it take responsibility and fell accountable  for complex matters, one of which is recruitment. This isn’t like a child who crosses the road alone when he’s too young and can’t notice cars or determine their speeds and thus needs his mother’s guiding hand. We’re talking about people who are university graduates (but even if they’re not), opinionated and capable who as part of their maturing in learning Scrum learn something else – how to recruit. If they learned the daily, planning, retrospective, reflecting sprint situation and self-organization, they should also learn this. How and when? Just as any other technique is taught. Slowly and carefully.

In fact I see three ways of guiding the team: Teaching, Mentoring and Coaching.

Teaching in my view includes the theory of how things are done, e.g. labor laws, dos and don’ts, how to interview, what is the preferred process, how to treat someone during an interview etc. Mentoring is in following every step of the execution, being there and mentoring how to do things right through action. Coaching includes asking a lot of questions; encourage insights; bringing people to the state they’re in, empowering them to make mistakes and to act, assisting them reach decisions and insights. All three are meant to help us handle dilemmas.

I find that there are many dilemmas that team members need guidance in. But this is no different from the help that any beginning manager or recruitment team needs, and later down the road in advanced stages and recruitment skills. So it should just be extended – for example, the “merciful” would like to give someone a chance even if his skills aren’t exactly right. So how do you teach them to manage this dilemma and create interest in the most suitable candidate? Or concerns about the interview: How to ask difficult questions? What happens if you disagree with the candidate?

Well, that’s why there’s a coach nearby. Or a very enabling manager. You have to be there, consult frequently, and reach conclusions after every stage. I personally as a manager and as an Agile coach always take care to remain close nearby, ask questions etc. but leave the decision to the team.

The above picture describes an example of a simple tool , intuitively helps team member identify  the ‘right‘ candidate.  It’s visible and allow the team to discuss and understand candidate skills and his a ability to act as a team player according to team expectations.

Good luck and Godspeed