Can Scrum and Kanban be used for non-software development work?

Can Scrum or Kanban be used to manage any other work than software development? Do the same concepts apply?

The past week-end there's been some chatter on twitter about using Kanban or Scrum for managing work outside the software development realm.

People seem (pleasently) surprised that it can be done. But can it really? The answer is YES! But why do methods that were clearly developed with software development in mind expand to manage other type of work?

Well, we have to look at the roots of these methods to understand that. Both Kanban and Scrum based their core practices around a list of "stuff" to do. Features/stories in software development fills these lists or backlogs, but in an advertising agency, for example, the "stuff" will be something like drawing proposals for clients, brainstorming meetings, research work, etc.

Through these lists, Kanban and Scrum establish an order of work (what to do now?) and allow what is normally a disconnected mass of work to be organized in a way that a team can use, not only to execute, but also to follow-up their work (e.g. through a burndown/burnup chart)

Indeed, at the root both Kanban and Scrum are just formalized work management methods that were created to overcome the chaos that is still so normal in software development organizations. The hidden truth however, is that the same chaos is present elsewhere and those companies can benefit as much from Scrum/Kanban as the software industry is benefiting now.

The corollary of this is that Scrum/Kanban can be used to do anything, from building a space ship to planting potatoes, and I have even used it for personal non-software development work as well as helped others establish some of the ideas behind Scrum as their own "working method".

There's a catch, though!

Getting back to the backlogs, both these methodologies need a steady stream of work to be analyzed, prioritized and ultimately picked up to be worked on. Because the constraint (i.e. the part in the system that is always busy) in the process is normally the project team, it is imperative that special attention be given to the backlog, where work is listed and described. It is often a good practice to regularly spend time analyzing the work in the backlog to make sure that it fits the Vision for the product/project and that it is sufficiently well defined so that the team will not lose their time trying to figure out what the work-item really means.

For this we normally have a manager (called product owner in Scrum) whose time is spent analyzing the project/product and deciphering the customer needs into a format that the team can understand.

This work is crucial, and the real reason why teams need "managers" (product owner in Scrum).

Manage your work for better performance

The key message here is this: Your work performance will only be as good as you are at managing the backlogs.

Because Scrum/Kanban are work management methods, it follows that the team's performance will depend heavily on how the backlogs are managed by the team and their manager. Therefore, the hidden pearl in Scrum and Kanban is that you should focus a lot (but not all) of energy in defining and improving how your manage your work. And this is valid for any type of work. Be it software or creative projects in an advertising agency.

An inconvenient truth, in work management

I bet anyone in my position (Agile Coach) has faced this before: you present a work method to a team or a person (be it scrum, XP, DSDM, FDD, etc.) and they go "yeah, I see what you mean, but that would never work here".

If I only had a dime for every time I heard that I could be rich!

Today it happen again. Here I am presenting the Personal Scrum work method. People are following, they are asking some good questions and at some point it hits: "Yeah, I see what you mean and it makes sense, but that would never work for us. We have too much work we cannot predict because we want to have a very fast turnaround for our customers (1 business day) and that's why we cannot really plan our weeks that way. On top of it we are too busy to spend that much time (1-2 hours/week) planning what to do."

Now, for most of you (if not all) the problems in this phrase/quote are quite transparent, but for the person saying it, it was not. They did not understand some of the basic principles of work/time management and productivity:

1. If you cannot allocate your whole week because some portion of it will be "unpredictable" (have you heard of maintenance in production software?) then you don't allocate the full week to planned work! That's not a reason not to plan... Just estimate how much time you need for "unexpected" items (and that tends to be pretty regular from week to week), and plan the rest of the time!
   
2. If you are too busy, then how do you know your are doing the most important things for your stakeholders/customers? Are you setting aside the time to think through the priorities of your work from your customer/stakeholder's perspective? If not then I'm sure they'll be mad at you or at least disappointed -- even if you are busy!
3. If you are too busy (yes, again), that means you are "thrashing". This means: you have started many threads of work but are getting none of it done! Remember that only work that is "done" counts. Starting something you don't finish does not count (unless your manager/supervisor is clueless, in which case it is time to search for a new job anyway). Search for the ZEN of getting things to "done".
   
4. Work is work. Stating that a method (whatever that method is, take GTD for example) does not apply to manage your work can only be a result of not understanding the basic essence of any piece of work: 1) you get an order with some information and possibly inputs; 2) then you process it, alone or with a team; 3) finally you finish the work (as in "done"). This is true for every piece of work that needs to get done, whether it is planting potatoes or designing a piece of software, and certainly writing a business proposal or answering an RFP. If you don't understand that basic attribute of work there's a deeper problem we need to address. Managing the work is the least of my worries when I face this type of situation.

Now, all of these observations could have been done by anyone with experience in trying to manage work. But (and this is the sad fact) there's not too many people out there that understand the concept of "managing one's (or one's team) work". Sigh...
This brings back memories of a conversation I had with a senior and well known Scrum trainer/guru when he was training at our company:
In the CSM training, after the "promise" game exercise he was looking down and gloomy. I walked up to him and asked what was the matter. He turned and said: "see, this (the problems uncovered by the "promise" game) is what I see in all companies I visit, and that just makes me feel sad about the state of our industry. See, what I'm trying to do is just make our industry better, more professional".

Indeed, better and more professional. That's the right goal!