Using Kanban to improve your recruiting process

I recently had the opportunity to talk with a couple of HR managers who were interested in how agile can help the HR department become more effective. This was a context where the product development is well into their agile journey, and we are talking about a group of about 20-30 people providing HR services like recruiting, training, social events to an enterprise R&D organization in the 1000 people range.

Well, I tend to view HR as a service driven operation. There is demand of various types coming in. The HR turns this demand into a service that the organization consumes/uses. A classic example is recruiting. Demand is the hiring manager with the new open position. The recruiting department helps fulfill this demand, and the end result should be position fulfilled.

So the First thing we did in the session was explain how lean/agile aims to maximize effectiveness delivering value leveraging the following understandings:

• Most HR Activities are knowledge work with high variability and learning. We are not sure about a candidate so we want to maximize early feedback. We want to understand whether a training we got a request for will REALLY be interesting to the people to the level they will sign and allocate their budget to it, to avoid spending precious energy on things that get thrown away / changed later.
• HR groups have a certain capacity. When overloaded performance actually goes down, same like motorways, computers, or development groups. So we should try to use a system that lets the group limit multi-tasking to healthy levels.
• Activities that are only half done are very dangerous. We call that inventory / work in progress, and the more of those we have, the harder it is to operate. It is harder to focus, context switches cost more.
• There is a lot variability in the demand as well as the work required to deliver services. During ramp up times recruiting for example is overburdened. Versatility within the HR department is valuable to assist in dealing with this variability.

With this context in mind, I outlined Kanban as a Method to drive for improvement in this context. What does this mean? Kanban starts with the processes you currently have. You agree to pursue evolutionary improvement, and to respect current state but be open to change it.

What you actually do is take the following steps:

Visualize the Work

Visualize the process/workflow of fulfilling the demand. For example if we continue with the recruitment example - raise need for position -> create position description -> publish > filter candidates > best and final between a few top candidates > prepare offer > send offer > signed offer > prep for onboarding > onboard > 3 month - successful hire. With this workflow we draw a kanban board. I recommend starting with a simple board with a few steps - see below…

Now we populate the board with the current work, in each of the phases. A card represents a piece of work that when Done will mean fulfilled service ( eg one open position)

We can use different indications to show different kinds of work, work states such as blocked, who is currently working on what and more. The idea is to visualize as much of the state of work as possible. Ideally in a big physical board visible in the workspace of everyone or in frequently visited public space. This creates transparency that will in and of itself spark interesting discussions, raise problems to the surface and start creating a list of problems we need to handle ( which is good… )

We want people to use this board in their day to day activities. The board should be the main tool used to track work and synchronize. Lots of teams use daily sync meetings in front of the board.

Next step is to recognize that there are limits to capability, and work should be governed by capacity. What we actually do is assign limits to numbers of cards/items in process. The most common way is to say “no more than 3 cards in this board lane” or “no more than 3 positions we are currently writing descriptions for”. This creates a pull system, because it means that once that limit is reached, no new work can be pulled in, until some work has been pulled by the downstream process. This has the effect of “We’re all in this together, concerned about delivering value, rather than just doing our job”. Very quickly some slack will be created by the pull system. The magic is to divert this slack to help the work flow right now, but more importantly find ways to improve the capacity of the bottleneck that caused the flow to stop.

An example is probably in order. If it seems like many positions are in “sign” it might be interesting to use slack time to help create better templates or easier access to salary tables to reduce the effort it takes to prepare offers. If it also seems like a lot of offers are rejected since the candidate is not really serious, it might make sense to find a cheaper way to verify seriousness before spending the effort to prepare an offer. What you actually do will be context specific of course. The Kanban Method WIP Limit will just waive the flow problems in front of your face and beg you to deal with them, more intensively than before.

Start caring about the flow, the time it takes from start to finish, from request/demand to finish. Care about the mean time, the promises you can start making, the corner cases and what they mean and how you can improve by learning from them. For example if a typical position is handled start to finish in 4 weeks, and you see a position took 1 week, look at it and try to think what makes it a “Bright Spot”? Was the job description crisp and sexy? Was the hiring manager devoted to making it happen? Was the recruiter using some new sourcing technique? Same for the opposite case - what went wrong with that position that took 8 weeks?

This is a very interesting step. On the surface, this is very mechanistic. Seems like “Document your process”, what’s new here? And what’s Agile about it?

First, just to make sure we understand, these policies are the rules of the game. Things like the WIP Limit, the conditions for cards being done in a certain phase and ready for the next one, the policies for expediting work if necessary.

Explicit policies enable empowerment. They improve the level of coherency of the system among all people working on it. They can safely make local decisions that are aligned with the rules of the game.

Beyond that, Explicit Policies are not static. They should evolve based on new understanding and learning. You should experiment with them to see what works. The policies will be painful. You will sometimes feel you are hitting a wall. That they are creating constraints for you. That is good. Constraints drive creativity. And if the policies are constraining you in a way that’s driving you towards better and better flow, that’s great. It means the pain is part of the gain. The discussions you will have about what to do to make the policy work for you, will drive the improvement action items. Sometimes you will relax policies that went too far too early. Sometimes you will tighten things up to drive for more improvement. This is one of the key practical ways Kanban drives learning and Continuous Improvement - Oh that holy grail…

Finally, with the system in place, after you start using it, there will be opportunities to use models that apply for Flow systems. I will not go into this. Suffice it to say that although the Kanban system might seem simple, there are a lot of ways to look at a system and improve it. If you’re interested in this area, I can refer you to more material on the subject.

Yes, might seem simple at first, if you’re looking for the revolution it is not here. On purpose. Kanban is an evolutionary method. It aims to provide an alternative to classic shock and awe change programs that many organizations had bad experience with. With Kanban you change at the pace that works for you. You can accelerate pace of change as you become more proficient in identifying the problems and experimenting with solutions.

What did the friendly HR managers think? Well, they liked this method, found it very applicable to various processes in the HR department, and can’t wait to start. We are meeting in a couple of days again to play some Kanban games and setup their boards. I will report when there is more to tell…

Note that nothing here is very specific to HR of course. This simple approach can be used to introduce change in many knowledge-oriented services. Many Kanban practitioners are reporting Kanban boards popping up in other departments when the IT group starts using it. It’s quite viral…

Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.