Managing Change Requests Using Lean Methods and a Kanban Board
For many software development groups, managing change requests is a burden. We all want to work on the latest software projects. Using agile techniques such as Scrum or MSF Agile to manage projects works well for smaller teams focused on one project. Scaling Agile to the enterprise sometimes proves difficult for many enterprise shops. Existing Agile techniques assume a team working on one project, not an enterprise team working on multiple applications. There is another agile way to mitigate these issues. You will explore how to use the lean artifact Kanban board to manage your software's change requests.
Welcome to Eric Landes Fictional Corporation
To better illustrate how the Kanban can be implemented in a company, I will use a fictional company's development team to tell the story.
This team demonstrates how Kanban can be implemented in an existing company. The company is Eric Landes Fictional Corporation (ELFC). Keep in mind that this is a fictional company with fictional people. Any resemblance to a real corporation or real people is not intentional.
ELFC is a regional health insurance carrier with a fairly large IT department. That IT department includes a staff of 16 developers, 6 business analysts, and 7 testers. A small group in this department focuses on the change requests for existing applications. Jake is the manager of this department, which is called Software Maintenance. Jake manages two developers, Tristin and Raj. One business analyst (Sharon) and a tester (Jamie) are part of the team as well.
Jake was recently appointed head of the Software Maintenance (SM) department. When he took over the department, he inherited a backlog of change requests. There were a total of 110 change requests in his queue. In analyzing the turnaround for requests, he found out that each request had a cycle time of close to two months. Jake could not find any statistics on the amount of rework the team had to undertake.
The company needed to increase the response times for business reasons. The applications used by the business are critical to get new health insurance products to market quickly.
Jake comes to the SM group as a former team lead for an agile development team. He is familiar with using Scrum to manage projects, and certain XP methods, like pair programming and iterative development. He believes that customer involvement, releasing often, and embracing change are the right way to develop software.
Jake began researching different methods for managing changes two years ago. He read up on the buzz of lean software development using Toyotal Production System methods. This reading provided interesting ideas for this particular challenge. These ideas came from reading articles about the work of David Anderson at Corbis, and looking into Mary and Tom Poppendieck's writings on Lean Software development.
David Anderson's work had much to say on improving the scalability of Agile. More important from Jake's perspective, David writes about improving the flow of development to increase productivity. By using lean methods at Corbis, they could emphasize flow of work to help smooth variability and improve predictability. This method also emphasized continuous improvement and process. These methods also work well with groups that have very defined job categories. Instead of having the developer wear the different hats of business analyst, tester, and developer, the Kanban method can treat each as a separate job function.
When talking with his manager, Ron, Jake said "Ron, I have two goals going into this new assignment. I want to decrease the backlog by 50%, and decrease the cycle time of requests in the Software Maintenance system." Ron, sensing a challenge, replied "That's a great goal, Jake. I'll give you six months to achieve those goals! We'll re-evaluate after that time."
The agile projects Jake had worked on before brought a predictability to the release of new software that he wanted to bring into the SM group. Now that Ron had thrown down the challenge, Jake had to get down to business. From his reading, Jake felt that implementing a Kanban board to track the flow of work would keep agile principles, and implement new lean concepts to help the group achieve his goals.
Now that he had a plan, Jake had to present it to the group and get buy-in. Getting team buy-in is essential in agile projects. Teams almost always have some part of self managing when using this lean agile concept.
Implementing the First Plan
To prepare for a meeting with his group, Jake put together a spreadsheet to show what stages each request was in. From looking at samples on the web, and looking up the origins of Kanban, Jake knew the literal definition meant "visual board." This idea resonated with him, because in previous agile projects, the status was kept extremely transparent. Stories and current status were listed on a board in the team room.
The information Jake wanted to show on the board would include what he developed in this spreadsheet. Jake has four different buckets where a feature might be in the life cycle: Business Analysis, development, QAS (testing), and Customer Acceptance Testing. The idea is to show those stages on the Kanban board. By meeting regularly, this should expose issues that might be festering for some of those features. Figure 1 shows part of Jake's spreadsheet.
Figure 1: Jake's spreadsheet compilation