At Qualogy, where I work, we have a team that acts as a recruitment agency for freelancers towards our customers, so that we can help our customers fill open positions even when we don’t have a suitable internal candidate. This team’s main goal is to find suitable candidates as quickly as possible, offer them to the customer, and help both to come to a mutually acceptable agreement.
The team of three that takes care of this work was looking for ways to improve the service to their customers. That meant being quicker to offer possible candidates to customers, but also to provide faster feedback towards (rejected) candidates.
As a way to achieve this, we decided to try a basic Kanban system, with the process from receiving the request from a customer to either an accepted candidate, or all candidates rejected and notified.
We started out by charting the existing process and identifying the parts that were in our control, and those that are not. There were obvious places where we would simply be waiting for a response from a customer (‘We do/don’t want to talk to this candidate’, and ‘We do/don’t want to take on this candidate’). This made the initial sketch of the process look as follows:
We played around a bit to fit this partially conditional flow on a Kanban board. Initially we had the idea of a linear board with each state in our process mapped to a column, where columns could be skipped if they were not applicable. This left us a bit unsatisfied, as part of the agreed process was not really explicit. By looking at the whole of the process as consisting of two parts, first finding candidates, and secondly offering them to customers, we got closer to a working solution. Then by making the difference in flow for accepted (at least for an interview) and rejected candidates explicit on the board, with the token from the first part of the process (finding candidates) cut in half between candidates offered, and those rejected, we ended-up with the following structure:
As part of the use of Kanban, we also wanted to keep track of how long it takes to go through the stages of the process. As is recommended practice, we added the time for relevant states to each token:
Making the process explicit, by setting-up the board and clearly agreeing on what the work in the different stages should consist of, is the first basic step when starting with Kanban. It gives a lot of clarity for the team, and makes it easier (possible) to start discussing improvements in process with a common understanding.
One thing that anyone familiar with Kanban will find puzzling is that we didn’t specify any WIP limits on the board. We did discuss doing that, of course, but we decided to wait. One approach to setting the WIP limits would have been to start with the number of people in the team, and use that as a starting point. It is very normal in this type of work for one person to be handling multiple cases, though, and no one was sure how many. Another approach is to simply look at a normal week, and see the maximum number of items there are in any given column during that week. Though we started with this approach, demand was too low to be able to come up with any useful figures, so for now we are still WIP-less.
After some initial apprehension on the introduction of the board, the reactions to working with the Kanban were very positive. The perception was that there was more clarity as to what was in progress, and what needed to be picked up. The daily stand-up in front of the board took some getting used to, but also helped with the division of work amongst the team members. The clear state and frequent communication was seen as a very good way to be able to fill-in for colleagues when they were away.
After one month of this process, we held a retrospective to see whether everything was going well, and what we could improve. The retrospective turned up some interesting points.
On the positive side, better communication, both within the team as towards customers and candidates, was seen as a very positive point. The visual process had also much improved keeping all the administrative tasks up-to-date, which had previously often been collecting into large backlogs.
On the improvements side, there was worry about tasks that do not fit into the standard process, as those are not visible, and thus parts of the work that people do is not visible. A further point was that after an interview at a customer, sometimes it would take a long time before the customer reacted, and thus a long time before we could provide any feedback towards the candidate. This would create extra work, as the candidates would start calling regularly to request status updates (a very good example of failure demand.
As a result of the retrospective, the team decided to annotate tokens that were in the ‘Interview’ column with dots, which would be added at each stand-up meeting. And after a set amount of dots (which equals to a set amount of time since the interview), contact would be made pro-actively with the customer, and after that with the candidate, to keep everyone up-to-date.
Another agreement from the retrospective was that any status change would always be immediately updated on the board. This would make taking over any tasks by another team member much easier. The team already thought this had improved much in the new process, and wanted to further improve in that regard.
Finally, it was agreed to put up a separate board for non-applicant work, so that that could also be tracked. This would be a generic ‘to-do, in progress, done’ style board for any other type of work. The reason there was suddenly a different type of work for the team was a need from another department in the company, due to illness there. The work was completely unrelated to the process discussed above, and the best we could come up with was using a separate board (or separate ’lane’ on the current board, but that didn’t work out with the widescreen board we were using). This doesn’t help much in showing if specific items are delayed by the ‘extra’ work, but at least it does show what work is in progress at any time, indicating a ‘total’ delay.
The next step for this team will be in finding out what could be useful WIP-limits Work-In-Progress limits, which are agreements on how many items can be in the same state on the Kanban board, which should expose any bottlenecks quickly). So far the demand has been low enough that there has been no real opportunity to find out where the bottlenecks are. It’s expected that as the market becomes more active, the first bottlenecks will be automatically revealed.