Use Kanban for Flowing Work

Contents

A Question of Frequency

A chart showing different time periodsScrum teams have ways to deal with unplanned work,[1] but what if all of a team’s work is unplanned? Customer support teams are the example I’m asked about most often. They receive multiple requests each day for information or defect-fixing, most of which can be addressed in a relatively small amount of labor hours.

This kind of team may be better served by the method called “Kanban,” now considered part of “Agile” even though it predates the Agile Manifesto by four decades. Invented by Toyota to support car production, Kanban is useful for relatively small work products created and released continuously, without possibility or need of much item-specific planning. That means most are of a type that is well known and must be turned around in less than a week, usually in less than a day.

A limit is placed on how much work can be done at once, called the “work-in-progress” or WIP limit. In “The Sprint Process,” I give examples of task and story states (under “The Paper Option”). In Kanban, only so many stories can be in the “In Progress” column. The team does not “push” stories from an earlier state like “Defined” just because they are ready to move. Instead the team “pulls” stories from the earlier state when there is a gap in the next state’s WIP. In a way this is similar to Scrum in FuSca, since project teams only pull as many stories into a sprint as they can complete in the sprint’s time period.

Classic Kanban does not prescribe Scrum-like meetings, leading some coaches to promote a concept called “Scrumban” that supposedly combines the best of both. I reject the term. Using a Kanban-like board to track work for Scrum teams does not eliminate fundamental differences between the two, and the pre-Agile literature on self-organizing teams has long recommended daily standups, weekly team meetings, lessons-learned meetings, etc. Regardless of the labels used, Kanban requires less meeting time because there is little to plan.

Another problem with Scrumban leads to the primary problem with Kanban, which is its misuse. All of the software development teams I am introduced to that are using Kanban are underperforming on productivity and predictability. By asking a few questions, I ascertained in each case the real reason for choosing Kanban was not an objective evaluation that it was the right method for the team’s circumstances. Rather it was a way to reduce griping about meeting time or process discipline.

The author of two books on Kanban provided an unexpected confirmation. Like a good scientist, I actively seek evidence against my positions. When I spotted his book subtitled Managing Large-Scale Projects with Kanban in a university library catalog, I drove a half-hour to take a look (Kniberg 2011). Despite the title, the author’s teams ended up doing retrospectives every two weeks, followed by planning meetings for the “Next Ten Features,” and considering a high-level Demo on the same cadence. Originally these were held on different cadences. The teams also added separate backlog grooming sessions a few days prior to planning. “This evolution toward a more Scrum-like model was not really intentional,” he writes. “It was just the result of a series of process improvements triggered by real-life problems.”

In a sidebar the author, a Swedish consultant who speaks at global conferences, adds: “This seems to be a general pattern: I see many Kanban teams that gradually discover (or sometimes rediscover) the value of many of the Scrum practices. In fact, sometimes Kanban teams start doing Kanban because they didn’t like Scrum and then later discover that Scrum was actually pretty good and their problems had been exposed by Scrum, not caused by it. Their real problem was that they had been doing Scrum too much ‘by the book’ instead of inspecting and adapting it to their context.” I suspect other causes, such as training failure (including failure to explain why a technique was important), partial implementation, and lack of coaching.

In short, I think Scrumban is probably just Scrum, and my argument with using Kanban for projects is the same I have been fighting for decades with people resisting a disciplined approach to project management. To repeat, if you do project work, any formal project management method will provide significant benefits to customers, finances, and employees. But it will require a significant amount of meeting time and discipline. I always insist project teams switch to Scrum, and always see measurable benefits. Kanban is not a project management method; it is intended to manage repeatable work that does not require pre-planning at the unit level (or more accurately, has been planned in a larger context using other methods).

In a similar vein, Kanban can be used as a bandage to cover bigger problems. A human resources, accounting, or supply chain team preferring Kanban may be in reactive mode instead of doing strategic planning with its stakeholders using Scrum. A claim that “everybody only works on their own stuff, so no one else can provide input” suggests over-specialization and a severe risk from “Won-the-Lottery Syndrome.”[2] When a customer support team, internal or external, is getting a lot of calls that need immediate response, that indicates one or more of these problems:

  • Your company has a weak approach to quality, allowing a lot of escaped defects.
  • Your deliverable is not easy to use.
  • Your user documentation and training is poor or makes finding specific instructions difficult.

In short, rather than making it easy for your end users to fish for themselves, your company is having to give them fish.

Before simply adopting Kanban instead of Scrum, ask some tough questions to identify why people believe it is more appropriate. Reasons that are really problems in the enterprise should stimulate continuous improvement projects to fix them. In project teams, Kanban may be an appropriate bridge to manage an existing workload. But the team should begin a transition to “Self-Directed agile” or Scrum to maximize the benefits of teamwork.

Given all that, and the value of short-term deadline pressure discussed earlier, I obviously believe most teams in any enterprise will perform better using Scrum. (I have successfully converted technical support teams to Scrum.) After issues like those above are solved, Kanban is only appropriate for teams whose time is mostly spent on work that:

  • Is primarily reactive and cannot be proactive,
  • Must change more frequently than weekly, and
  • Can be produced that quickly.

Kanban Overview

The Origin of Kanbans (Yes, Plural)

Drawing of a stack of index cardsKanban was invented by Toyota as a way to control parts production, prevent delays, and limit the costs of creating and storing excess inventory. People involved in Kanban’s evolution explained in 1977, “In order to avoid such problems as inventory unbalance and surplus equipment and workers, we recognized (the) necessity of schemes adjustable to conform with changes due to troubles and demand fluctuations.”[a] One adjustment was to have the final assembly line withdraw parts on demand (“pull”) rather than trying to predict how many parts of each type are needed (“push”). “Toyota sees the stock on hand as being only a collection of troubles and bad causes,” these originators wrote. The system extended outward to the production of parts as well.

There are many variations of the (pre-robot) process, but here’s a basic description summarized from the sources I found. A kanban is just a plastic card naming a part and a set number of pieces. When the last of one part in a bin is used at Station 2, its operator moves the empty bin to the output side of Station 1. The Station 2 operator places the kanban for those parts in Station 1’s kanban holder, typically a standalone post with card slots. There can be multiple bins for a part, each calling for the same number of parts.

Meanwhile, when a bin gets filled at Station 1, the Station 1 operator moves the bin to Station 2’s input side, and places the card saying those parts are ready in the holder for Station 2. If the distance is short enough, there might only be one bin rack between the stations, so only the kanban would be moved between holders.[b] Operator 1 then draws the top card in Station 1’s holder to know what to work on next.

Clearly this means each workstation can produce and use a variety of parts. It is critical to note that those parts are standardized, and each operator can do everything needed to create that part at one station. In other words, no direct interaction between operators is needed to create a part.

Nor are there frequent design or process changes. There will be occasional changes to a part, or entire assembly line, when new models come out. But those were relatively rare compared to software development, due to the substantial costs of making changes in manufacturing. Most days the work is routine. One reason people are trained on different machines is so they can switch tasks regularly to prevent boredom.

Kanban evolved in manufacturing to emphasize five principles, a journal article explains:

  • “visualize workflow”
  • “limit work in progress (WIP)”
  • “measure and manage flow”
  • “make process policies explicit”
  • “use models to recognize improvement and opportunities”[c]

Notice that the WIP limit is a key feature. “If there is no explicit WIP limit and no signaling to pull new work through the system then it is not a Kanban system,” one research team stated flatly.[d]

A presentation at a systems engineering conference explained why. “WIP limits accomplish several goals: they can lower the context-switching overhead that impacts individuals or teams attempting to handle several simultaneous tasks; they can accelerate value by completing higher value work before starting lower value work; and, they can provide for reasonable resource work loads over time.”[e]

Kanban has spread far beyond those origins in manufacturing, for example to HR departments,[f] restaurants,[g] and of course, software.[h] For project work, the most minimal form of Kanban re-creates the kanbans as sticky notes, and the holders as a chart on a wall. The chart has columns showing a backlog and the state of a card when in progress, like the Paper Option I described without the “Sprint” designation.

There are only three absolute rules in Kanban, per every book or journal article I’ve read:

  • Rank-ordering of the cards in the backlog.
  • Clear definitions of the criteria that must be met for a card to move out of a column.
  • To reiterate, a WIP limit, either by column or for the whole board, which is the maximum number of cards that can be in play at any time.

By the way, the point to kanbans was not to make tasks more visible to managers. Quite the contrary: “The cards are used to visually represent work items… for the teams to self-organize by assigning their own tasks and to complete work without direction from a manager,” a review of software-related studies said.[i] A team leader or so-called “Kanban Master” who uses a Kanban board to assign work has quite entirely missed the point.

FuSca Process Flow

Like my approach to Scrum, my approach to Kanban alters some common ones based on my teamwork research and experience with Agile-at-scale. At a high level, here’s how it works within the Full Scale agile™ (FuSca™) system:

    1. The team sets up a Kanban board in a tracker and defines WIP limits for one or more “in-progress” story states.
    2. Customers (end users or “Customers” as defined under the “Sprint Process”) submit requests for help.
      Note: Some digital trackers have means for direct entry by people who are not regular users.
    3. The team converts those requests into user stories and rank-orders them, with the Team Guide having the final call.
      Note: Most stories are equivalent in size to tasks in FuSca Scrum, small enough to be handled by one person in one workday at most.
    4. When a team member moves a story out of a column (state), and that creates or adds space under the column’s WIP limit, they or the next available member:
      1. Moves into that column the highest-ranked story for which the member has the needed skills in the previous column.
      2. Begins work on it.
    5. Stories considered done are moved to the appropriate state and submitted to the requester for testing.
    6. If the requester:
      • Agrees—The story is accepted.
      • Disagrees—The reasons are recorded in the story card, and it is returned to the backlog for rework as soon as a WIP slot is available.

Anyone who has worked with a customer support or “help desk” team should find these steps familiar. Those teams may already have done much of the preparation work necessary for adoption of formal Kanban.

Team Meetings

As I said, there are no ceremonies in traditional Kanban. However based on my previous teamwork consulting, I ask Kanban teams in FuSca organizations to hold Daily Standups (minus the burndown chart review) and weekly team meetings including Retrospective Sessions. The agendas for these meetings are the same as those already described for Scrum.

Some Kanban teams also hold triage meetings like those described for defects under “Triage and Resolve Defects,” but for all types of requests. Depending on the size of the requests, this could happen as often as a couple times a day, or as little as weekly.

Guidance Roles

There are significant differences between the Guidance Roles I described for Scrum and those for a Kanban team. The most similar is the Team Guide (“Product Owner” in classic Scrum). Most of the tasks under “Team Guide” apply, except that pre-grooming sessions and the Planning and Demo ceremonies go away. Also, TGs do not “accept” stories. Often the TG is an appropriate “second set of eyes” who reviews quality before the deliverable goes to the requester, but the requester almost always accepts or rejects the work. The only exception might be technical requirement stories generated within the team, usually for continuous improvement.

By definition there is no Scrum Master when you aren’t doing Scrum. The coaching part of that role falls to the TG. The facilitation part is much smaller because you are only doing Standups and Retros. The TG can do that, though I prefer they not do so lest they be treated as a team leader. The Standups don’t really require facilitation. For the Retros, rotate the facilitator role among all members or willing volunteers, as I recommend for the Facilitator role that replaces the Scrum Master in FuSca. (See “Meeting Facilitation” for help with the role.)

Depending on the nature of the team’s deliverables, you will likely support either:

  • A Customer, and possibly Architects and Agile Liaisons, like those for Scrum teams, probably shared with Scrum teams (see “Cross-Team Roles”).
  • A set of Scrum teams within an Agile program, such that each of their TGs are your customers.
  • Many customers, meaning a relatively large number of people who can request your services.

Obviously your work intake process will differ depending on which is true, which I will cover further down.

WIP Limits

Since Kanban teams don’t have timeboxes, the Agile Performance Standards related to delivery rates don’t apply. These teams don’t use capacity planning, so they need another means to maintain a sustainable pace. And there is no means for controlling scope change based on iterations.

The answer to all of these is the WIP Limit. The most egregious misuse of Kanban I have witnessed, and I have witnessed it all too often, is the lack of WIP limits. Let me be blunt: If you don’t have a WIP limit, you are not doing Kanban. To me, the WIP limit is nearly the entire point to the system. I note in “Choose Daily Tasks” under “The Sprint Process” that humans cannot multi-task well, according to scientific research. In an example relevant to Kanban, a six-year study of 31 judges found that the more cases on average a judge kept open at any one time, the longer it took him or her to complete any case on average, and the bigger the backlog the judge built up. The scientists accounted for issues that could impact case length, like its complexity.[3]

Under FuSca, Kanban teams replace the “100% delivery” performance standard with this one: “Never exceed any WIP limit, and be within two cards most of the time.” That is, if a column has a WIP limit of three, you never have four cards in it and and rarely one or zero. This standard ensures full productivity without overcommitment, to meet the Agile Manifesto principle about a “sustainable pace.”

Prepare for Kanban

Organize the Team

All of the steps related to gaining buy-in for and organizing Scrum teams apply to Kanban teams as well. At minimum, you need to create a team charter, identify Team Guides, and decide how to handle meeting facilitation.

Those on an experienced customer support or similar team probably already have a work tracking tool (“tracker”), and policies for triage of requests. Those folks can skim the next few sections and related steps that you haven’t covered already, and focus on the WIP limit. However, if you are supporting FuSca teams using a different tracker, you will need to switch to it presuming it has Kanban boards. (Some request trackers and Agile tools can be integrated instead.) This will greatly speed interactions between you and your internal customers, and allow each side and your stakeholders a more accurate view of progress.

Everyone else has a lot more preparation work to do!

Determine States and Exit Criteria

A paper tracker can easily be created the same way for Kanban as for Scrum. Every digital tracker I have used had a storyboard feature that would work for Kanban, and bug-tracking tools are essentially Kanban tools, although they may use lists instead of card-like interfaces. A board on a wall using notecards and masking tape might look like this:

Matrix with four columns and cards moving through them in different states

Kanban teams often have more states in their trackers, because these encompass the handoffs covered by tasks in a Scrum story. In fact, I recommend you think of the states as tasks. A team producing rapid-turnaround deliverables to customers, for example, might use:

  1. New—Not yet evaluated by the team.
  2. Ready—Reviewed, formatted, and rank-ordered.
  3. In-Progress—Under development or getting produced.
  4. Blocked—Blocked and on hold, meaning you have done all you can to clear the blocker.
  5. Testing—Under formal testing, or under review by a second team member.
  6. UAT—Submitted to the requester for sign-off.
  7. Accepted—Approved by the requester.

Think through the steps every typical request must go through, and put a state for each in your tracker.

Next define the “Exit Criteria” for each state. These are mini “Definitions of Done,” the general actions that must be accomplished before a story can be moved to the next state. My definition for the “Ready” state above is an example. With minor wording changes, you can figure out the rest, such as:

  • In-Progress:
    • Development complete.
    • Self-tests complete and passed.
    • Documentation updated.
  • Testing:
    • Tested by peer and passed.
    • Documentation reviewed.
  • UAT:
    • Approved by requester.
    • No defects open.

A digital tracker may have a function to enter these criteria in each column. If yours doesn’t, put them into your team’s process documentation. To save space on a paper tracker, I recommend putting them on the back of the column label note cards “upside down” to the label. Tape the card to the board only on its top edge, and viewers can simply flip up the card when they need a reminder.

Feed the Backlog

Receive Requests

As I said before, the method you use for creating stories will depend on who your customers are. For teams working with internal Customers and/or other Agile teams, the method is the same as for Scrum teams. Insist they provide user stories in the standard format to gain all the benefits already described. As with Scrum teams, those folks enter stories either directly into your backlog or through your TG. Unless the requests are entirely routine—meaning almost always a repeat of previous stories—I strongly recommend the TG hold meetings regularly with a Customer as described in the section on “pre-grooming.” Though in Kanban there is no team-wide grooming, this will reduce the chances of people wasting time due to misunderstanding the story. In fact, the lack of grooming makes this a greater risk in Kanban.

Teams supporting many customers will need one or more methods for getting requests into the tracker. I strongly recommend a digital tracker with a means to enter requests. In some cases, tools provide separate Web interfaces from which your team can import requests as user stories after a team member reviews them. When supporting internal requesters, you may choose to give them user permission to enter items directly into the Product Backlog.

Convert Requests to Stories

Some teams do entirely routine work, in which case you need merely create standard cards or selection menus in a digital tool. If you can get away with first-in, first-out priorities, this makes the intake process simple.

In all other cases, each nonroutine request must go through a triage effort similar (if not identical) to that described under “Triage and Resolve Defects.” Each must be checked for format, or at least content, and all requests must be rank-ordered against each other.

The first question is whether the request will be done at all, of course. “Reasons, not Excuses,” has a list of the few types of defects that might not be fixed. Even in those cases, you need to communicate the decision and reason in hopes of maintaining customer satisfaction. Tough customers like me may not agree with your decision, but from personal experience I can tell you satisfaction is higher from a disappointing communication than when a request “drops into a black hole.” Those stories that will not be worked in any way can be deleted, per the Agile principle de-emphasizing “comprehensive documentation.” Then again, a high volume of requests may make that impossible, in which case you can add a story state like the standard “Won’t Fix” from bug-fixing applications.

Next you need information necessary and sufficient to do the work. At minimum, you need Acceptance Criteria. Review each request to see if you understand what deliverable would make the requester happy. Without that, you are likely to waste time and unlikely to satisfy the customer, as explained in “The Power of Acceptance” and preceding sections about story formatting regarding Scrum. Block the story and contact the requester, asking questions specific enough to elicit Acceptance Criteria.

For defects or functional requests, I’ve yet to see a more effective means of specifying needs than the classic “steps to reproduce” format:

Information Needed Instruction Response
System/Tool Used What tool are you using? For SW, what section or menu item?
Step 1 Enter the first thing you did or want to do.
Step 2 Continue with up to 5 total steps.
Step 3 —
Step 4 —
Step 5 —
Expected Result What did you think would happen?
Actual Result What did happen?

A digital method of entry might provide, or allow you to create, a form with required fields that convert to the user story format (who, what, why) and Acceptance Criteria. Depending on the nature of your work, you may not need the level of detail above to create Acceptance Criteria. But my point still applies: Find a way to get a clear requirement.

Next someone must review new requests and determine what to do with them. Options include:

  • The TG, who will need to name a backup when absent.
  • A designated triage person or subteam for the day—as discussed under “Triage and Resolve Defects,” you will need to set a schedule if more than one person is involved.
  • In low-volume cases where only one or two people can do each type of request, those people as they become available.

Finally, who rank-orders the requests, using which criteria? Business value is easy to rank if your customers are other FuSca teams:

  1. True emergencies.
  2. Shared stories in a Scrum team’s current sprint.
  3. Stories that have dependent stories near the top of a Scrum team’s backlog.
  4. Independent stories rank-ordered by the same criteria used by the program Customer(s), plus technical requirements.

Otherwise, gather requester representatives to get their input, including external customers if available, and create a list in your process documentation to refer to during triage.

When working with Scrum teams, it is critical to honor any team promises you make regarding dates. A Scrum team story with a dependency on one of your stories will be blocked until you get yours done. For work that must be done in close coordination, the team will pull its story into a sprint based on when you say you can be ready. In either case, failure to rank-order your work in accordance with your conversations with the other TGs can cause their teams to fail in their sprints. When you have any hesitation about promising something, don’t promise.

Along those lines, your team members may be asked to sit in Grooming Sessions, or Planning or Demonstration ceremonies, specific to shared work. Doing so will make life easier for both sides. There’s no need to create stories for the meeting time, however. Depending on the size of your stories, either the participants won’t take any during that time, or their stories will stay in-progress a little longer.

Set the WIP Limit

There are many methods described in books and on the Web for setting your initial WIP limit. Teams that already have been using partial Kanban or a similar method for tracking the flow of work will have data to suggest the WIP. Use the “throughput” metric, which tells you how many items you complete in the appropriate time period. Assuming the items you were tracking are similar in size to stories as I have defined them (or can be recalculated to match), your average throughput per day is a good place to start. We want stories to be a day or less; if your team completes five requests per day on average, a WIP of five stories makes sense.

Otherwise, I suggest you start with two stories per person per day. This allows progress on one story when another is blocked or otherwise cannot be worked on (while a test is running, for example). Depending on the nature of your requests and skill sets, you may want WIP limits on more than one column. In the example set of states I gave you earlier, you might need limits on both the “In-Progress” and “Testing” states.

A digital tracker should have a means for entering the limit in each column, and will probably make obvious when you are trying to exceed that limit. One I’m aware of turns the whole column red! On paper trackers, add the number to or below the column label card.

With all of the decisions above made, you can start running your Kanban process.

Go with the Flow

A Day in Kanban

On a typical day, each team member will go to the board, move the highest-ranked story for which they have the needed skills into the next column, and start working on it. Once it meets the exit criteria, they move the story card into the next column. In the preferred scenario, that state requires someone else, in the best case a cross-trained peer, to review the work. The initial team member then goes to any column they wish whose next state has room in the WIP limit and grabs the top-ranked story that member can do.

For example, say Bakari is on an efficiently cross-trained (“full stack“) team where everyone can do everything that uses the states I listed earlier. He goes to the team’s tracker, selects the top story in the “Ready” state, and moves it to “In-Progress” (which has two stories in it, and its WIP limit is four). When he’s finished, he moves it to “Testing,” which is at its limit of four. The team uses peer testing, so he takes another one of the cards in that column and checks the work. If he finds a defect, he notes that on the story card and fixes it unless something prevents that (see next section). Once the defect is solved, what happens next depends on the team’s processes. Bakari either indicates that on the defect and leaves it in the Testing column for someone else to peer-review, or simply moves it to the next column. A glance at the board might tell him he must draw a card from a particular column to free up room under its WIP limit. Otherwise he can choose whichever he feels like doing. So goes the day.

Deal with Blockers and Story Defects

Most of the Scrum practices related to blockers[4] and to defects[5] related to specific stories can apply to Kanban. When a story is blocked before work starts, leave it in the backlog—in the “New” or “Ready” states in my example set above. Once work has begun, however, the person working the story should mark it as blocked with a reason listed and do everything they can to remove the blocker. While waiting on a response or fix, if there is room in your WIP to start another story, do so. Otherwise, move the story to a “Blocked” state, or just backward by one column, at the top of the column. Although many coaches disagree with this approach, I think it acceptable to move an item backwards on the board in this one circumstance, to maximize productivity.

Note that a blocker within the team’s control is not a blocker, just a technical issue team members must work out. A defect found during team or requester testing fits that bill as well. Create a defect card in your tracker and attach it to the story (on paper trackers, I suggest a small sticky note). Leave the story where it is and tackle the blocker or defect. By contrast, clearing a blocker from outside the team is not considered “work” on the story in the sense of taking up WIP, as long as it amounts only to the occasional follow-up contact. That’s why I think it can be moved backwards or to “Blocked.”

There is no Facilitator, so the person who owns the story at that point is responsible for clearing the blocker. As the Team Guide has primary responsibility for coordinating with other teams, the TG can provide assistance when other teams are causing the blocker.

Once the blocker is cleared, simply remove the “blocked” indication on the story card and, if needed, move it to the top of its column. If the next column’s WIP is full, you cannot work on it. However, when a WIP slot opens up, the unblocked story takes priority over stories not yet started, obviously, since it had to be ranked higher to have already been started!

Respect and Refine the WIP

Members should have the self-discipline to respect the WIP. As long as a story is not blocked, there is no reason not to be working on it and only it. Sometimes, especially in the early going, the TG has to do some coaching the way a Facilitator does in Scrum. Recognize this as an investment to speed the team up by preventing multi-tasking.

Leave the WIP as-is for the first few weeks while you learn the process. Should people run out of work, refer to “Find New Work.” (Working out of the backlog is cheating in Kanban, but we’ll tolerate it until the WIP is refined.) In that circumstance, after those few weeks, raise the limit a little in the next weekly team meeting, and repeat the process every two weeks until the “idle hands” scenario is rare.

Pay attention to skill-set issues, though. Having most people run out of work is a WIP problem; the same one or two individuals running out of work is a skill-set problem. Make use of the guidance under “Cross-Training,” creating separate stories for each person’s role (trainer versus learner) instead of tasks.

One bad scenario bears scrutiny. If people can only work in one state due to skill sets, and more than one state has a WIP limit, the limits should be set such that one “slot” is open almost all the time in each—that is, if the WIP is four, keep three stories there most of the time. This allows someone who finishes up another state to move a story into one with a WIP limit. Say a team using my example story states put WIP limits on both “In-Progress” and “Testing.” It could happen that a story met the Exit Criteria to move out of “In-Progress,” but all of the slots were full under “Testing.” Assuming the story owner could only do “In-Progress” stories, the owner would be stuck until a tester finished a story in the next state. (In that scenario, the team will need to decide how to indicate on that story card that the story is ready to move.) The obvious way to eliminate this problem is cross-training. Then the person finishing the “In-Progress” story would also know how to do testing, and thus would grab a story under “Testing” to open a slot.

The easiest evidence that the WIP limit is too high is that people are putting in overtime. Remember the Agile principle: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” Another is that members often juggle more than two stories at once. A primary goal of Kanban is to speed up the team by reducing multi-tasking. Another indicator, ironically, is that the limit isn’t often hit. When your “Testing” WIP is 4 and most days only three stories are in play, the WIP is higher than the team can do. This may suggest, again, a need for cross-training. Using my example states, a team staying within its “In-Progress” limit, or tempted to raise it, while not hitting the “Testing” limit, needs cross-training between the testers and developers so the latter can take up testing tasks. Recall that in original Kanban, each station operator could do all of the tasks at that station (and usually at multiple stations, I’ll add).

An inability to keep the backlog clear—that is, to match the number of incoming and outgoing stories—is not a WIP limit issue. Raising the limit to fix this is like a Scrum team member reducing her task hour estimates to squeeze more work into her capacity, or a team taking on more stories than its velocity in the hope of getting them done. It is an irrational approach that will not work. This problem is either a symptom of one of the larger issues detailed under “A Question of Frequency” above, such as poor quality creating too many bugs, or the Kanban team does not have enough people.

Manage Individual Contributor Work

Drawing of a medieval astronomerIndividual contributors (ICs) are people with roles so singular and limited in scope, they do not fit logically on any one team. The best reason to have such a role is that there is only enough work of that type for one person to do, and it requires enough specialized knowledge that it would not be efficient to cross-train a team on the skill. Valid examples I have seen include:

  • A senior engineer whose primary job was advanced research to lay the groundwork for future products, trying to keep the company ahead of the market.
  • A hardware engineer who tracked vendor deliverables.
  • The one human resources generalist, procurement person, certification specialist, marketer, etc., in a small company.

Though having ICs in these roles is reasonable, it also presents the same “Won-the-Lottery” dangers to the company as any subject-matter expert on a team. I urge companies to insist that any ICs cross-train at least one backup, at least to the degree that person can handle routine work while the IC is out or a new specialist is hired. Under the “sustainable pace” principle, everyone in your enterprise should feel they can take a vacation without the function grinding to a halt.

Unfortunately, I often see people in IC roles for the wrong reasons, like they refuse to cooperate or be transparent with a team, or their job went away, and so on—and management doesn’t have the courage to fire them. I’m thinking of a former program manager at a government facility I worked at. He got booted out of the program he was running because he botched it, and he irritated most people he interacted with. Yet he was given a “Special Projects Manager” slot. No one was sure what he did all day. Either he had a friend higher up who couldn’t separate the personal from the business relationship, or his supervisor didn’t want to go through the significant hassle required to fire a government employee.

Another example was a software developer who was slow in his work and refused to participate in a Scrum team, but was kept on because his large corporation had a ridiculous blanket ban on new hiring for months—even to backfill a position! He was relegated to helping Customer Service reps with more complex tickets, which wasn’t full-time work and could have been handled by the teams.

On the other hand, this type of role supports “neurodiversity” efforts, which try to create workplaces where people with different social orientations can work together. In this case, many people who fall on the autism spectrum are fully capable of working, often excelling at valuable skills. But some would not be comfortable speaking up in team meetings like the Scrum ceremonies. To avoid stereotyping and try to gain the value of each person’s perspective, it is important to include all individuals on teams first, implementing suggestions on this site for an introvert if applicable. Should someone prove unable to participate, however, a reasonable accommodation is to create an IC role for that person. These individuals may find the Agile Tracker a more pleasant way to accept and report on tasks than direct communication, and need someone else on the team to present for them at Demos.

Regardless of how the ICs got there, employers have a right to know what they are getting from those folks for their money. They want ICs to maximize productivity, just like Scrum and Kanban team members. And when Agile teams are dependent on ICs or vice versa, you want those dependencies and any blockers to be as clear as they would be between two teams. Kanban is the way to accomplish all of this.

Effectively you treat an IC as a “team of one,” more specifically as the Team Guide of that “team.” Almost everything in the Kanban content of this site applies, except of course the meetings and the “Organize the Team” section above. Therefore, to the degree possible given any neurodiversity issues:

  • The IC should identify Customer(s) or customers.
  • They need their own Kanban Board in the tracker, or their own paper tracker.
  • Work requests from or given to Agile teams, or for Customers of those teams, need to be in the standard story format.
  • The IC must establish and stick to a WIP Limit, for the same reasons a team needs one.
  • When supporting only one or a few Customers, the IC will hold a weekly meeting with them to ensure alignment on needs and priorities, equivalent to a Pre-Grooming Meeting.
  • If supporting Scrum teams:
    • Attend invitations to Grooming Sessions when invited.
    • Honor date commitments related to stories in sprints.
    • Attend Demonstration Ceremonies to ensure they understand the bigger picture and show their own work.
  • If supporting programs that follow FuSca, the IC and Agile Release Manager should decide whether it would be helpful to the teams to have the IC participate in the Phase 2 Release Planning like a TG (explained under “Plan in Releases“).

In short, anywhere the word “team” or “TG” appears in the steps linked below, substitute “individual contributor” if you are one. Unless the action makes no sense when applied to one person (like creating meeting rules), the concept probably applies to you, too.

⇒ Steps: Use Kanban

↑ System | ← Prepare for the New Sprint | → Plan in Releases

[1] See “Planning for the Unplannable.”

[2] See “Cross-Training.”

[3] Coviello, D., A. Ichino, and N. Persico (2010), “Don’t Spread Yourself Too Thin: The Impact of Task Juggling on Workers’ Speed of Job Completion,” National Bureau of Economic Research, Working Paper 16502.

[4] In “Blocks to Progress”; “Check the Blockers”; and “Block Early and Often.”

[5] See “Create a Quality Mindset.”

[a] Y. Sugimori et al., “Toyota Production System and Kanban System Materialization of Just-in-Time and Respect-for-Human System,” International Journal of Production Research 15, no. 6 (January 1977): 553–64, https://doi.org/10.1080/00207547708943149.

[b] C. Sendil Kumar and R. Panneerselvam, “Literature Review of JIT-KANBAN System,” The International Journal of Advanced Manufacturing Technology 32, no. 3–4 (February 21, 2007): 393–408, https://doi.org/10.1007/s00170-005-0340-2.

[c] Muhammad Ovais Ahmad et al., “An Empirical Study of Portfolio Management and Kanban in Agile and Lean Software Companies: An Empirical Study of Portfolio Management and Kanban in Agile and Lean Software Companies,” Journal of Software: Evolution and Process 29, no. 6 (June 2017): e1834, https://doi.org/10.1002/smr.1834.

[d] Muhammad Ovais Ahmad et al., “Kanban in Software Engineering: A Systematic Mapping Study,” Journal of Systems and Software 137 (March 1, 2018): 96–113, https://doi.org/10.1016/j.jss.2017.11.045.

[e] Richard Turner et al., “Effectiveness of Kanban Approaches in Systems Engineering within Rapid Response Environments,” Procedia Computer Science, Conference on Systems Engineering Research, 8 (January 1, 2012): 309–14, https://doi.org/10.1016/j.procs.2012.01.065.

[f] Ahmad, Muhammad Ovais, Denis Dennehy, Kieran Conboy, and Markku Oivo. “Kanban in Software Engineering: A Systematic Mapping Study.” Journal of Systems and Software 137 (March 1, 2018): 96–113. https://doi.org/10.1016/j.jss.2017.11.045.

[g] Resalin Rago, “Agile and Lean Lessons from the Restaurant Industry,” Agile Velocity (blog), March 15, 2017, https://agilevelocity.com/agile/order-agile-lean-lessons-restaurant-industry/.

[h] Ahmad et al., “Kanban in Software Engineering”; Staats, Brunner, and Upton, “Lean Principles, Learning, and Knowledge Work”; Ahmad et al., “An Empirical Study of Portfolio Management and Kanban in Agile and Lean Software Companies”; Denis Dennehy and Kieran Conboy, “Identifying Challenges and a Research Agenda for Flow in Software Project Management,” Project Management Journal 49, no. 6 (December 2018): 103–18, https://doi.org/10.1177/8756972818800559; Paulo Sérgio Medeiros dos Santos et al., “On the Benefits and Challenges of Using Kanban in Software Engineering: A Structured Synthesis Study,” Journal of Software Engineering Research and Development 6, no. 1 (October 19, 2018): 13, https://doi.org/10.1186/s40411-018-0057-1.

[i] Ahmad et al., “Kanban in Software Engineering.”

Share this page