One of the problems with agile hiring is this: what data do you collect?
Let me digress for a bit and talk about cycle time and lead time. This image explains cycle time and lead time for a cross-functional team. Everything starts in the Ready column and proceeds through the possible progression through development and test to Done. I have no WIP limits on this board because agile hiring would rarely (I can't think of a time) have WIP limits.
Cycle time is the time from when the team starts to work on an item until the item is done. Lead time is the entire time the item spends on the Ready column until it's delivered to the customer.
Let's think about the flow first. For agile hiring, we might want to think about the time it takes us to get a position approved. That's the equivalent to getting an item on the Ready column.
We might also want to think about all the prep: job analysis, description, and ad. That's one piece of a cycle time. We also might want to look at sourcing in some way, another piece of cycle time. We definitely want to look at the cycle time in phone screens and interviews. And, we want the cycle time for how long it takes for us to generate an offer.
All of those cycle times create the lead time, the traditional HR metric of time to hire.
Here's why lead time is insufficient: In agile hiring, the “team” changes. Approving a req requires HR and the hiring manager. The hiring manager with the team might work on the job analysis, etc, but sometimes the manager works alone. Sourcing requires another team. Phone screens and interviews are a collaborative effort between the manager, the team, and maybe an HR person. Offers and hiring is more of a manager possibly with an HR person.
I wanted to specify all the different cycle times, because randomly removing time in the process does not create a better candidate or hiring experience. (Just as removing testing does not create better features!)
Data should help us surface assumptions, review, and improve the process.
We have to know that we hired the right person, not just that we hired fast.
That means that I look for speed in opening the req, in the job analysis steps, a regular cadence in the interviewing, and speed in the offer and first day.
If you only look at the time to hire, the total lead time, you don't see the possible wait states. There are possible wait states in the pre-phone screen states, and in the post-interview states.
In Hiring Geeks That Fit, I have several suggested metrics, and all of them involve finding the wait states. Here's the table I suggested in Part 4 of the book:
You might not need these pieces of data. You might need something different. I do recommend you avoid one large piece of data, such as time to hire. That metric has too many pieces of the value stream as the only metric.
Time to hire is lead time, so you might also want to know that data. But, it's not sufficient as the only metric.
With quantitative data and qualitative data about the candidates, you and your team—with HR, if that fits—can retrospect about the entire process.
Now, you have an agile approach to the hiring process, but we still have to deal with sourcing as part of hiring. That's the next post.
The posts so far:
The post Creating Agile HR, Part 3: Possible Agile Hiring Metrics appeared first on .