Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Sep 24, 2012 — Enterprise Agile Planning expert

Kanban is a Tool, NOT a Solution

Enterprise Agile Planning

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.”

More from the Blog

View more
Jul 27, 2021 Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Contact Us