Short Answer
Honestly, it doesn’t matters. If it helps an organization create value for its customers in a way that allows employees to experience freedom while solving challenging problems, it doesn’t matter what label the method carries! But, that would be too short a response.
Longer Answer
One way to decide if something should wear the label “agile” is to look at how it reflects the values stated in the Agile Manifesto. Of the Agile Manifesto statements, this is how Kanban values the “items on the left” over those on the right.
Individuals and Interactions over Processes and Tools
The visibility that Kanban provides to teams is a key contributor to facilitating interaction amongst individuals. The kanban board gives visibility to impediments that individuals are encountering makes resolving the impediment of prime importance.
Unlike Scrum, Kanban does not explicitly encourage generalization of skill sets. While Kanban does not force you to have a role for every queue, it is often easy to start by mapping the roles to queues and then inspect the bottlenecks and address those by helping the team develop more generalized skills.
Kanban is not a tool or a process that supersedes the importance of the individuals and their interactions. Yes, Kanban provides a lot of metrics that can be used to inform planning. However, the metrics are to facilitate interaction among team members, between team and stakeholders, and between team and customers.
Working Software over Comprehensive Documentation
When using Kanban to produce software, there are specific characteristics of Kanban that allow you to value working software over comprehensive documentation; small batches, WIP limits, measuring and managing flow. Perhaps your workflow will have a step or steps related to creating documentation.
Kanban does not prescribe working software, other than through mapping your value stream. If the last step in the value stream is working software, you can use Kanban as a tool to make sure you do that.
Customer Collaboration over Contract Negotiation
Kanban encourages customer collaboration through the prioritization of the backlog. Prioritization of the backlog is an ongoing process. Agile Kanban practitioners often use user stories or minimal marketable features (MMF). Use of either of these approaches supports customer collaboration in creating those items. The person who provides the detail on the stories or MMF is also available to the team to respond to questions.
As in Agile, daily standups are also present in Kanban. Unlike Agile, only people with issues speak in the daily standup. The standup meeting is an opportunity to speak up, whereas in Agile the traditional “three questions” are often present. This gives the team an opportunity to elevate issues to the Product Management representative’s attention, allowing them to be a partner in the process.
Silver Bullet Policy (see slide 20 for a brief overview) allows the customer to swap out an extremely high priority item for the current work in progress. There needs to be a swap so that WIP limits are not exceeded. Silver Bullet Policy may never be used, but can give the business the feeling that if there is an emergency, they can use this policy.
Responding to Change over Following a Plan
Agile teams often plan on a regular cadence. In Kanban, planning events can be triggered on an event. For example, your team may have a rule as follows: When the backlog backlog has dwindled to ten stories, a planning event will be held.
Unlike Scrum or XP, where the teams try to identify a piece of stability to work on for a period of time, Kanban allows the team to re-prioritize the backlog at any time and take something new off the backlog. This allows the team to respond to change sooner than if they were locked into a set sprint duration.
Summary
While Agile is primarily focused on software, Kanban is more focused on developing a lean organization . In fact, the business-oriented language that surrounds Kanban may make it an easier Agile model to embrace than Scrum.
While an organization or team can claim to be using Kanban and use it in non-agile ways, that will not be the case when done well. If the team and management use visualization, set WIP limits, and iterate on the value stream, Kanban is an excellent option for Agile teams.
Find More Information
There are lots of excellent resources on Kanban. My favorite reference is a book called Kanban – Successful Evolutionary Change for Your Technology Business. Thank you, Eric Landes, for loaning me your copy for a while. For further reading, check out the InfoQ version of the Kanban and Scrum Book.
A special thank you to Eric and Susan for co-authoring this blog.
I’m not sure the following is correct: “Unlike Scrum, Kanban does not explicitly encourage generalization of skill sets.”
Scrum explicitly encourages cross functional teams, but says nothing explicit about generalized INDIVIDUALS. Not saying that Ken Schwaber would say cross functional individuals are bad, just not something explicit in Scrum.
We’ve been having this argument internal at Northwest Cadence (and on Twitter) for a while. Two recent blog posts on the topic go through some of the arguments: “Do Teams of Cross Functional Individuals Hide Dysfunctions?” (at blog.nwcadence.com) and “How Flexible Should an Agile Team Be?” (at blog.bsktcase.com).
Cross functional teams critical to Scrum, and to most agile methods, however, relying on cross functional individuals may actually hide problems. (See Toyota Kata for more information.)
Steven,
Thanks for the comment. I read the blog on cross functionality potentially hiding dysfunction, and believe you raise good points. I was thinking of training that Mike Cohn has provided with regards to generalist and specialists on teams; generalists can help the specialists be specialists.
The other post on Agile Team Flexibility is also a good one. Would it be fair to say that having the ability to function in more than one capacity on the team is good, as long as it is not abused to hide dysfunction?
Hi Dan,
I think there’s an increasing interest on Kanban, in fact I have published an article last week titled Scrum vs Kanban (which I hope you will get the chance to read).
I would like to republish your post on PM Hut as I think PM Hut readers will enjoy it. Please either email me or contact me through the “Contact Us” form on the PM Hut website in case you’re OK with this.
Hello,
Thanks or the comment. I agree that there is increased interest in Kanban lately, and more interest in the use of “lean” within software development. It is an interesting time of change. I read the Scrum vs. Kanban article you published, and will add a comment to that post. I have observed that some folks put up a map of a very simple value stream (not necessarily their current value stream), neglect WIP limits, and don’t iterate on the process, and call it “kanban.” It is unfortunate, but it’s not going to provide the value that using Kanban can provide. This is similar to teams that do “scrum but…” It is OK to not do Scrum, of course, but it would be better if they did not call it Scrum.
Inspecting and adapting the process is hard, and it is easier to make a break from those methods by installing another framework than it is to get true change via inspecting and adapting their process. In fact, waterfall teams I have worked with had a “lessons learned” where they intend to change the process, yet often the change never materializes. That is probably an article for another day.
I will contact you via the PM Hut site.
Pingback: Getting from A to B with Kanban | MarkjOwen's Blog