- A Question of Frequency
- Kanban Overview
- Prepare for Kanban
- Manage Individual Contributor Work
Scrum teams have ways to deal with unplanned work, 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 Agile method called “Kanban.” Invented by Toyota to support car production, Kanban is useful for relatively small work products created and released continuously, without possibility or need of 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. Think back to the task and story states used in my Scrum examples (as in “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, since 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. You’re just doing best practices for any kind of team, and using Kanban as your formal work-management method. 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. (Usually that’s the reason a client calls me about them!) 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 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, they 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. They 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.” 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 Scrum by using it for the improvement project.
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.
To prevent repeating a lot of content, I am going to assume you have some understanding of the material covered so far in this site, or access to someone who does. Anyone only interested in Kanban would have bought a book on that! I’ll re-use terms from Scrum to explain the process, including some not traditional to Kanban. (The step sets of this Kanban topic have cross-references to the relevant Scrum sets.)
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 Stack Scrum™ (FuSS™) system:
- The team sets up a Kanban board in a tracker and defines WIP limits for one or more “in-progress” story states.
- Customers (end users or “Customers” as defined earlier) submit requests for help.
Note: Some digital trackers have means for direct entry by people who are not regular users.
- The team converts those requests into user stories and rank-orders them, with the Product Owner having the final call.
Notes: Most stories are equivalent in size to tasks in Scrum, small enough to be handled by one person in a day or two of labor hours at most.
- When a team member moves a story out of a column (state) with a WIP limit, he, she, or the next available member:
- Moves in the highest-ranked story in the previous column for which the member has the needed skills.
- Begins work on it.
- Stories considered done are moved to the appropriate state and submitted to the requester for testing.
- 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.
As I said, there are no ceremonies in traditional Kanban. However based on my previous teamwork consulting, I ask Kanban teams in FuSS organizations to hold Daily Standups (minus the burndown chart review) and weekly 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 requests. Depending on the size of the requests, this could happen as often as a couple times a day, or as little as weekly.
There are significant differences between the Guidance Roles I described for Scrum and those for a Kanban team. The most similar is the Product Owner. Most of the tasks under “Product Owner” apply, except that pre-grooming sessions and the Planning and Demo ceremonies go away. Also, the PO does not accept stories. Often he or she 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 Product Owner. The facilitation part is much smaller because you are only doing Standups and Retros. The PO 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, either rotate the facilitator role or let other member(s) who are willing run them, just like the Facilitator role that replaces the Scrum Master in FuSS. (See “Meeting Facilitation” in The SuddenTeams™ Program.)
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 “Guidance Roles”).
- A set of Scrum teams within an Agile program, such that each of their POs 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.
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. The WIP limit is the entire point to the system. I noted under “Choose Daily Tasks” 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.
Under FuSS, Kanban teams replace the “100% delivery” performance standard with this one: “Remain at 90% to 100% of any WIP limits 90% of the time.” In most teams, that will mean it can only sustain a gap of one story short of WIP. This ensures full productivity without overcommitment.
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 the Guidance Roles needed and who will fill them, and decide how to handle ceremony facilitation.
Those on an experienced customer support or similar team probably already have a tracker, and policies for triage of requests. Those folks can skim the next few sections and related steps you haven’t covered already, and focus on the WIP limit. However, if you are supporting FuSS 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 customers, and allow each side and your stakeholders a more accurate view of progress.
Everyone else has a lot more preparation work to do!
A paper tracker can easily be created the same way for Kanban. 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.
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:
- New—Not yet evaluated by the team.
- Ready—Reviewed, formatted, and rank-ordered.
- In-Progress—Under development or getting produced.
- Blocked—Blocked and on hold, meaning you have done all you can to clear the blocker.
- Testing—Under formal testing, or review by a second set of eyes.
- UAT—Submitted to the requester for sign-off.
- Accepted—Approved by the requester.
Think through the steps every typical request must go through, and put a state for each in your tracker. You can always add tasks to a story if you want to break it down further within a given state, or skip a state if it isn’t relevant. Usually this is only true for “reminder” tasks, meaning steps that aren’t typical for that kind of story.
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:
- Development complete.
- Self-tests complete and passed.
- Documentation updated.
- Tested by peer and passed.
- Documentation reviewed.
- 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.
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 PO. Unless the requests are routine—meaning almost always a repeat of previous stories—I strongly recommend the PO 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 requestors, you may choose to give them user permission to enter items directly into the Product Backlog.
Convert Requests to Stories
Next comes a triage effort similar (if not identical) to that described under “Triage and Resolve Defects.” Each request must be checked for format, or at least content, and rank-ordered.
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. 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:
|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.|
|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 like this. Depending on the nature of your work, you may not need this level of detail to create Acceptance Criteria. But my point still applies: Find a way to get a detailed requirement.
Next someone must review new requests and determine what to do with them. Options include:
- The PO, 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 if your customers are other FuSS teams:
- True emergencies.
- Shared stories in a Scrum team’s current sprint.
- Stories with dependent stories near the top of a Scrum team’s backlog.
- 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 POs 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.
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 a week on average. 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.
Deal with Blockers and Story Defects
Most of the Scrum practices related to blockers and to defects related to specific stories 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 Scrum Master, so the person who owns the story at that point is responsible for clearing the blocker. As the Product Owner has primary responsibility for coordinating with other teams, the PO can provide assistance when other teams are causing the blocker.
Once the blocker is cleared, simply remove the “blocked” indication on the story card. As long as the WIP is full for the state needed to move forward, you cannot work on it. If or 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!
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 PO has to do some coaching the way a Scrum Master 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, he or she 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 could 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 training tasks.
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.
Individual 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 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 (but not all) 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 try all individuals on teams first, implementing suggestions on this site for an introvert if applicable. Should they 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 Joint 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 are between those teams. Kanban is the way to accomplish all of this.
Effectively you treat an IC as a “team of one,” more specifically as the Product Owner of that “team.” Almost everything in the Kanban content of the site applies, except of course the meetings and the “Organize the Team” section. Therefore:
- The IC should identify Customer(s) or customers.
- He or she needs 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.
- Ask the PO(s) if the IC should attend Demonstration Ceremonies.
- If supporting programs that follow FuSS, the IC and Agile Release Manager should decide whether it would be helpful to the teams to have the IC participate in the:
- Joint Demonstration Ceremonies.
- Phase 2 Release Planning (like a PO).
In short, anywhere the word “team” or “PO” 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
 Coviello, Ichino & Persico 2010.