JavaEnterprise JavaContinuously Improving Your Kanban Change Request Process

Continuously Improving Your Kanban Change Request Process

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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.

Current Status

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.

The Retrospective

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.

The group also agreed to implement better quality software engineering practices into their change management. Using Test Driven Development, they agreed to try to achieve 90% or higher code coverage via unit Tests. They also agreed to create automated customer acceptance tests. This was one place where Jamie could help out by writing those tests in conjunction with customers.

Using these quality practices seems counterintuitive. Adding more work like automated acceptance tests and more unit testing should increase the workload. But, the team agreed that they need to be implementing software engineering best practices. And, Jake hopes that using these best practices will help decrease time when making complex modifications. The unit tests and automated acceptance tests should provide a stable framework that allows developers to make changes and easily check that they have not harmed other features.

The SCM group continued showing impressive productive results. Jake continued to show Ron his manager velocity and burndown charts. He also kept velocity reports updated near the Kanban board. This helped the team keep their progress in mind. Figures 1 and 2 show samples of what those reports might look like.

Figure 1: Sample Burndown chart

Figure 2: Sample Velocity chart

Three months later, Jake went into the team room for a daily stand up. Because of his success with this group, Jake was now managing another group. Jake had not been able to add a new developer to the group right after the first retrospective. But, it looked like the group was going to get enough new money to hire two new people for the SM group. Because of his new responsibilities, Jake could not attend all the daily meetings for SC.

“Sharon, that was great how Tristin and Jamie worked out a new fix to our testing process during the daily standup. That’s something I would normally expect in a retrospective, but they took care of it right away,” Jake said.

“Yes it’s something we call ‘Just In Time’ retrospectives” Sharon said. “It’s a concept I picked up from the kanbandev mailing list on yahoo. We shouldn’t wait to implement fixes to the system, if the fix is something the team can implement immediately. If we wait for the retro, we might forget it, and we will not have that immediacy that making the changes during the daily stand up gives us. We will still occasionally do retrospectives, but perhaps not as often. And those should be taking a higher level view, maybe using a value stream map.”

Kanban Spreads

As news spread around the IT department, the Kanban idea began to spread. Two other groups in the company have asked Jake to talk about Kanban with them. Jake, with Ron’s blessing, has agreed to help those teams out with the implementation. The idea with Kanban is not that the board is an end in itself, but that it keeps the team improving. As Jake says, “Continuous improvement is the goal for my teams, no matter the method.”

Conclusion

Sometimes, you have to see how something works, even if it is on paper, to really understand the technology and its benefits. Hopefully, the scenario I presented in these two articles will show you the benefits of implementing a Kaban Board within your team to improve productivity.

References

About the Author

Eric Landes is a Project Manager/Project Lead for a large corporate IT department, specializing in developing custom SharePoint applications. He has three years’ experience using Agile techniques in developing enterprise applications and over 15 years’ experience in software development. See his blog, or linked in profile for more information

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories