Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
Current Situation
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.
The Plan
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
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.
One Month after Implementation
In the first month after implementation, the SM group saw the backlog shrink from over 100 features to less than 60. Cycle times decreased to around one month and one week. So far, Jake’s discussions with the stakeholders have found them cautiously optimistic about this new approach.
Jake set up a retrospective for one month after the initial implementation of the Kanban system in SM. In the retrospective, the team came up with some new ways to improve the Kanban. The team had used Kanban to give them visibility into their process to help eliminate waste. The waste found included change requirements that were not necessary. Jake thought the next step the group needed to take would be to continue eliminating waste. More importantly, the group would need to improve their ability to add business value. Jake felt they could achieve this in the next six months.
(The next installment looks at how Jake and his group use the Kanban process to add value to their company).
References
- David Anderson, “A Kanban System for Sustaining Engineering“.
- Mary Poppendieck and Tom Poppendieck. Lean Software Development: An Agile Toolkit.
- 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 two years’ experience using Agile techniques in developing enterprise applications. See his linked in profile for more information
