Continuously Improving Your Kanban Change Request Process
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."
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."
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.
- David Anderson: "A Kanban System for Sustaining Engineering".
- Mary Poppendieck and Tom Poppendieck: Lean Software Development: An Agile Toolkit.
- Dr. Eliyahu M. Goldratt: The Goal.
- Johana Rothman: "Matrix Management is not the root cause."
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
Page 2 of 2