Get certified - Transform your world of work today


Non-IT Kanban Implementation at Scale

25 July 2014

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 in to their new office and were treating (I've known these guys for a number of 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 actually 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 exactly 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, until 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 really 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 really 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 intracompany 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.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (2 ratings)


Be the first to add a comment...

You must Login or Signup to comment.


The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.



Newsletter Sign-Up