Kanban provides a revolutionary — and simple — way to manage the most important job IT departments have: Maintaining existing applications. But to effectively manage software maintenance you first have to understand the fundamental difference between maintenance and development.
Before I became an independent consultant, I was the head of the IT department for a multinational, multi-million dollar heavy equipment manufacturer. That may not be the kind of shop that you’re part of but I bet your shop and mine had one thing in common: Most of my department’s time was spent on software maintenance — extending, modifying, enhancing and (occasionally) fixing systems that kept my company in business.
I never really got my hands around how to manage maintenance even though it represented 80% of my budget. What’s ironic about that is that the tools I should have been using to manage software maintenance were in place on the shop floor of the company I worked for…and had been for several decades.
The reason I didn’t do a good job of managing maintenance was that I hadn’t grasped the fundamental differences between software development and software maintenance.
Software development treats each project like building a bridge: A group of people are brought together, money is allocated, money is spent, something is built, and the project is over/the team dispersed. Costs appear as the project is started and end when the project is over.
In software maintenance, the team is not assembled at the start of the project and disbanded at the end — the maintenance team is an ongoing expense. Unlike software development, the costs associated with software maintenance are not treated as an investment but as part of the “cost of doing business.” If development is like building a bridge then software maintenance is like owning a factory: the mortgage payment, heat, light, and other utility costs are due every month and they don’t fluctuate much from year to year.
Owning a factory is what the accountants call a ‘capital expense’ and, when you think of software maintenance that way, it makes all the difference in the world.
As any MBA graduate (like me) will tell you, to maximize the value of a capital expense you concentrate on just one thing: Throughput. Or, to put it another way, getting as much out of that factory as you can. Beginning in the 1940s, the Japanese developed processes and techniques, including Kanban, that were designed, among other things, to maximize the value of their factories by improving throughput. Not surprisingly, people have been applying those techniques outside of manufacturing.
Learning Tree, for example, has several courses that show how Kanban can be applied to software development (“Lean-Agile: Combining Kanban & Scrum”, for example, uses Kanban as a way of scaling up Scrum to handle large projects). But, for me, the place where Kanban really makes sense is in managing software maintenance.
Using Kanban to improve throughput in software maintenance requires only two things:
The difference this makes can be astonishing: Microsoft’s XIT team implemented Kanban and reduced the typical lead time for a software change request from five months to fourteen days, improved productivity by 155%, and cleared their backlog. They did this in nine months and with no new resources.
Implementing Kanban is simple – so simple, in fact, that it doesn’t require the organization to change much (which makes it very attractive to IT departments because it reduces the politics involved). The first step is the critical one: The IT department decides on the maximum number of software change requests that the department will work on at any one time.
The simplest way to get an initial cut at that number is to take the number of available developers and multiply by two. That gives each developer a task to concentrate on and another task to work on if the first task gets blocked for some reason. That’s probably going to be too high because most request aren’t blocked so, over time, departments will experiment with that number to determine what’s optimal for them.
To manage the process, the department sets up a Kanban board divided (again, at its simplest) into three columns: pending, in progress, and completed. Incoming/pending requests are written on sticky notes and stuck in the far left column (the “pending” column). The number of requests allowed in this column is also limited – usually to just a few more than the maximum number of requests allowed in the middle column. This number is probably too low because developers will sometimes exhaust the pending requests faster than new ones can be added. Departments will also experiment with this number to ensure that developers always have work to do (without, of course, being overloaded).
The administration is simple: When developers finish a request, they go to the Kanban board, move a sticky note from the pending column to the middle column (the “in progress” column), put their initials on the note, date it, and start work on that request. When the task is completed, the developer moves the sticky note to the far right column (the “completed” column), dates it…and picks a request from the pending column.
Whatever process handles completed requests takes requests from the right-hand column as they appear. On the other side of the board, as requests are removed from the pending column, new requests can be added…as long as the number of requests doesn’t exceed the maximum for the pending column. New requests must meet two criteria: The organization must want to have the request completed in the near future and the time required to complete the task must be below whatever limit would classify the request as a development project rather than a maintenance request.
With this system in place, developers always have work to do and requests are pulled through the system as developers have available time.
As I’ve described it, this system is probably too simple for most IT departments. Many departments find they have separate classes of maintenance requests (“immediate bug fixes” vs. “discretionary enhancements”, for example) and it makes sense to allocate limits among those classes. Most departments also have more complicated processes than I’ve described and need more than just pending, work-in-progress, and completed columns (most departments find it valuable to add columns for analysis and quality assurance, for example). If a department adds a column to the right of the work-in-progress column, they often collapse the completed into the work-in-progress column as a sub-column. All of these options are covered in Learning Tree’s “Smoothing Development Workflow: An Introduction to Kanban” (for example, we recommend adding swimlanes to the board to handle the various classes of maintenance requests).
Even with these additions, managing and monitoring software maintenance is easy: If, by looking at the date on a sticky note, the manager discovers that a request has spent a long time in one column, there’s a problem to be investigated. Alternatively, if a column is emptying quickly (indicating that there may be no work for the people in the next column to do), there’s an opportunity to be grasped. Many organizations also develop a standard for flagging requests that are stalled for some reason (waiting for someone to make a decision, for example). Often that’s just putting a red sticky note on the stalled request and writing the date and reason on that note. If a request has been stalled for a significant period of time, that’s another problem to be investigated.
However you choose to implement Kanban, you’ll do what I couldn’t accomplish back when I was running an IT department. You’ll effectively manage your department’s most important task: Maintaining the software that keeps your organization going.