Managing Change Requests Using Lean Methods and a Kanban Board
Jake wants to put the "Kanban board" up in the room where Tristin, Raj, Sharon, and Jamie work. Because the Software Maintenance group are currently located in one room (with others in the development group), this is possible. Jake put a board in that room to display status using one board to display current status of features. The board was put together like that seen in Figure 2.
Figure 2: Mock up of what the Kanban looks like
To start the Kanban, Jake set up an initial two-hour meeting with the group, planning to initiate 15 minute daily stand-ups after this first meeting. The meeting started with Jake explaining his vision. "I've set up the board with different cards representing each feature. All the features are numbered to keep track of them throughout this Kanban board. On this board, I have displayed the features that I know have to be completed." Jake explained.
"Jake, I'm working on three features. Currently, the feature called number 12 is in a holding pattern waiting on feedback from customers. When that happened, Joel" (the previous manager) "assigned two other features to me. He wanted to make sure I had enough to be working on. " Tristin said. "Jake, I also have some features currently assigned. Numbers 2, 4, 5, and 13 are in my queue," Raj explained. "I have started work on two of these features."
As Jake took all this in, it was Sharon's turn. "I'm working on analysis for three features. I'm scheduled to start analyzing a new one this week, but I won't get to it. I still haven't finished any of the three currently assigned to me."
After Sharon explained that, Jamie chimed in. "Jake, I am waiting too for some testing. I've started to write tests for feature 12, and also for number 13."
In the meeting Jake, explained how he viewed the SM group as a system. "I believe this system can perform better than it is currently configured." Jake explained. "By using this Kanban process, we should be able to increase productivity and add value to the company. This board should make our processes more visible, helping the team manage the work queue. Instead of a manager assigning new items to people in the group, the tasks are pulled by team members. The theory and experience from others say that this should increase throughput of completed features. We will measure these items to prove or disprove my theory."
The numbers indicated to Jake that the work allocated to the group was over the group's ability to deliver. Having each member of the team work on more than one item at a time was actually overflowing the system. "To start with, all current features, even those that I would consider WIP, should be put up on the Kanban in the backlog queue," Jake said. "Then, each one of you can pull one item to work on, until your part of the process is completed. Move the token you are working on to the next part of the process."
Jake continued "For instance, assume Sharon finishes one analysis feature. She then puts the feature token above the Development column, and goes back to the backlog on the Kanban board, and pulls a new feature token from there. Now, when a developer is free to move on to a new feature, they can pull that feature token or another from the developer queue."
"Normally, we would limit the number of items on the Kanban board backlog. Because this is the start of our Kanban, we won't follow that rule so closely. But, new items will follow our new Kanban backlog limit rules".
"But how will limiting our work to one item at a time increase our productivity?" Tristin asked. Jake replied, "That is a great question, Tristin. I believe that the multitasking of requests that we currently have is not an efficient way to work. A blog post I read from Johanna Rothman mentions the evil of multitasking and how it is the root cause in reducing an organization's throughput. We want to focus on the right things. I believe that focusing on work until it's completed should increase quality and eliminate the waste encountered when switching between tasks."
Because the current backlog was large, the group wanted to focus on decreasing the total work. To get started, they requested some help from management to temporarily increase the number of developers and analysts to get the work done. This request was agreed upon for the first month.
Also, the team agreed that Jake would work with customers to triage all requests in the current queue. He would close any requests older than six months and ask customers to resubmit them. Jake wanted to meet with customers to begin discussing the Service Level Agreement they expected.
Setting the Kanban up for Continuous Improvement
Figure 2 shows a facsimile of the Kanban board set up in the Software Maintenance group's "office." To make this effort continuous, the group has decided to set up daily standup meetings by the Kanban board. They have agreed that at the meeting, only the people pulling work from the Kanban can bring up issues. This meeting should not take more than 15 minutes, and only the people with issues should talk. That aspect was a little different than Scrum standups, but the idea was that the team wanted to make sure the process could scale to large groups.
Jake then decided to set up a weekly status meeting with all the customers with a stake in the different features. At this status meeting, Jake, along with the rest of the SM group, demo any software and have the stakeholders prioritize the new features. The invitation states that stakeholders can reprioritize any features that are not in Work In Process (WIP).
Jake wants to revisit reprioritization once he has some time with the Kanban under his belt. The rest of the team agrees with Jake that changing the reprioritization process will be a continuous improvement effort. After reading about the Theory of Constraint, Jake feels the Kanban can be refined to help manage their constraint(s) effectively.
Page 2 of 3