I just finished David Anderson's Kanban: Successful Evolutionary Change for Your Technology Business, and I really enjoyed it for its sensible combination of ideas into something that really seems to work. And while he doesn't discuss it, I see application in many other areas than software development.
First off, to clarify for people familiar with the term "kanban" from Lean implementations, this is not a book about the kanban card systems used in manufacturing. Kanban (capital "K") is a system that David created that uses ideas from Lean and Theory of Constraints and several other disciplines. Interestingly, David talks repeatedly about his Kanban system as a change management system, not a new way to do software development.
One of the most obvious elements of Kanban is the visual control that is central to other kanban systems. In this case, it is usually in the form of a whiteboard that shows the status of work as it flows through the system. (This is often backed-up by an electronic tracking system.) Of course, simply putting up a whiteboard with swim lanes and buying a stack of appropriately-colored notes isn't going to make the system. There are a number of discussions to be had and decisions that need to be made for this to work, and these are outlined in the middle section of the book.
What makes Kanban a change management system, rather than a workflow management system? If it's set up right, it ends up creating change by creating transparency in the process. This is one of the great principles of well-designed Theory of Constraints solutions too. If you have a strict WIP limit and something gets stuck, people take notice quickly because the work slows. With the right information, everyone can take notice and work together to resolve the problem. If the same problem occurs over and over again, smart organizations will seek to eliminate the source of that problem - this even happens with the customers / suppliers of the organization that has implemented Kanban. Internal and external change comes out of new ways of operating. David mentions organizational maturity at a number of points through the book, and this is the reason. High maturity organizations are able to manage these changes naturally, where lower maturity organizations may need someone to help point people in the right direction. The last several chapters of the book talk through various aspects of how Kanban motivates making ongoing improvements in the organization and in the use of Kanban itself.
How does this apply outside of software development? I can see this working in almost any organization that has relatively fast, repeatable work. (Not that the work is exactly the same, but the process of doing the work is repeatable.) For example, I think this could apply in an analytical lab that is responsible for regular analyses (and reports) as well as developing new methods for new compounds. It's very easy for a lab to get overloaded with incoming work and get stuck in finalizing the paperwork to close out the backed-up orders. The principles of limited WIP (work in process) and transparency will help. There are even examples of people using this kind of mechanism for their own work with Personal Kanban. I wonder how far one could take Kanban with projects.