Agile Recruiting: Is Scrum Applicable for HR?
2017-08-10Today, only lazy people are not talking about innovations, agile, self-organizing teams. Let's first consider such a well-established process in all HR-departments of the planet as recruiting. Is it possible to experiment with it using agile frameworks, given that these experiments are most appropriate in the area of developing new products with vague ideas about what awaits us in the end? Well, in fact, what can you think up here? Application - interview with the candidate - search and selection of resumes - interviews - evaluation - decision-making - offer. And most importantly, is there really something to invent? For example, with our rapid growth, we have more than 40 vacancies for three recruiters. Almost all are like "go somewhere, I don't know where, and get something, I don't know what." Because we have innovation, development, research and all of that. Those who have ever closed a vacancy, for example, a designer, will understand what it means: a constant, in many ways, routine work without coffee breaks.
Is there a place for Agile project management?
Nevertheless, three months ago, our recruiter's team decided that we want to create the world's best recruiting service for Scrum teams. What are three months in the traditional project development? What can you do in the project with the hefty daily workload for closing vacancies? Never mind. Nothing but "now the number of vacancies will be a little shorter, and then we will be engaged in project tasks." But the thing is, it will never happen. What is the three months work in Agile (we used Scrum)? These are six sprints, each of which ends, though small, but useful to the customer product (increment, speaking the Scrum language). And today, with good reason, I can say that if you want to improve even a very structured and well-developed process, you will not find a better methodology. I will explain why.
First, life makes us change faster. When people around you work in Agile, all processes are significantly picking up speed. And if you do not improve your service, you will very quickly and hopelessly fall behind your customers. And if people around you do not work in Agile, HR still needs to change faster than everyone else to ensure the development of other divisions of the company.
Secondly, at the current rate of change and unpredictability of the results of almost any decisions, Scrum is exactly the framework that, due to the movement of short sprints and close communication with the customer, ensures the constant adaptation of your decisions to changing conditions.
Thirdly, this methodology provides an honest relationship with the client. It turns out that you can suddenly learn a lot about what the customer really wants. It seems to us that in the process of working on a vacancy, we are consistently interested in the needs of the client, but the first demo (demonstration of increment to the customer) can make some adjustments to existing representations. We, for example, were convinced that our customers, above all, are concerned about the quality of candidates and the speed of selection. After the first sprint, we realized that the main thing that excites them is the transparency of the terms, that is, a clear understanding, when the person will start to work so that they can plan their work. And they are also interested in time. Their own time, which they are ready to invest in their result, and not in all our great, modern and valid evaluation procedures. The ideal recruitment service is invisible to the customer.
Today, thanks to Agile, we can take guaranteed obligations on the time of recruitment process, regardless of our internal circumstances and the complexity of the vacancy, and our customer (with rare exceptions) can plan his or her work taking into account the candidate's start of work. Three months ago it seemed almost impossible, and in our history, there were complex vacancies, the closing date of which lasted up to six months. Besides, we have made our service transparent to the customer and implemented several experimental schticks that significantly speed up the process of closing the vacancy, and after a few sprints, we will have a clear statistics on how they work (the topic of one of the following articles). Based on the current dynamics, after a couple of months, we will be able to say that the vacancy of any complexity is closed by the best possible candidate after no more than a month.
How does it work?
In Scrum, there are four simple activities that, in fact, create the wow effect of speed improvements that we see in ourselves: Planning, Daily Stand up, Demo (demonstration of the result to the customer), Retro (Reflection of the team's work). And that's what they give:
- Scrum allows you to keep the goal of the sprint in a constant focus and does not let too much "get carried away" by daily tasks, forgetting about the project ones. The team plans its work and takes responsibility for the result. Also, this thing is very motivating: a common goal that is understood by everyone brings the enthusiastic drive.
- The movement to the goal is completely transparent for all participants. The notorious 15-minute daily seems at first to be delusional and a waste of precious time for recruiters, but literally after a couple of such meetings the team understands that this ritual perfectly synchronizes and builds the process. You see every day where the whole team and every member are towards the goal.
- The team begins to work as a single coherent mechanism, inevitably interacting to solve the problem and gradually becoming responsible and self-organizing.
- The mechanism of instant feedback analysis from the customer and the interaction reflection allow integrating all ideas for improvements into the next sprint very quickly.
- And one more important nuance is the harmonious balance between the process and the result, which is achieved due to the double check: Scrum Master is responsible for the process of interaction in the team, Product Owner - for the product. These are two different people with an entirely different set of competencies, and this is what allows you to work on the product and teamwork simultaneously.
And in the end, I would like to pay attention to several issues that reflect the nuances of using Scrum in the HR-sphere.
What is the product for the service industry, to which HR certainly belongs? If this problem is not especially acute in the development of specific products, the IT and engineering development team can always accurately name the product. In our expert field, everything is much more ambiguous. Where is the line between the daily work to improve the services of recruiting, adaptation, etc.? And what about developing a new product? Nevertheless, we have identified two types of products that we develop in Scrum. They are a new service (for example, a faster and more accurate way of evaluating candidates with the participation of the customer) and new technology (for example, when we invent a new technology of search and selection Technical geniuses, which guarantees a faster result without the loss in quality).
How to combine work on the project with a lot of current tasks? Again, if this problem is not especially acute for developers as 100% of their working hours are devoted to development, so HR-s most of their working hours are occupied by the current functionality. When six months ago we asked this question to the coach who taught us how to work in Scrum, the answer was "there is no way." It is either the project or routine. However, our experience has proved otherwise. Scrum is so well-structured that with its help it is possible to organize design work in any amount. Besides, it involves measuring and accumulating statistics on a number of tasks that the team takes in the sprint. After a few sprints, it begins to understand how many project tasks will do in this sprint and organize their work more structured and responsibly in all directions.
How to deal with a sprint demo, if it is almost impossible to present the customer with any completed increment for two weeks in the service sector (and we have 2-week sprints)? Our product is not material. Therefore, it takes the time to measure the results. Nevertheless, the demo is necessary; this is the activity that provides communication with the customer. We found a way out: in any case, the client seems to have some business value or an idea of business value, even if it is not a finished product. But we show it to a small group of our customers. There can be as many such iterations as you like, here the main thing is the constant communication with the client, and the finalization of the product by his or her real expectations. The team receives feedback, analyzes the product and its work and moves on.
How do you make it work?
What are the conditions under which Agile in the team will work? The key condition is people with different thinking. People who think about the product and they are quite mature (psychologically, and not physically), to take on long-term obligations both to the team and to the customer. The most difficult thing when implementing Scrum is to switch the command to self-organization mode. According to statistics, this requires at least six months. It took about five months in our case (in HR). The process was not easy, someone left, someone came, but after that, the team began to function as a living organism.
Summarizing our experience in Agile, I can say only one thing: it's a bomb. We have a full-cycle production company, from project development to production, and we have implemented Agile in almost all processes of the company, including services, in a short time. I can not say that everything goes fantastically smoothly (there are problems, of course, but everything can be solved), but the fact that Agile speed up the creation of any business value at times is a fact. Problems that have not been solved for years find their solution after a couple of sprints. Try it. You will like it.