This blog has moved. Go to SoftwareDevelopmentToday.com for the latest posts.

Monday, July 27, 2009

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.

Labels: , , , , , ,

at 13:33
RSS link

Bookmark and Share

6 Comments:

  • "But why do methods that were clearly developed with software development in mind expand to manage other type of work?"

    Just look at the agile Manifesto's values and associated principles. Replace the word software with product, service, results, etc. and the values and principles hold. The values and principles are about how to work and what is considered important in doing so, not what you are working on.

    By Blogger Software Qualities, at July 27, 2009 2:21 PM  

  • "But why do methods that were clearly developed with software development in mind expand to manage other type of work?"

    Hmm, remind me, where was Kanban developed? Toyota was not that much about software development..

    By Anonymous Anonymous, at July 28, 2009 9:54 PM  

  • @Anonymous Precisely. That goes to show that those that oppose Kanban as a valid Agile method are really missing the point.

    Kanban (as Scrum) are really just work management methods. So they should work for managing any type of work.

    By Blogger Vasco Duarte, at July 29, 2009 10:39 AM  

  • This comment has been removed by a blog administrator.

    By Anonymous Anonymous, at November 04, 2011 11:05 AM  

  • @Anonymous thanks for sharing that with us. can you explain why you think so, or are you just a coward who disagrees but doesn't even know why? ;)

    By Blogger Vasco Duarte, at November 04, 2011 3:53 PM  

  • This was really helpful - I'm trying to format JIRA to work well within a creative team...the rest of the departments have utilized it for years, whilst creative has been in a love affair with excel to create (what are with the use of JIRA, redundant) triages. I'm having a difficult time figuring out what the real difference is between a Scrum and a Kanban and which would be the best to triage and organize creative projects (ie design and copy for web, print, etc). Thanks!

    By Anonymous Anonymous, at May 14, 2013 8:37 PM  

Post a Comment

Links to this post:

Create a Link

<< Home


 
(c) All rights reserved