Motivated people, a valuable service, an experienced coach, a trained workforce. Even with all these things in place, we ran into a few challenges when using Kanban in an HR environment. Here are the three things we continue to struggle with in our ongoing Kanban journey at a major international firm.
Thing 1: Tools Matter
ServiceNow, we’re told, is a good ticketing system. What we found out however, was that it isn’t good system for Kanban. Regulatory and IT constraints made it that so the teams had to use it. And while the system has support for setting workflow stages, item types and WIP limits, it’ll allow you to violate those limits without a peep, and move items any way you want. Now, so far this doesn’t sound like a problem. And you’re right, these issues can just be solved by discipline in a team.
The real issue is data. ServiceNow produces garbage data for Flow Metrics. For each ticket it only tracks 2 things: When it was made, and the time since it last moved. This meant that we could track the overall Lead Time of an item, but not Cycle Time (as the team prioritizes work in a backlog first, before they pull it). Neither could we accurately track time per workflow stage. Moving an item meant the timer would reset again (even when moved back and forth). All in all, this means that deriving Flow Metrics requires a lot of manual administration: about an hour each day.
Thing 2: Definitions matter
A challenge with the Definition of Workflow is to what level of detail you need to go. Too far, and you’ve got either too many steps and too many item types, making for chaos. Not far enough, and you’ve got a meaningless To Do/Doing/Done view which tells you nothing. Usually, working on a well-defined product keeps this under control. With HR services though, you’ve got a massively varied set of items and workflow: employee relocations, performance reviews, recruitment (at multiple levels), complaints, promotions, the list goes on. Creating a view that would offer complete transparency would, ironically, offer very little transparency. Let alone the amount of work required. Creating multiple Workflows or teams makes little sense either, as the inflow for each is unstable and unpredictable. All said, we ended up going for a very generic workflow, just to keep the load visible.
Thing 3: Discipline Matters
This will come as no surprise to most readers, but establishing WIP limits is the easy part. Actually sticking to those limits when items are stuck due to dependencies, real people need you to start work on other things and your manager is concerned with the lack of things happening. It’s one thing to say a team can swarm together and solve blocks (they do), but changing the organization so inside and outside dependencies are no longer an issue is a long journey, and doesn’t help you in the here and now, with an employee trying to enroll their children at a local school after moving halfway across the world. One thing being blocked isn’t an issue when there’s 10 other things that should be moving.
Final Thoughts
Kanban did a lot of good. It allowed the teams to have a better view at the many services they offer, and learn from each other. It allowed them to quantify the gap between incoming work and delivery, and successfully argue for more staff. It allowed them to gain insight into lead time SLE, and (with some manual labor) cycle time SLE. But there is a slow-moving real world between getting started and achieving a smooth, predictable flow. It’s definitely worth it, but manage your expectations.
