A few days ago, I went to the happy hour of a local staffing firm that specializes in placing Agile technical and leading resources. They had moved into their new office and were treating. (I’ve known these guys for many years and was not looking for a job.) As I was walking around the office, what caught my eye were a few huge whiteboards attached to the walls. One of the boards was in the recruiting area, another one in the account-opening area. I moved closer to see what was on them. Both boards had multiple columns and rows. I focused on the column headers of one of the boards. Most of the columns looked like sequential steps of one long process: resume submission of a job seeker to a client company.
I took a closer look at the other board and, after a few minutes of interpreting its column headers, realized that the board represented the steps in the account-opening process. The boards did not seem to be related and they seemed to be maintained by different teams—one by recruiting, another one by account opening. I looked around for a few more minutes and then asked the regional director to validate my observations and assumptions.
This is what I found out:
Without naming it explicitly, the teams have been using Kanban boards to manage their daily work flows—recruiting did their thing, accounts did theirs. I also learned that each team gets in front of its respective board every morning and discusses things in ways that are similar (not the same) to what Scrum teams do in daily stand-up meetings.
The boards were not connected. The swim lanes did not represent SLAs or levels of escalation. The lanes were not dependent. The swim lanes represented different business tracks that did not even require escalation—they were sort of independent.
And so they seemed. But then we discussed it in more depth and realized that since they are consuming the same team resources, there is a relationship. There were no WIP limits on the columns. So it became apparent that the teams were not actively managing the queues. However, they were visualizing them well. Then we discussed further whether the two boards were as independent as they seemed.
And this is what we discovered:
Tickets that were moving across the accounts board represented client-companies that went through various states of the account-opening process. But then, on the recruiting board, each client company represented an individual swim lane—a major work track that was further subdivided into more granular tracks, each representing a requisition number. What moved across the recruiting board were tickets that represented names of individual candidates.
So the boards were not independent: Each ticket that came to the last queue of the accounts board automatically became a major track (could be empty initially) of the recruiting board. Then, if a requisition number came along, it would become a mini-track.
We were dealing with a non-IT enterprise (mini)-level Kanban implementation that still needed some fine-tuning and polishing
up: converging one Kanban board into another, establishing WIP limits on each queue (column) of each Kanban board, introducing buffer queues (e.g., “something”-Ready). The setup also required some additional thinking about whether there were any other intra-company processes that needed to be visualized and aligned with the known ones.
I hinted to the regional manager that by “Kanbanizing” their overall enterprise business, and perhaps adding a few burn-up charts that represented how accounts got opened or candidates got placed over time (assuming a time line of, let’s say, 2014), they could really “agilize” the process of placing Agile technologists. They would demonstrate to their clients that they know the business they recruit for, and clients might just like it.
I also left excited, knowing that I have a nice non-IT Agile story to tell—something that would once again support the notion that enterprise-level applicability of certain Agile processes has a place in real life.