There has been a lot of interest lately in so-called “Kanban.” While it would greatly alleviate my personal angst to discuss the use of this term, what it really is/means and so forth, that would likely only be interesting to me (and a few other pedantic people who will remain nameless). Instead, I want to talk about taking an Agile approach to what is generally more predictable work than new product development (e.g. for support teams). I get asked about “support” all the time. Recently I was asked via email, “How can I ‘use agile’ for support issues? Scrum seems like too much overhead.” When someone asks that, especially if they say they want to “use agile”, I have to ask more questions:

“What kind of support?”

“Do the people doing support also do new product development?”

“Is the support for a product currently in development”

“Does support include new feature requests?”

“What does ‘using Agile’ mean to you?”

Depending on the answers to those questions, there are a number of suggestions I make. If it’s interrupt-driven support of business stakeholders with a quick turnaround SLA (Service Level Agreement for you non-IT types) there isn’t really a specific process I’d choose. A simple task board (or traditional help desk system like Remedy) is probably adequate and the relevance of “Agile” is more related to the Agile values than a specific process implementation.

If the people doing support work are also doing new product development, I would probably just roll the support work into the Scrum workflow, making sure that support issues are triaged by the Product Owner (with the business owners of the product or products being supported) and leave room in the Sprint Backlog for that work to be addressed; ditto for support of a product that is also currently in development.

If the support includes new feature requests then the question is, “How often are new features deployed?” If they’re delivered according to a set schedule (e.g. a patch every month or every quarter) then again the Scrum workflow is probably appropriate.

There is a fuzzy area in-between straight interrupt-driven support and support with regular new development on a fixed schedule. It occurs when support is ongoing and new feature development is customer driven (i.e. there isn’t a set schedule for patches and new features are delivered in an ongoing fashion). In that instance I’d probably want something more disciplined than just an issue tracker, but without all the “ceremony” of Scrum (even though Scrum is already pretty low ceremony there are certainly approaches that are lower). Extreme Programming (XP) is probably my first choice for this.  I’d do a weekly “planning game” with the “customer” (or more likely an internal representative of the customer(s)) with customer acceptance tests as work is completed, Daily Standup, etc.

In almost all of these cases, having the team use a simple task board to visualize their work and limiting their work in progress is a useful tool. A visual representation of “cumulative flow” (which is really just a “burn up” with more variables) is useful for identifying bottlenecks and determining “time in queue” (i.e. cycle times) amongst other things. I suppose if people want to call that “Kanban”, that’s fine. But without explicit agile engineering practices and/or lean management practices, “Kanban” is no different than old school “code & fix” and more often than not it’s just cover for an undisciplined organization.

The whole point of Lean thinking and Agility is continuous improvement through regular learning and giving the people closest to the problem the authority and autonomy to solve it. If you take that stuff out, it’s really just business as usual (which may be good enough, but there’s no need to give it a new name). Lean and Agile are ways of thinking that usually lead to different ways of working, AND it’s the thinking part that’s hard and which is skipped over to get to a mechanical recipe for success (which doesn’t exist). If an organization isn’t going to change their thinking, the various Agile and Lean tools available will do little to change things. You just get a new set of SOPs (standard operating procedures). In other words, “new boss same as the old one.”

Jimi Fosdick
CST