Chapter 1. Team Kanbaneros gets started

Marcus and Joakim are at a conference presenting a practical introduction to kanban. They’re finishing the presentation; let’s join them in action.

“To sum up: kanban is an approach to software development based on the principles of Lean. It has quickly been picked up by many organizations around the world. You can pick it up too! Starting tomorrow, you should stop starting and start finishing. And with that,” Joakim concluded, “our quick, practical introduction to kanban ends. But remember what we said earlier—you could get started tomorrow. Getting up and running with this isn’t hard—the effects can have a dramatic impact on your productivity.”

“Thank you all for coming! We’ll be hanging around here for a couple of minutes if you have any questions,” Marcus added, trying to close the discussion in order to end the presentation on time—for once.

As Joakim started to clean the whiteboard and remove all the stickies from the wall, Marcus answered a couple of quick questions, pointing some people to the slides available for download as he headed toward the exit. He didn’t get far, though. Halfway to the exit a woman abruptly stopped him.

“What’s this? Why are you leaving? Don’t tell me we missed it all?!” The woman looked disappointed and almost as though she’d been cheated.

“Missed what? The presentation? Yes, it just finished, but you can catch the video online,” Marcus replied.

“Oh no!” she cried out. “We only came here for this presentation! It looks like someone missed the starting time of the presentation.” She nodded toward a man leading a group into the room.

“Well, we’ll probably do something in the autumn as well if you want to see the live presentation,” Marcus said, trying to smooth things over.

“That won’t cut it—we want to get started right away! Our whole team is here; even the business guys were joining us for this tutorial, on my recommendation.” She looked genuinely sad. “Hi, I’m Daphne, by the way.”

“OK; why don’t you book Marcus or me for a day of consultation, then?” Joakim suggested as he joined them, introducing himself to Daphne.

“Well, we could, but there have been quite a lot of complaints from both the team and people working with it already. We wanted to do something about this and hoped that we would pick up something to help today.” The words came from an imposing man who had caught up with Daphne.

“What kind of problems are you talking about?” Joakim asked the man.

“The team feels swamped with work, and people who are waiting for them to deliver stuff thinks it takes forever,” he said plainly.

Daphne cut in: “Despite us having a lot of work to do, we have long discussions about which project is more important to start first. Yet we still fail to pick the right one.”

“And ... well, there’s more, but we don’t want to take up your time. You were leaving, right?” the man said, leaving the question hanging.

“Unless you have a better suggestion?” Marcus replied quickly. This sounded like the beginning of a fun challenge.

“This is what we’re going to do. I’ll buy some consultation from the two of you right here and now,” the imposing boss-man said. “Your slide there on the screen says ‘start tomorrow.’ I’m giving you a chance to put your money where your mouth is. How much time can you spare?” He paused and locked his eyes on Marcus and Joakim.

“We have two hours until we need to get going,” Joakim said, looking at his watch.

“Well in that case: get us up and running with kanban in two hours,” the boss-man said, extending his hand.

“We won’t be able to help you solve all your problems, only put you on the right path,” Joakim said, looking at Marcus. They nodded to each other. “Right—we have two hours to spare. Challenge accepted!”

1.1. Introductions

The entire team was gathered in the next room. They introduced themselves to Marcus and Joakim by describing each other, a technique they seemed to be pretty experienced with, judging from the bold statements made.

“Adam is a tester. He’s been around for quite some time and is almost always skeptical: of new stuff, of the others’ capabilities, but mostly of the quality of the work the others do. He tries to deliver his criticism in a nice way; sometimes he succeeds.”

“Adam likes to work his way. He doesn’t like change—change means regression testing.”

“Beth is a new employee. She’s responsible for requirements analysis on the team. That includes everything from asking the business what it wants and writing it down to making sure the developers understand what they should do.”

“Beth is always looking for new ways to work.”

“Cesar is the business. He practically built the first version of the application the team is working on, an internet bank, all by himself way back when.”

“Now he has left the IT part of things and is in charge of the business part of the operation. He still likes to think of himself as a developer and is often found ‘on the floor.’”

“Daphne is a kick-ass developer. She has been known to sling more code in an hour than most developers do in a week.”

“But she likes to work alone; other people slow her down. Sitting down with Cesar and deciding how stuff should work—that’s the best way to work, if you ask Daphne. Things fly out then. All these other ceremonies and hierarchies are in her way.”

“Eric is a developer by day ... because he has to be. But at night he’s a guitar hero, playing in local pubs and other venues. Soon the big break will come. Soon.”

“Writing code is all right, but it’s often hard to see why we do it.”

“Eric likes to get things done so that he can continue to answer questions on http://guitar.stackexchange.com.”

“Frank is the manager of the IT side of the operation. He has 36 people under him, and he tries to meet with everyone at least once every other month, but there are lots of other meetings to attend.”

“He cares about the product, but he has a hard time keeping up with all the new features. Frank tries to develop his people whenever he has extra time.”

“Great,” Marcus said. “I’ve found a room over here with a whiteboard in it. Do you have your stickies, Jocke?”

“Yes, of course,” Joakim replied, with his please-no-stupid-questions face. He’s an agile coach; naturally he has stickies with him at all times.

“Great—let’s go, then,” Marcus said, leading the way.

“Who can tell us what your team does?” Joakim asked when they stood around the board.

“That’s probably me,” Cesar said, pulling out his laptop.

“No, please! No slides!” Eric cried out in pain. “Tell him—we don’t have time for that.”

“Yes, you’re probably right,” Cesar responded, a bit stumped. “Here’s the short version.”

The team is a small development team consisting of the group gathered here. They work for a big insurance company with responsibility for the newly released mobile bank application. Because their team is pretty small, they can govern themselves for the most part. There’s reporting to be done to other parts of the business, but they can make their own decisions about the work they do, with Cesar having final say in every important decision. The team is in charge of creating new features in the mobile bank, as well as supporting and maintaining the software that’s in production.

“Why do you need our help?” Marcus asked. While waiting for an answer, he wrote the heading Challenges on a flipchart.

“I can probably answer a bit of that.” Frank, the project leader, stepped forward. “We’ve been experiencing difficulties in keeping up the pace of expected deliveries. There has been a lot of complaining from different stakeholders in the organization about not getting their features in time.”

“And that gets worse by the minute,” Cesar added. “People no longer trust the quality of our work, and they definitely don’t trust our estimates and delivery dates.”

“We, on the team, for our part,” Daphne added, “feel totally swamped and don’t know what to do first. When we’re trying to please everybody, it leads to sudden changes in priorities, and everything is ‘PRIO 1.’”

The team then told Marcus and Joakim that it was common for stakeholders to hand tasks directly to the team members. These requests often came from senior people in the organization, making it difficult for the developers to say no. Furthermore, those items were sometimes tasks someone else was already working on. Marcus patiently wrote down the challenges as bullet points on the flipchart.

“Thank you, but that’s probably enough,” Daphne interrupted. “The clock is ticking, you know; you only had two hours to spare, right? Let’s get practical.”

“Yeah, let’s get back to the task at hand.” Frank grew impatient now. “Where do we start?”

“We understand that you’re eager to get started,” Joakim answered. “But you should also understand that kanban is a bit different from other methods. Take Scrum or Rational Unified Process (RUP), for example; they prescribe what roles you should have, what meetings you should run, even how you should run them, and so on. Kanban, on the other hand, starts where you are, helps you understand your current situation, and helps you identify the next step to improve it.”

“Yes, it’s important for us, and for you, to understand where you are right now in order to help you,” Marcus cut in, afraid that Joakim would come across as too theoretical, “but we can definitely get started now, and you’ll understand more about this as we go. We’ll keep this list of challenges here as a sort of agenda for our short time together.”

“What is your team called, by the way?” Joakim asked.

“From now on it should be: the Kanbaneros!” Frank said, in his best Mexican accent. The rest of the group laughed, and Marcus wrote it down on the flipchart.

“Let’s start with some show-and-tell to make our work a little more visual, shall we?” Joakim began.

1.2. The board

“How do you know what you’re working on as a team and how work enters your workflow? If you’re not even sure yourselves, how could the stakeholders know, right?” Joakim went up to the whiteboard and grabbed a marker.

“Where do you keep your backlogs today?” Joakim asked. “I guess you have some kind of list of what you need to work on?”

“Of course we do,” Beth quickly replied. Joakim and Marcus could sense that she felt a bit insulted by the question. “I make sure to enter and categorize all the requirements in JIRA,^[1] our project-issue tracking system.”

¹ JIRA is an electronic issue- and ticket-tracking application from Atlassian: www.atlassian.com/software/jira/overview/.

“Yes, and I go in there as often as I get a chance and try to keep the ordering, with respect to priorities, up to date.” Frank added that he felt the project-tracking system was in good shape.

“This makes it easy to see who is working on what and the progress for each item,” Cesar added.

“Can we access your JIRA system right now?” Marcus asked, pointing to Daphne’s laptop.

“Yeah—of course,” Daphne answered, and she flipped the laptop open.

“Good. Let’s write down what you’re working on right now,” Joakim suggested. “Write each item on a separate sticky note, and keep it brief; it’s enough if all of you understand roughly what it refers to.” He opened the pack of sticky notes with his patented one-hand grip in less than a second, much to the amused admiration of the group (or so he imagined). He handed out yellow notes to the team.

“Please write legibly, using the thicker sharpies and not the ballpoint pens.” Even though Marcus had given the exact same instructions hundreds of times, he always felt a bit patronizing when doing so, but he had learned the hard way that tiny scribbling makes it much more difficult for people to understand and feel involved in exercises like these. “When you’re done, post the items on the whiteboard.”

Joakim asked the team to post the work in priority order from top to bottom. There were a couple of minutes spent running back and forth to the screen, but pretty soon six items had been posted in a nice column on the board. When the running had settled down, Joakim faced the team and asked, “Do you agree, team? Is this what you’re working on right now?”

“Yes,” came the answer, almost instantly and simultaneously from Cesar, Frank, and Beth. Adam and the developers, Daphne and Frank, looked down at the floor and said nothing.

“There’s no right or wrong here,” Marcus said. “What’s important is that we get the true picture of your current situation. Anything else?”

After a couple of seconds, Adam came clean. “Well, it’s not entirely true ... we have a lot of stuff that we do that doesn’t get entered in JIRA.”

“What are those items?” Joakim asked. “Can you give us examples?”

It turned out that those items could vary a lot both in size and in what they were: additional requirements, small support tasks, favors repaid to other departments, and maintenance of systems were some examples. Often, someone senior who wanted something done handed it to a team member in the corridor.

“Those tasks are hard to turn down,” Adam said. “We don’t know how to prioritize or what we’re allowed to say no to. But I guess we could do a better job telling you about them.”

“Well, to me it seems that we’re missing JIRA tickets,” Beth said. “If people are working on stuff that isn’t registered in there, then we can’t trust JIRA.”

“Is there anything you could do about that?” Joakim continued.

“Well, I guess it will sort itself out if we make sure to add everything to JIRA, right?” Beth said. “Then all the work will be in one place, and it’s easy to share with people who don’t sit next to us.”

“That’s right,” Joakim said. “Any drawbacks to an electronic tool?”

“Not where I stand, no,” Eric was quick to say.

“Hmmm—things often get lost in JIRA,” Beth commented. “We have, on more than one occasion, had doubles of work, for example. There’s a fair amount of searching to find anything in there.”

“How could we make work easier to find and see?” Joakim asked.

“Well,” Beth began, “we would have to see it all the time, I presume. Like writing on the wall or something.”

“Bingo!” Marcus could not hold back anymore. “Put the work on the wall! For every work item you’re working on, create a little note and put it up on the wall. You’d be surprised how big a difference such a small thing will make for your work.” Marcus knew from experience that it was a big thing for many organizations that were starting with agile development.

To see this in practice, Marcus suggested that the team create a sticky for each work item they were working on right now and then post them on the board.

“Everybody done?” Joakim asked after a minute or two. “Please post them on the board.”

Next to the previous six items from JIRA, another eight were posted.

“My God!” Frank cried out. “Is this true?”

“We told you!” Daphne said, throwing her arms out wide. “We get a lot of stuff on the side.”

“I know, but I never realized ...” Cesar scratched his head. “You’ve been through some bad, stressful times, people.”

“But that’s more than the actual work in JIRA,” Beth said, as she counted the stickies.

“That’s what we’ve been saying all along,” Eric said, changing the tone of his voice for once.

The group grew silent and gazed at the board for a while. By creating small notes that represented each work item, they had shown, in a physical way, what they were doing. Joakim and Marcus had witnessed this eye-opener for teams many times before.

“There you have information being picked out of JIRA, the electronic tool—or the ‘information fridge,’ as you like to call it, Joakim,” Marcus said. He looked at Joakim, pausing to have him explain the metaphor.

Joakim picked up the cue and explained: “A visualization on a big visible board can be called an information radiator; its information is obvious and apparent to people passing by. Electronic tools are, I think, sometimes more like fridges in that you have to open them and poke around to find what you’re looking for.” He wasn’t too sure anybody heard him, as the team stared at the pile of stickies in front of him.

“Looking back at your challenges,” Marcus intervened, “we’ve at least started addressing the confusion of who’s working on what and what work the team is actually doing, and we’ve touched briefly on prioritization.”

Beth took in the scene before her with the stickies on the board. After a minute she said, “What do we do with that pile of stickies then?”

“Yeah, stacking them on the wall doesn’t help us get more work done and keep the stakeholders satisfied, does it?” Daphne added.

1.3. Mapping the workflow

“Well, all those stickies show you that you have a lot of work in progress,” Joakim started. “But there is more you can get out of visualizing your work, like letting everyone see the progress of the different work items and what the priorities are. This will further improve transparency and help you to prioritize work as it comes to you,” he said, pointing to the list of challenges. “Let’s try to map your workflow to the board and put the stickies in the right places.” Joakim removed the cap from his whiteboard marker, ready to go at it.

“Map our what to the what, now?” Beth asked.

“Well, the items you work with flow through your system from idea, or customer request, to finished feature in production, providing value to the customer, right?” Joakim asked.

“Yes ... I guess so.” There was mumbling all around.

“Where does the work start?” Joakim asked.

“Hmmm—hard to say,” Frank said. “It depends on where you draw the line. Is it when the idea is first conceived? Or when we decide to do it, or get the approval to do it? But I guess something that’s concrete is that we register all the stuff we’re doing in JIRA, our ticket-handling system.”

“But Beth,” Cesar interrupted, “you and I have done a lot of work before that, right?”

“Yes,” Beth replied, “but that’s a bit unstructured, because it goes back and forth a lot before we decide what to put into JIRA. Sometimes it’s a big idea, and sometimes it’s a little fix.”

They decided to start the workflow when the work was registered in JIRA and to end it when the work was in production.

“I can’t see why we shouldn’t track it all the way,” Daphne said.

“OK, let’s draw the workflow as columns that the work progresses through.” Joakim started drawing columns on the whiteboard, but then he stopped. He had tried too many times to draw the board for a team, and knew that it would make the board his rather than the team’s. Luckily there was a simple solution. “Better yet; you draw them.” Joakim threw the marker into Beth’s lap.

“To indicate that some work is in a certain stage, we put the sticky in the column with the corresponding name,” Marcus explained.

“But what are the names or stages, then?” Beth looked confused, because Joakim hadn’t written any names.

“Well, that’s where you guys come in,” Joakim said with a wry smile. “We can’t do all the work for you. The stuff you haven’t done yet in JIRA—what do you call that?”

“Well ... I don’t know. Undone?” Frank said. There was laughter all around.

“How about Inbox?” Cesar suggested.

“I don’t know,” Eric said. “My thoughts go to the mailbox. And I hate email. Can’t we try something else?”

“To do,” Daphne suggested. “Or is that too simple?”

Nobody seemed to mind, and Joakim said: “That’s a great start! Remember, we want it simple and easy. If you see a need to later, you can always change it.”

“In fact,” Marcus said, raising a finger, “we suggest that you draw the board with a marker on a whiteboard. Don’t make it permanent, using tape and stuff for the columns too soon, because that might make you less inclined to change it. And you’ll have to change it as you learn.”

As Marcus talked, Beth drew a column on the board to the far left. She wrote Todo at the top of the column.

Joakim said: “OK, all the stickies that you haven’t started working on yet—move them into that column.”

The team went up to the board and started to move items around. There were some discussions and questions about what items actually meant, but pretty soon three stickies were posted in the Todo column.

“OK, guys,” Joakim called out to the group as they huddled around the board. “Let’s make it easier from the outset, and put the items in prioritized order, from top to bottom. This will be helpful later on, because you’ll be able to easily see what is more important in each column.”

“How do you go about working with the item from there?” Marcus asked. “What is the first thing you do?”

“We often sit down for a design discussion. How should this be built? What can we use from our existing platform? Should we use other teams’ components for the new solution? Things like that,” Frank said.

“There’s some documentation of our findings, as well,” Beth added.

“What would you call that?” Joakim asked.

“How’s Design as a name?” Cesar asked.

“Hmmm, not quite right. There could be a lot of different things to do. Maybe Analyze would be a better fit? What do you think?” Frank asked Marcus.

“I haven’t got a clue. It’s your workflow. Ask your team instead. What do you all think?” Marcus faced the group.

“Yeah—Analyze is better,” Daphne said, and the others nodded and murmured in agreement.

“Anything you’re analyzing right now?” Marcus asked.

The team agreed to put two items in the Analyze column.

“Continue down your workflow, following the flow to ‘in production.’” Joakim thought that Lean terms, strung together, sometimes became poetry. A quick look around confirmed that he still was alone in that belief. He coughed slightly and said, “OK, what happens after that?”

The team continued by creating columns for Development and Testing, and they added the stickies with the current work to the columns. After that, there was a brief discussion about what “done” meant. They decided to add a step in the workflow for acceptance. They settled on Accept as a column name. When asked, Adam also realized that three of the items in the Testing column were tested already and were waiting for Cesar’s approval. They decided to move those into the Accept column as well, together with another item that was already there.

Adam went up to the board and moved the stickies from Testing to Accept.

“Then what?” Joakim said. “You have your work analyzed, developed, tested, and accepted. What more needs to be done?”

“Well, we should roll it out in production, dude,” Eric said.

“And by ‘we,’ you mean ...” Daphne prompted.

“Ops.” Eric shrugged, sighing.

“What’s that?” Marcus said.

“Well, that’s operations,” Frank, ever the diplomat, explained. “The operations part of our company has been outsourced to another company. That’s increased the time it takes to get a deployment into production.”

“And the first thing they did was to revoke all our access to the production servers,” Daphne muttered.

“I take it that you have to wait a while before stuff is shipped, then?” Joakim asked.

“Yeah, they do deployments six times a year. And they’re not going to change their minds.” Eric was disappointed.

“Write ‘Waiting for Ops’ or something,” Adam said.

“Yes, let’s go with that,” Frank said.

“But it could be called Done or Out of Our Hands, if you like,” Frank said.

“Why?” Marcus asked.

“It’s only Ops work that’s left, and our hands are tied,” Daphne said.

Frank continued, “Yes, we don’t do much after that.”

Joakim and Marcus exchanged a “Should I do it or should you?” look. It was Joakim’s turn, apparently, and he asked, “Who is your customer?”

“What do you mean, ‘customer’?” Frank asked.

“Well, who is interested in your work or the features you create?” Joakim explained.

“Well, the stakeholders who wrote the requirements for the system—,” Frank began.

“Really?” Joakim said sneakily.

“Hmmm ... define ‘customer’ again for me,” Beth said thoughtfully.

When the team gave it some more thought, they soon agreed that the users of the internet bank were the important customers to keep in mind.

“‘Done’ for them would be when they can use the product,” Cesar said.

“What about the Waiting for Ops column, then?” Joakim pressed. “Will that make your end users happier?”

“No, of course not,” Beth said. “But that’s apparently how things are done, so what can we do about it?”

“If we were to ask you to post all the items that were Waiting for Ops, how many would that be?” Joakim asked the whole group.

“A truckload of them,” Eric answered before anyone else had time to say anything.

“Yeah—it’s many. The last release was—” Frank stopped and thought for a while. “I think there’s one coming up this Wednesday. I’d guess maybe 25 to 40 items.”

Marcus faced Cesar and asked, “What good are the projects doing your customers there, in Waiting for Ops?” He pointed toward the column.

“None whatsoever—we want it out,” Cesar said. “But as Beth said, it’s pretty much out of our hands.”

“Can you change that?” Joakim asked.

“Not easily.” Cesar sighed. “They’re on a different budget, in a different department, and even in a different building, for crying out loud.”

Daphne went up to the board and said, “But if we had a Waiting for Ops column with stickies, and the only thing that prevented those items from getting done were the Ops guys. Don’t you think we can start a discussion, at least?”

“Yeah, it’s much better than saying ‘You suck,’” Frank said, looking at Eric, who in turn looked down at the table.

“We might even be able to help them with some of the simple things ourselves.” Daphne saw her chance to get back the admin rights to the servers.

“Yes, it’s at least worth a shot,” Cesar admitted.

“Great work, team,” Marcus said. “When you visualize your pain and gather data about it, it’s much easier to get the stakeholders’ and other teams’ understanding. It’s not you nagging, it’s data.” Eric nodded in agreement and looked relieved.

“Here’s another excellent example of why visualization is so important,” Marcus cut in. “These issues exist right now; you just didn’t see them. By making this simple visualization, a sticky for each work item and which stage of the workflow it’s in, you were able to see a problem in your process.”

“Right—even though I’d rather call it an ‘unrealized improvement opportunity,’” Joakim said, smiling at Marcus. “And this is a big thing. Your kanban board will tell you all sorts of things. Items moving slowly, items being blocked, or items not being worked on are only a few examples. They’re improvement opportunities from which you can learn how to improve your way of working. Seize these opportunities. Call Ops and do something about this, for example. Maybe they don’t even know that this is a problem for you!” Joakim realized he was getting carried away and tried to calm down.

“I sure will,” Cesar muttered, but he was also quite happy with the progress they had made so far.

“OK, what happens after that—after Waiting for Ops?”

“Well, then it’s over,” Adam said. “It’s in production. Bugs might turn up, but then they’re entered as JIRA tickets, hopefully, and that would go in the Todo column, I guess?”

“If you say so, it’s your process,” Joakim said. “That leaves us with a final column called Done, or something?”

“Why have a Done column at all?” Daphne asked.

“Why not?” Eric replied. “We want to show that we’re amazing, right?”

Marcus agreed. “Yes, by all means do.” He paused briefly. “And it’s also a great way to collect all the work on the board as it’s finished.”

“Right.” Adam got that. “But why Done? I said that bugs might occur. How about In Production? That says more what it is, I think.”

The rest of the team agreed, and there were no tickets to put there at the moment.

“Looking at this—would you say that it is roughly the workflow your work goes through?” Joakim asked. “Can you see the status of each item more clearly now than when it was locked in the electronic system?” He nodded to the flipchart with their list of challenges.

“How about prioritization? That was also one of your challenges,” Joakim said, and pointed to the item on the flipchart. “Is prioritization easier for you to see now, when the items are listed in priority order in each column, for example?”

The team looked at the board for a moment. Frank mentioned that it felt a bit simplified and that they couldn’t know if it worked until they had tried it.

“That’s alright for now,” Marcus said. “Two things: first, this isn’t final. This is ‘best so far.’ This board, and everything else we’ve discussed, will probably be subject to change later on. We should improve it as we go.” He paused for a second, trying to avoid going into preaching mode about the virtues of inspect and adapt and continuous improvement.

“Second, let’s talk about the different types of work you mentioned. Or in other words—what goes on the board?”

1.4. Work items

“We now have a lot of stickies on the board, each of them symbolizing a work item,” Marcus said. “They each have a short title describing what work item they refer to.”

“And the status of each item is clearly shown by which column it’s in,” Joakim added, sweeping his hand across the board from right to left.

“Is this enough information for all of you, and for your stakeholders, to understand what you’re working on at the moment?” Marcus asked.

“Well, those titles might be too brief at times,” Beth said.

“How do you mean?” Marcus asked.

“I’d say that some of them could only be understood by the developers who are working on them, if even by them.”

“Maybe you want to write a short description of the work the sticky represents? Not something long-winded, but at the same time not so short that you don’t remember what that note was about,” Marcus suggested.

“Like a user story, then?” Beth smiled.

“Yeah—you could do that,” Joakim answered, “but you don’t have to. Any short description that reminds you of what you’re doing will do. It’s good if it’s apparent what the item is about without having to get up close to the board and read for a while. It should be apparent at a glance so you can tell different items apart.” Joakim drew a big square on the board and wrote Description in the middle of it.

“Is that enough then?” Marcus asked.

“Not always. I often want to know the JIRA number.” Eric loved that tool; you could hear it in his voice.

“Why?” Joakim asked, in part because he was not as impressed with JIRA, in part because he thought Eric probably had a point.

“If we’re going to have such a short description, we’ll need a reference back to JIRA so we can see the rest of the information there. Sometimes there’s loads of useful stuff in there. Long discussions, pictures, or what have you,” Eric explained.

“Great!” Joakim wrote JIRA # in the top-left corner of the square he had drawn on the board.

“Anything else?” he asked.

“Deadlines!” Frank stood up and almost screamed.

“Sure ... that seems important to you?” Marcus questioned. He looked at the group: no answer. After a while, Cesar broke the silence. “Yes, they’re important to us, but they aren’t present on every work item we do. How do we handle that?” He aimed the question at Joakim.

“What do you all think?” Joakim asked the group.

“Let’s write them on the notes that have a deadline; it’s as simple as that, right?” Eric said from his seated position.

“Yeah, but we want it to stand out, so that we don’t miss it.” Frank was talking to himself a bit.

“How about using a different color, then?” Beth suggested.

“Great idea!” Joakim went up to the board and added a deadline in the top-right corner. “Another thing that might be useful is to always write them in the same area of the sticky. That makes a connection that the top-right corner has a deadline, if present.”

“Great work, team,” Marcus added.

“But there’s one other thing that can prove useful to add to the work item,” Joakim said. “Any guesses?”

No answers.

“How do you know who’s working on what?” he asked.

That fact was noted on each item in JIRA, but they quickly realized that they needed to move that information over to the board as well. The first suggestion was to write the name, but that would use up space on the sticky; and sometimes more and more names were added, which would make the sticky hard to read.

“A simple thing would be to have some sort of marker to attach to the work item. A magnet with your name or something,” Beth said.

“Right: a simple and common solution is to create what are known as avatars of yourselves that you put on the work items you work with,” Marcus stated.

“An avatar? A blue guy riding a flying horse? How’s that going to help?” Daphne looked quite surprised.

“No, not that kind of avatar.” Marcus laughed. “A little picture, or placeholder, that represents you. Like a printed picture of yourself, or a cartoon that looks like you, or whatever rocks your boat.”

“Cartoons? But we look nothing like that!” Frank objected.

“Use something that at least resembles yourself, or make sure to add your name to it, so it’s easy to make the connection between the picture and you,” Joakim said. He was still burned by the time he chose to use stickers with dogs that were impossible to connect to the right people. He started drawing a sketch of an avatar on the board. His drawing skills caused some giggling.

“You know what would be helpful?” Adam said when the sketch was done. “To know if something is a bug or not.”

“How come?” Joakim asked.

Adam explained that bugs were prioritized over other work and probably could skip steps like Analyze in the workflow. They also wanted to track which JIRA ticket the bug originated from. After some discussion, the team decided to indicate that something was a bug by using a different color, writing it on a red sticky instead of a normal yellow one (a pattern common in the kanban community).

“That’s really good!” Beth, who always thought of herself as a designer in disguise, was intrigued. “Then those bug items will be easy to pick out even from a distance.”

Joakim produced a red sticky and wrote the word Bug on it. On a yellow sticky, he wrote Normal. He posted them on the side of the board.

“Please come up to the board and change the colors of the items already sitting there,” he said, handing out red stickies.

The group discussed some items, but for the most part they were quick to decide the type of work for a particular work item. After a short while, they took a step back and looked at the board.

“Now we can see a little more about what we’re working on,” Marcus said. “Furthermore, if the board starts to be only red stickies, we need to sit down and have a serious quality talk, right? The board is beginning to speak to us, sending us information about the status of our work. Can you see what we meant by information radiator before?”

There was nodding all around. It was easy to see the power of visualization and how simple measures, like changing the color of a sticky, could be useful to help important features to stand out, such as the type of work represented by the note.

“Great!” Marcus clapped his hands together. “We now have a board with a workflow and a simple template for what should go on each work item. Let’s see how work items should move across the board and what we can learn from that.”

“Remember where we started on this visualization journey,” Joakim interrupted. “We want the board and everything on it to radiate information to us. That information will tell us how our work works so that we can learn from it. The real gain isn’t seeing the status of each work item, great as that is. The real gain is to help us make decisions and to improve our process as we learn from how it works. This is only the beginning, and you’re never done.”

“This is a basic and important principle in kanban: to make work visible,” Marcus cut in.

“Right, and the basic reasoning behind that is that you can’t improve what you don’t see. Do you agree?” Joakim said.

Remember

You can’t improve what you don’t see.

People nodded their heads, seemingly in agreement. “Totally,” Cesar said, “and already we’ve seen the value of this. But what do we do next?”

1.5. Pass the Pennies

“Let’s check in with your challenges again,” Marcus suggested. “Let’s see if we can do anything to overcome your feeling of being swamped with work, shall we?”

“That will take us to another important kanban principle, which teaches us to limit the work in process,” Joakim started. “That is, to strive to work with fewer items at the same time.”

He almost didn’t have time to end the sentence before Adam, ever the skeptic, said, “Why? Shouldn’t we do as much as possible? Right now we’re showing the work we’re doing; we can’t do much about that. We’re going as fast as we can.”

“I don’t doubt you for a second. But I think you can do better,” Joakim said, a mysterious smile on his face. He looked at Marcus, winked, and said, “I think we need some pennies over here.” He pulled out a table and four chairs.

“Right.” Marcus produced a small coin purse. He emptied it, creating a little pile of 20 coins at one end of on the table.

He turned to Cesar. “How are we doing with time?”

“We’re 45 minutes in. An hour and 15 minutes to go. Please go on,” Cesar said mechanically, wondering to himself how these pennies would move things forward.

“Four of you please take seats around this table.” Joakim invited the group to the chairs. “The rest of you each stand behind one of your colleagues and bring up a timer on your phone. Marcus and I will fill the last two spaces behind you.”

He explained that the aim of the game is for each station to flip all coins once and then pass them on. When all workers have flipped all coins, they’re done and delivered to the customer. Everyone seemed to be with him so far.

“The people standing behind a ‘worker,’” Joakim made air-quotes to emphasize the irony, “are responsible for timing the worker in front of them to see how much time is spent on the task. Start the timer when your worker starts working, and stop it when the worker stops. Got it? You’re timing the entire time your worker is active.”

“Finally, we want to measure the total lead time, the time it takes from start to finish for the work to flow through our workflow,” Joakim said. “I’ll act as the customer and will be timing the whole chain. I’ll track two things: the time it takes until the first coin arrives to me, the customer, and the total time—that is, when all of the 20 coins have arrived to me.”

After a moment of razor-sharp thinking, Daphne spoke. “But working like this, it means that the first coin and the last coin will arrive at the same time?”

“Yes, that is correct,” Marcus responded. “In this first iteration at least. We’ll see changes to that soon, in the iterations to follow.”

Marcus concluded the introduction to the exercise. “We’re going to run this three times. The first time every worker will flip all 20 coins and then send them to the next worker in line. Are you with me?”

“Are you ready? Timers, time your worker’s effective working time,” Joakim instructed a final time. “Ready, set, go!”

There was intense silence as Adam started to flip his coins like a madman. He passed his coins over to Beth and turned to his “manager” Frank behind his back. “Done—stop the watch!”

Beth continued with equal concentration and sent the coins down to Cesar. Cesar didn’t even breathe during his turn and drew one big breath as the coins were sent to Daphne in the last station. Daphne tried to flip two coins at once, one with each hand, resulting in even slower progress. The others moaned. “Come on Daphne—don’t let us down here!”

Finally she was done and sent the coins to Joakim, who stopped his watch. On a flipchart, Marcus created a small table and wrote down the results.

Joakim went around to each of the “managers” and asked them for the individual times for each worker. After adding up the total, he turned to the group. “As Daphne predicted, the first and last coin came in at the same time.”

“Now let’s try with five-coin batches,” Marcus instructed. “That means—flip five coins and then pass them down to the next worker before you move on to flipping the next batch of five, and so on. Got it, workers?”

The workers nodded and started to focus on the coins again.

“And managers, make sure to time the whole time your respective worker is flipping coins. Starting when the first coin comes in and is being flipped and ending when the last coin has been passed over to the next worker.”

“Hmmm—I think I know where this is going,” Frank said to himself.

“Time waits for no one,” Joakim interrupted. “Ready, set, go!”

This time there were more sounds from the coins but still a sharp focus and silence from everyone in the group. When Adam had flipped his last coin, he cheered for the others. “Come on! Put your back into it, Cesar!”

It wasn’t long before the five-coin iteration was over and the results added.

“What? That doesn’t look right,” Cesar called out as he looked at the numbers. “You sure you timed that correctly?” he asked, looking first at Marcus and then at Joakim.

“I assure you it’s correct. Let’s discuss this further after the next iteration,” Marcus responded. “This time we’ll do a single coin at the time. Flip it and pass it down. Got it, workers?”

“As before, managers, time the whole time your worker works. Ready, set, go!”

Total silence, except for the continuous sound of coins sliding around the table. After what felt like a short time, they were done. Joakim collected the times for each worker and added them to the flipchart.

“I can’t believe that!” Frank sounded skeptical and almost as though he felt cheated. “How on Earth can that be right?” The others also looked quite surprised.

“It’s correct, all right. Let’s discuss what we can learn from this,” Joakim said.

“First, take a look at the time for the first coin to arrive to the customer. What happens with that as we switch to smaller batches?” Marcus asked rhetorically and pointed to the summarized rows.

“It goes down, way down! Fifty versus four; that’s amazing!” Frank shook his head in disbelief.

“And what about the total time?”

“Well, that went down too, of course,” Daphne said, not as impressed.

“But not as dramatically as the time for the first delivery,” Frank still could not believe that number. He looked at it over and over.

“And now—take a look at the times for the individual workers,” Joakim said, giving them a few seconds to reflect.

“What’s the common trend? Not pointing fingers to anyone in particular.” He coughed and winked at Daphne. She got the joke and waved him off.

“Well, as strange as it sounds, those times go up at the same time as the others go down. How can that be?” Cesar looked to Marcus and Joakim for answers.

“What we’ve shown you with this simple exercise is that when you decrease the number of concurrent or simultaneous ongoing work items, the lead time decreases,” Marcus explained. “Notice that we’re doing the same amount of work, but working in a different way—with smaller batches, with less work in process at the same time.”

“Or WIP, as you’ll hear it referred to in the kanban community,” Joakim added.

Remember

Work in process (WIP) is the number of work items you have going at the same time. Less work in process leads to quicker flow through your process: shorter lead time.

“It wouldn’t be much of a community if it didn’t have its own strange three-letter acronyms, now would it?” Marcus said, with a big grin on his face.

“As you’ve seen, this has a dramatic effect on the total time, which in this case went from 50 to 20 seconds.” Joakim pointed to the board. “But another thing also happened. When we worked with big batches of 20 coins, we delivered the first and last coins at the same time; but with smaller items, we got the first one in after 4 seconds. Less than a tenth of the time for the first delivery when doing 20-coin batches.”

“Smaller batches,” Marcus made a shrinking movement with his arms, “with less work in process, will both give you better total speed and let you become more agile, because you can deliver the small, important stuff first. Do see why this could be an advantage?”

“Not only that,” Marcus continued “but what if there was something wrong with the way you flipped the coins? What if the customer expected them to be flipped to stand on the edge—what would have been different with different batch sizes?”

“Because we didn’t deliver until all of us were done with our individual contributions, we would have to do it all over again,” Daphne said. “In the first iteration, that is.”

“Finally, we stopped focusing on using each worker as efficiently as possible,” Joakim said, directing his comment to Cesar. “In the first iteration there was a lot of waiting until the last worker did any work, but each worker was efficient and worked through the entire batch before handing it down. On the other hand, in the last iteration, when the lead time was the shortest, every worker worked for a longer time, making them less efficient as individuals but more effective as a team.”

Remember

Optimizing your process for quicker flow can lead to poorer resource utilization.

“I hate to rain on your parade, but ...” Adam leaned back and crossed his arms over his chest. He let out a big breath. “Our work, the ‘reality,’ is a bit more complicated than this. I hope you realize that?” Adam sounded tired.

“How do you mean? Please explain.” Marcus tried to open a discussion.

“For starters, items don’t arrive in a continuous flow like that. They go back and forth between us. I do a little testing, then there’s some more coding, more testing again, and maybe even changing requirements.

“Second—the items we handle vary a lot in size. The coins and the work are exactly the same all the time.”

“Good points,” Joakim interrupted, as he saw Cesar checking his watch. “And you’re right. This is a simplification, a simulation that aims to show a single principle: that less work in process leads to lower lead times. In reality, there are a lot of other forces at play, and you have to make trade-offs, but the basic principle still holds.”

“There are also a lot of other advantages with shortening lead times and limiting the amount of work in process—but we don’t have time for that now.” Marcus tried to wrap up the discussion. “This exercise is used as a bit of an eye-opener, and for now the important thing is that you understand the principle. Let’s get practical again and gather around the board; how can you apply this to your work and to your board?”

1.6. Work in process

They went back to the whiteboard.

“Where are our pennies?” Adam said dramatically, underlining the fact that he still didn’t trust the result fully—not yet, at least.

“What are the pennies on this board?” Joakim asked the group, ignoring Adam’s comment.

“They’re the stickies,” Beth said.

“What about them? What did you learn in the game?” Marcus asked.

“OK, let’s see if I understand this,” Frank began. “If we want the work to flow fast across the board, we should do fewer items at the same time. Going from 20 coins to 5, so to speak.” He looked at Joakim and Marcus.

“Do you agree?” Joakim looked at the group. They seemed to agree.

“But how do we do this in practice?” Eric wanted to know. “What do we change?”

“Well, if we all agree that this is a good idea,” Daphne replied, glancing briefly in Adam’s direction, “that should be enough, right? We agree to work on fewer things at the same time.”

“Yes, you could all agree to stop starting and start finishing.” Joakim mused on this kanban call to arms that he was so fond of, but the blank stares from the audience told him he had to elaborate. “Rather than starting on a new work item, you could help someone on the team finish one already in progress.”

“And rather than allowing yourself to be blocked,” Marcus added, “for example, by waiting for information or a review from someone, you should try to resolve the situation or work on how to avoid it in the future. These are the unrealized improvement opportunities we talked about earlier, remember?”

“This sounds great in theory,” Eric agreed, “but in practice it’s not that easy to help someone finish something. I mean, I don’t want to bother Daphne by having her explain what she’s been doing and how I can help. Isn’t it better if she finishes that herself?”

“That’s certainly what it’s going to feel like at times, especially in the beginning, but you have to start somewhere and use your own judgment,” Joakim explained. “In our experience, the path of least resistance is often to start new work, so we have to make a conscious effort to design the work so that it’s easier to help each other finish it.”

“Which leads us to the next step in limiting work in process,” Marcus interrupted, concerned that Joakim was about to go off on a tangent, “which is to use visualization to make the limits explicit and specific. We choose a maximum number of work items that we’re allowed to have in progress at the same time.”

“This limitation will help us focus on getting stuff finished and help the work to flow faster through the system.” Joakim was back on track again. “Limiting your work in process will help you with a couple of the challenges listed at the outset. First, things will start to move along so you’ll stop have people breathing down your neck.”

Joakim went up to the flip chart and pointed to the first item. “When stuff starts to come out of your system on a regular basis, the demand for accurate estimates and predictions will diminish, in our experience. Second, you won’t feel swamped with work because you now have a limit on how many things you’ll work on at the same time. If someone wants to add a new work item, they’ll have to also decide what gets taken out.”

Joakim added dots to the flipchart as he talked.

“Which, in turn,” Marcus cut in, a happy grin on his face, “will make it easier to prioritize. Fewer items to start with, but you now have something to show and reason about. The work you’re doing is right there, on the board.”

“But how do we know what that number should be?” Beth said.

“It depends.” Marcus opened with every consultant’s standard answer, realized it, and quickly tried to move on to something a bit more useful. “In general, a lower limit is better, but too low of a limit could have bad consequences. Imagine that you all work on one single item. That would be great for the flow; the second it’s ready for development, the developers could pick it up and start working on it. And Adam is getting ready to start testing it when development is done. Any problems with that scenario?”

After a moment Frank broke the silence. “Seems like there’s a lot of waiting in that case, or am I missing something?”

“No—that’s exactly right.” Marcus gave Frank a thumbs-up. “Low WIP leads to a lot of slack. Which is good for lead times, but most companies are probably not willing to pay for people sitting idle.”

“You need to balance those two against each other: fast flow versus people having work to work on. You want a low work-in-process limit, but probably not a limit of ‘one,’” Joakim concluded.

“But that still doesn’t help us figure out what that limit should be for us,” Daphne said.

“No, and I’m afraid we can’t tell you.” Joakim shrugged. “That is something that you must come up with and constantly tune to increasingly get better and faster flow through your workflow.”

“Change the limit of the number of concurrent items. OK—we got that. But from what to what?” Frank was losing patience. “You’ve got to give us something!”

“Start simple,” Joakim said. “Start with one item each on the board. Pretty soon you’ll see some problems piling up somewhere, where developers have a hard time keeping up, for example.”

“What ever do you mean by that?” Daphne said half-jokingly, but there was some sting in there too. She was fast, and she knew it.

“Some tasks take a longer time to finish than others,” Joakim said. “It’s not that important where the flow slows down or stops. The important thing is what you do about it.”

“Take this example.” Marcus cleared the notes from the board. “Let’s say we think that two items are a reasonable amount to be developing at the same time, because there are two devs, right?” he checked with Daphne.

“Sure,” she answered a bit defensively, cautious where this would lead.

Marcus wrote the number 2 above the Development column.

“We have two items in there in progress. Now the analysts are ready with their work and want to push it into development. That will break our limit of two items, right?” Marcus drew an arrow and a question mark on the board.

“What do we do now?” Joakim asked.

Frank quickly volunteered his opinion: “Put them in there. They’ll get there sooner or later anyway.”

“Who else thinks that ‘putting them in there’ is a good idea?” Marcus asked.

“I sure don’t!” Daphne retorted. “Wasn’t that the whole idea with all this passing of pennies? Keep the number of items going on to a minimum?”

“Right—but what could we do instead, then?”

“Remove other stuff if what’s coming in is more important,” Eric suggested.

“Do nothing? Wait? Work slower?” Beth pictured the scene, and it didn’t sit right with her.

“See? A discussion is ready to take place,” Joakim said. “And that’s all the work-in-process limit is: a trigger for discussions. Preferably discussions on how to improve your process so that you can keep the WIP down and have the work items flow faster. It could be a discussion on what specific action to take to avoid bringing more work into the process. Sometimes it will mean a developer helping another developer to finish something, sometimes it will mean replacing something already on the board, sometimes it will mean that developers stop developing to help out with testing—”

“Hold your horses! That will never happen!” Daphne cried; her voice and face told the others she was joking.

“As if I’d ever let you!” Adam was quick to join the joke.

Remember

The WIP limit isn’t a strict rule; it’s a trigger for discussions.

“We often end up doing a lot of testing before a release anyway,” Eric chimed in, “so I guess it would make sense to do it all along to avoid the ketchup effect. You know? Nothing, nothing, nothing, and then, all of a sudden, BLAM! Everything comes at once.”

“There might even be valid reasons to break the limit from time to time.” Marcus tried to get the discussion back on track again. “But if you do it often, you might have to review the limit and see if a higher limit would help the work to flow better. If, on the other hand, you rarely or never reach the limit, you’ll never have these useful discussions, and you won’t have the tension to improve. Then it’s time to lower the limit.”

“Now you shouldn’t have a problem finding numbers for your limits, right?” Joakim had looked at his watch and realized they had to move along.

“Well, one each is simple, but is it the correct number?” Frank started.

“Think of it as a limit, and not trying to find the correct one,” Marcus said, pressing on. “As we said earlier, you’ll inspect and adapt with time. If we decide to go with one item each, how can that be achieved in a simple way?”

“Write the number of people doing work in each column?” Adam suggested.

“Yes, great idea! What would that look like? Care to help us out?” Marcus handed a marker to Adam and stepped back.

“Well, I guess, because I’m the only one doing testing right now, we’ll end up with a 1 there.” Adam wrote a big number 1 above the Testing column.

“Hold on!” Beth stepped up to the board. “I do some testing too from time to time. It’s a good way to follow stuff up early, and the analysis work rarely takes up all my time because I often have to wait for meetings to take place. I think 2 is a better number.”

“Yeah, that’s true. Let’s go with 2.” Adam changed the number.

“OK—how about you devs? What’s suitable for you?” Adam threw the pen in the lap of Eric, who instantly passed it over to Daphne.

“Two items seems a bit low to me. Sometimes we need to wait for people, which would mean that we would end up with nothing to do. But four seems a lot as well. What do you think, Eric?”

“I say four items; we do loads more than that today. We’ll manage!” Eric said with confidence.

“Hmmm—I’ll write 3, and we’ll keep an eye out for problems,” Daphne said as she erased the number that was there already and wrote 3 instead.

“As for analysis work, I think a limit of two items seems reasonable,” Beth said, and promptly wrote the number 2 above her column. No one seemed to object to that.

“And the rest of them?” Frank said, turning around. He realized that Marcus and Joakim were nowhere near the board right now. “What should we do with them?”

“What do you mean?” Joakim seemed quite happy to stand in the back and let the team figure it out by themselves.

“Well, the Todo, Accept, and Waiting for Ops columns, and so on. Shouldn’t they have numbers on them as well?”

“They could,” Marcus answered. “But why? What would you gain by that?”

“Eeeh ... I thought that all columns should have a number,” Frank confessed.

“As we said: they can have them, but there’s no rule,” Joakim explained. “Put limits on the columns where you feel it helps you get a faster flow. How about that Accept column, for example? What would a limit of items do there?”

“Let’s see.” Cesar stepped forward and talked slowly to himself. “Limiting that column to, say, four items means if it’s filled with four items, then—” He paused and wrote the number 4 above the column.

“When the testing team wants to add yet another one, they will be blocked, and things will back up, so to speak. Because the flow is stopped by that limit.” Cesar stepped back. “What does that mean?” he mumbled to himself.

“How do you unblock it?” Marcus offered. The others were silent as Cesar continued to think for himself.

“Well, Beth or I check the items out and accept them ...”

“Right—so you could see that limit as a signal to you to come and do your acceptance work.” Joakim suggested what he thought Cesar was thinking, but translated into the terms they had been using to introduce kanban.

“OK—but why not have a limit of one, then?” Adam asked.

“Because—” Marcus didn’t get further before Cesar interrupted him.

“Because then I’ll have to run down there the second something is ready to accept, or the workflow will start backing up.” A light bulb was turned on for Cesar. “I see. Very interesting.”

“Why four?” Frank asked.

“We don’t know what a proper limit is. But four seems like a start that we could use and tweak as we see fit. A lower number demands our constant presence, something we often can’t handle because we’re traveling or are stuck in meetings. A higher number would mean the team would go too long without feedback from us, which might mean rework if something is wrong; and we want to fix that before they’re too deep into something else.”

“But why should there be a column for stuff that you’re waiting to do?” Daphne asked. “I mean, you’re waiting for that column to fill up and then start accepting items when it’s filled.”

“Good point, Daphne,” Joakim answered. “This isn’t uncommon at all. It’s what we call a queue or a buffer of work. It’s usually put in front of a function that is limited in some way, like the Accept column here. Beth and Cesar can’t be with us at all times, so when they get here we want to make sure there’s work for them to do. Hence we build a little buffer of work for them, and only call them in when it’s filled.”

“Not sure I’m following you here, Joakim,” Cesar said.

“Let’s visualize it, and see if it gets clearer,” Marcus said, and went up to the board.

Within the Accept column, Marcus drew a Ready column and a Doing column, dividing the column in two. He turned to the group and said, “Now it’s apparent what’s waiting and what’s in progress. When the Ready column starts to fill up, we call on Beth and Cesar.”

“Isn’t it like that in Testing and Waiting for Ops as well?” Daphne said.

“It could be. You could have queues where you think they fill a purpose: for example, where there’s a limited resource or if you want to visualize the difference between waiting and working. If there’s a handoff involved, for example from someone doing development to someone else doing testing, a queue would be a good way of signaling that the work is ready to be pulled to the next stage.” Joakim looked at his watch.

Frank nodded; it seemed he was slowly coming to terms with Cesar’s explanation. He looked at the board for a moment. “That’s it, then? This is the board, we have our limits, and we’re done with it?”

1.7. Expedite items

“Yeah ... that could be the board for you.” Joakim took a step back and crossed his arms over his chest. “What do you think, people? Is everything up there? Is this how you work?”

Marcus went through the challenges on the flip chart, and said: “Even though we might not have solved every point on this list yet, you should now have tools to tackle most of them, agreed?”

There was a moment of silence, and then Adam cleared his throat. “Again—this all looks great, but it’s still a simplification,” he said, and sighed.

“Everything is not new features and moving stuff forward, you know,” he continued. “Sometimes things go wrong in production, and then it doesn’t matter what you’re doing right now or how many things you already have in progress; you fix it! There and then!”

“That’s right,” Daphne cut in. “Surely we’re not holding off urgent work in order not to break the work-in-process limit, are we?”

“Well—you could, but most teams don’t, because that would be bad for business. At the end of the day, your bottom-line result trumps keeping your process perfect. How do you treat urgent work today?” Marcus turned to the group. “If you’re happily moving along on your new and cool features, and you suddenly receive an alert that the production server is down, what will you do?”

“I’ll drop everything and ‘run to the hills’!” Eric said, Iron-Maiden-singing the last part. There was giggling all around, because nobody had seen Eric move fast—ever.

“Seriously ... I’ll stop what I’m doing and start to look in to it,” Daphne said. “Ah, I get it. We should visualize it on the board. Start where we are, visualize it, and make it explicit, and so on, right?”

“Right!” Marcus gave her a cheesy pistol-shooting sign with his right hand.

Joakim rolled his eyes and quickly moved on. “This is a common scenario. A common solution is to create a special lane on the board for urgent stuff, often referred to as an expedite lane.”

Marcus, having holstered his imaginary pistol, added a new lane at the top of the board while Joakim explained.

“The policy you hinted at, Daphne, that you should drop your other work and help resolve the issue, is pretty standard; but it’s often implicit and not understood or agreed on by everyone. It can be unclear who should act and do something about it or if everyone is supposed to help out. Should the new item be counted against our WIP limit or not? And so on. There are a lot of implicit policies at play.”

“Uh-oh, I know where this is going.” Eric threw his arms up in the air. “What’s the point of sitting here discussing limits if we’re going to have this loophole?”

“What do you mean?” Frank asked, giving him an unappreciative stare.

“You guys,” Eric nodded his head to Frank, Beth, and Cesar in turn. “You guys could fill this lane with items all the time. It will be your fast lane into the development queue, and you’ll use it like crazy, so that your work will get done first! Which makes us hop from one item to another. Again. Like last spring with the big Bank 2.0 release, remember?”

There was a moment of awkward silence.

“OK, there seems to have been some not-so-good things going on with expedite work in the past. What could you do avoid that from happening again, then?” Joakim asked.

More pondering. Eric, putting some extra thought into the challenge, fueled by the guilt of having caused the awkward silence, proposed, “Put in a limit of sorts, I guess.”

A short discussion followed in which the team agreed on some simple policies for how to handle the Expedite lane. Joakim summed up the discussion: “Let me see if I’ve captured your policy correctly. An expedite item should only be used for urgent cases and is not to be used as a fast lane to cheat the system. You’ll settle on a limit for how many expedite items you allow per month, OK?”

“Well—I for one am happy with that setup. I’ll promise you all that we’ll handle the expedite items with respect and not cheat the system,” Cesar said and held his hand over his heart for the last part. The laughs that followed were a relief from the slight tension that had crept into the room.

“Let’s make sure you understand the implications of this policy. What would happen if you put an expedite item into the system?” Marcus asked.

“It gets done faster. That’s what we needed,” Cesar said, but realized that he might be walking into a trap. Two can play that game, he thought, and asked a question back. “Why are you asking?”

“Well, I meant what will happen with all the other work already in your process? Adam, if you think back to the pennies game we played, what would an expedite item look like there?”

Adam thought for a while and then started to reason out loud. “I guess that would be introducing a new coin that had to be passed around before the others.” He paused. “And that would not be great for the flow, because we would have to stop flipping the other coins ...” All of a sudden, he got it. “That would make all other coins move slower through the system.”

“Correct!” Marcus said. “Use the expedite lane with care. Sure, it will take that item through the system faster, but it will also increase the work in process, and that in turn will slow down all the work already in there.”

Joakim thought that sounded a bit ominous. “That is, make sure you know this and take it into account when playing the expedite item card. There are times when it’s the right thing to do to get one valuable or important item out there fast. But it has a cost; make sure you know you’re paying it. Like a toll, if you like.”

“And we’ll make sure the lane isn’t misused too.” Eric looked happy.

“This could also be a way to handle the work that is handed to you in the corridor,” Marcus said, and he made a little dot close to that point on the flip chart. “Sure, you could do it, but is it worth the toll you have to pay for it? A discussion can be had with some real data to back it up.”

1.8. Metrics

Cesar went to the board, looked at it, and turned around. He was in boss-giving-speech mode now; they could tell.

“I think I speak for everybody when I want to extend a big thank you for this, and—”

“Now wait a minute,” Beth cut in. Cesar looked a bit surprised, but then again, this was Beth. She was worth listening to; he knew that from experience.

“Yes?” he asked, encouraging her to go on.

“I know we only have 20 minutes left, but there’s one area that we’ve left untouched,” Beth said. “How do we improve on this?”

“What do you mean?” Frank was surprised. “This will give us better control over our work than we’ve ever had before. I think it’s a fine start!”

“It is! But as I’ve understood it, this should evolve, right?” She looked at Joakim for support.

“Yes, but ...” Joakim responded, “as we talked about when we drew the board, and designed the work items, and so on, everything on the board is subject to change in order to improve as we go—”

“Great!” Beth stopped him short. “How do we know that we’re going the right way?”

Joakim said, “How do you know that you’re improving when you make a change?”

“Well, if we’re doing better than before,” Adam said.

“But against what?” Frank responded. This was his territory. “What does ‘better’ mean? How do we know? We need some metrics to know if we’re improving.”

“Here we go,” Eric and Adam said together, and others joined in with sighs and despondent voices. Joakim and Marcus looked at each other, a bit surprised by the strong reaction.

The team had apparently been subjected to a company-wide effort to introduce key performance indicators (KPIs)^[2] that didn’t help them at all. Because the KPIs had to be fulfilled, the productivity of the team had been suffering, as well as morale. Before long, the KPIs were abandoned.

² Key performance indicators (KPIs) are a common way to measure performance.

“OK, what do you say about skipping that, then?” Joakim tried to steer the discussion back onto a positive track and waited to get their attention.

“We’re not talking about metrics like that. These are metrics by you, for you, to help you to find areas in which to improve.”

“Yeah, exactly,” Marcus said. “Track them on the board, and keep them to yourselves if you like. Or at least only show them to the people you choose.”

“But it’s drudge work to capture and track,” Daphne moaned. “I want to do real work!”

“It doesn’t have to be,” Joakim said. “With the board in place, you’ve set yourselves up to easily track at least two simple and powerful metrics: lead time and throughput.”

He went up to the board and took a couple of stickies with him. As he spoke, he drew a big brace under the entire board. “Lead time is the time it takes for a work item to go from start to finish—from the first column to the last.”

“Really?” Adam cut in. “The time our work takes varies greatly. What could we possibly learn from that?”

“Bear with me for a while,” Marcus begged. “Starting to track lead times can be as simple as writing down the date of the sticky as it enters the Todo column and then writing down the date when it enters In Production. Plot that out in a simple diagram, and you’ll have a pretty good idea of what your average lead time is.”

Marcus quickly drew an example sketch chart on the board.

“With a chart like this, you can easily see the differences in time for the different items,” Marcus explained. “As always, this is more something to talk about than the solution to your problems.”

“But what does that chart help us with?” Adam scratched his head.

“Let’s see,” Joakim began. “What do you see that stands out to you on that chart?”

They looked at the board, and pretty soon Frank said, “Well, those three.” He pointed to the three Xs that scored the highest on lead time. “They seemed to take much longer. Why is that?”

“Why indeed?” Joakim asked. “That might be worth investigating.”

“Maybe all of them had to do with a certain subsystem of the application,” Marcus offered.

“Or were badly specified,” Adam said, looking at Beth.

“Or even lacked testers’ input when we did the specification,” Beth answered without missing a beat. They both chuckled about it.

“See?” Joakim said. “Another discussion got started. But you could have a discussion even around the general stuff. For example, what would it take to reduce the average lead time by half?”

“Half?” Frank sounded like he thought it was impossible. “It can’t be done now. We’re waiting so much on Ops and others that—”

“Exactly,” Joakim interrupted him, “but what would it take to change that?” He left the question hanging.

Joakim checked his watch and hurried along.

“Throughput, the rate at which you complete work, is even easier to track. Count the number of items you finish for a given period of time: for example, every two weeks. Or four, if that suits you better.”

“We release the second Wednesday every month,” Frank said, “so that would be a great point in time, if you ask me.”

Marcus drew an example on the board. “Count the items in the In Production column every second Wednesday, and then remove them from the column. This will give you a simple way to track throughput.”

Adam was hesitant. “Again—how will that help us improve?”

“Remember before when we talked about lowering work in process to get quicker flow through the workflow?” Joakim asked. “How can you know if you don’t track data? Sure, you can go on gut feeling or intuition, but how will you know? And will your feeling be enough to convince others if need be?”

“If you’ve tracked this metric for a while and average out the result, you could even start doing predictions and make promises you can keep around due dates. Wasn’t that one of your challenges?” Joakim continued.

“With these simple metrics,” Marcus added, “you can start where you are and track your current process. As you change, you can easily see if you’ve improved or not.”

“But isn’t that a bit simplistic?” Adam was still skeptical. “We have some sophisticated systems in place today to track and measure—”

Eric interrupted. “And we didn’t like them and didn’t use them, remember? I’d much rather use some simple metrics for us that work and that we use than those stupid ones we worked with because someone in management thought it was a good idea. I distrust most forms of metrics, but these I at least feel I can live with.”

1.9. The sendoff

There was silence again. Not as awkward this time, but silence nonetheless. Suddenly, Daphne turned to Cesar. “Time?”

“There’s plenty of time—no, wait, we’ve gone the full two hours right about now,” Cesar said, looking at his watch.

“There’s much more we could talk about,” Joakim said, “but this is a great start that will get you rolling, we think.”

“As you progress and want to know more, you can check out the principles behind Lean and try to apply them in your context,” Marcus continued. “That can be tricky, so take hints from other teams and how they have applied Lean in their contexts. You can also check out the kanbandev^[3] mailing list, the Limited WIP society,^[4] and conferences on the topic.”

³ http://groups.yahoo.com/neo/groups/kanbandev.

⁴ http://limitedwipsociety.ning.com/.

“With what you have now, you could start tomorrow and continue to improve from there.” Joakim tried to close the discussion.

“I won’t give a speech,” Cesar said and stood up. Immediate cheers from the others followed, and when they settled down, he said, “But I want to say: thank you guys. This was a vitamin injection that we needed. And you were right; we could get up and running in under two hours.” He smiled.

“When you get home you might want to know more details, some background, and sooner or later a few advanced techniques.” Marcus reached over to his bag. “Then this book could help you.”

He handed Cesar a draft of their upcoming book, Kanban in Action.

“One last question: What should we focus on now?” Frank asked.

“Lead times,” Marcus and Joakim said in concert; Joakim continued. “Take the whole process into consideration, and try to shorten the lead times.”

“And here’s a hint: try coming up with ways to lower your work in process to get there,” Marcus finished.

“Thank you.” Cesar looked them both in the eyes and turned away hastily.

At the door, he stopped and turned around.

“Oh that’s right—we never talked about your fee,” he said, pointing to the table behind Marcus and Joakim.

They both turned around, and at first they didn’t see a thing. They approached the table and found a sticky with some sort of number scribbled on it.

“What’s this?” Marcus looked back to where Cesar stood a second ago, only to see the door closing behind him.

“Looks like an account number in a bank,” Joakim answered. “But what use could we possibly ...”

They both got it at the same time.

“We got paid. I think we better get a login to that internet bank, right?” Joakim looked at Marcus, smiling.

1.10. Summary

We leave our heroes there, and the Kanbaneros team is on the way back home, ready to get started with kanban. This whole chapter was a fictional story, and it incorporated some simplifications and adjustments to get the story to flow better, but it has also shown you how you can get up and running easily.

Maybe your work, team, and context aren’t exactly the same as for the Kanbaneros, but you can follow along with the reasoning and adjust it for yourself. You don’t need to do everything they did; pick and choose what suits your needs best.

This chapter aimed to get you started with kanban. In the next section of the book, we’ll examine all the elements described and more in greater detail, offer variants, and warn you about common pitfalls. We’ll also offer some more background on where the concepts originated and how they have been applied in other contexts.

You’re more than welcome to try kanban out with what you know now, or you can also continue your journey in the next part of the book. In the next chapter, we’ll take a short look at the origins of kanban and dive into the principles on which it’s built. We’ll also give you a cheat sheet for getting up and running in no time.