As mentioned in my earlier article, "Managing Change Requests Using Lean Methods and a Kanban", managing change requests can be a burden. In that article, Jake had just become the manager of the Eric Landes Fictional Corporation (ELFC) Software Maintenance (SM) group. After seeing improvement in utilizing this method, Jake wanted to do more. In keeping with lean teachings, Jake and his team want to continue to improve the process.
Jake prepared for the monthly retrospective he had set up. His idea behind the monthly retrospective was to have the team take a step back, and look at how the Kanban is performing at a higher level. In other words, take a look at what worked and, more importantly, what needs to be improved. When Jake mentioned this to Sharon, he asked for her feedback.
"I just hope it doesn't become boring." Sharon said. "If we always do these meetings, they can just become something you always do, not very meaningful." "I agree, Sharon, so let's make sure they are meaningful. First, let's set these up for the first three months. After three months, we'll change it up a little. Also, to keep it fun, we'll let you lead the meeting. Come up with some ideas for how to keep the meeting on target and exciting. We can talk about it Tuesday before the meeting."
"Thanks" Sharon said. "I was hoping you would figure out the exciting part!" She laughed. "But seriously, if we can get the team to own this first retrospective, and understand that we need to improve the process, that would be my goal. We can set up a board and draw up the different ideas, as we discuss them. And at the end of the meeting come up with a couple of items to tackle that can improve the process. Maybe the company could buy lunch too?" "I'll see if I can find some money in my budget." Jake said.
That Wednesday, Sharon led the meeting. She stood up. "For this retrospective, Jake has asked me to lead the meeting. The purpose of this meeting is to make our Kanban process better. We want to continuously improve our process, so we will do this retrospective regularly. In talking this over with Jake, we decided that during the third meeting, we will spend time doing Value Stream mapping of the process. I'll give more information as we get closer to that time."
"For this meeting, we want to find out what worked and what didn't. To that end, as mentioned in our email, we'll post up everyone's top three items that went well and the top three items we want to see improved. After all are posted, we'll vote on the top two items of improvement and give each a priority. Then, courtesy of ELFC, we'll eat lunch, and over lunch brainstorm ways to improve those items. If there are any action items out of that, we'll record them, and if possible add that to our Kanban board. Raj, let's start with your issues."
After a bit of fooling around, Raj said, "Sharon, my first item that we did well was our daily standup. I feel that keeping it short, but having the ability to communicate daily what we're doing has helped me more than once. For instance, I started working on an enhancement for the User Interface that included a new mortgage calculation. When I mentioned a problem I was having with this at the daily standup, Tristin said that he had already implemented that calculation in an earlier story. I was able to quickly incorporate that into my code." Raj continued with two more positive items. Sharon put those items up on the board in an abbreviated form that all participants could understand.
"One item I have a problem with is the silver bullet approach. My understanding was that a silver bullet meant an item that had to be done, and it bumped another item out of the Kanban. We were told this should happen infrequently. But, we had this happen two times last month. In the middle, I was working on an item, and Jake came and reprioritized an item not even in the Kanban. Then, Jake assigned that item to me; I didn't assign it myself. That seems to violate the spirit of the rules we originally set up."
Jake wrote down all of Raj's items without comment. "Thanks, Raj", Sharon said. "Does everyone understand the issue Raj has brought up?" "Raj, I understand that this violated the spirit of the rules, but you didn't speak up when Jake asked you if there were any problems. It seems that we had opportunity and we accepted the approach there," Tristin said.
"Yes, but I didn't feel comfortable speaking up. So, I don't feel that I can speak up that way. Our group needs to stick to the rules, at least in the beginning while we learn to utilize this process. That's the issues I want to bring up," Raj explained.
After Raj mentioned two more items, Tristin went on to give his six. Then, Jamie gave his six. On his last one, Jamie said, "I feel that the flow in the Testing Queue is not very even. At one point, there are six tickets in the queue and we need to deploy in two days. Then, three days later, no tickets are in the queue for a couple of days. I don't mind working hard, but we should be able to distribute the testing queue more evenly somehow."
Sharon posted that along with her six. Then, it was time to vote on what items the team felt they might take action on in the next month. The first vote brought up two items the team wanted to address. The two items selected were Raj's issue with silver bullets and Jamie's Testing Queue opportunity. At that moment, lunch was served! During their lunch, the team tried to come to a consensus on priorities.
Fixing the Issues
"I do not think that Silver bullets are going to be used that often" said Jamie. "To me, the queueing issue with the test items presents a flow problem with our system." "I agree" said Sharon. "I'm thinking Theory of Constraint introduced by Dr. Eliyahu M. Goldratt, author of the book The Goal can help us here. From what Jamie has said, it looks like we are having a constraint in development. I propose we work on optimizing that constraint first. Once we finish with our issue in testing, then we can work on the silver bullet issue."
Raj chimed in. "I understand the issue you mention, Sharon, but I believe we should address the silver bullet issue first. My concern is that we were originally told that the silver bullet was not for regular use, and we may never need to use it. But in the first month it was used two times. That doesn't seem to fit the original intent of a silver bullet. I believe the silver bullet impacts our system negatively because we are shifting focus in the middle of another feature."
The team went over the two options, with all the team giving input, except Jake. He wanted the team to feel ownership of this decision-making process. So, he just observed and took notes during the meeting.
Out of the meeting, the group came up with a couple of action items. For the Testing Queue, they wanted to "buy" more capacity. So first, the group suggested to Jake that they recruit another member for the group from the other developers. This would give their group three developers.
Jake did not feel management would go for this solution. He had one month's worth of results, showing improvement in productivity but that was all. So, he would make his pitch based on how this improvement in productivity could get his group's backlog down to close to nothing. This pitch would be based on numbers, not a feeling.
The group also came up with a plan B. "What if I did development for two days a week, assuming our request for a new resource gets shot down?" asked Jamie. So, the group proposed this splitting of duties as a backup if the new resource did not work out.