I had an interesting experience last week, watching another scrum master try and develop the concept of limiting work in progress and then explaining it to the team.  I found it interesting because of my background with lean development.  In lean, limiting work in progress is a core piece of lean, so it kind of goes without saying.  That started me thinking about the crossover areas between lean and scrum and the way they interrelate across similar problem areas.

That’s when I saw this post http://scrumcrazy.wordpress.com/2013/02/04/kanban-vs-scrum-kanban-is-not-for-software-development-but-scrum-is/

I can’t say it’s comparing apples to oranges, more like comparing apples to the orange peel. Comparing scrum to kanban is kind of like comparing lean to a sprint planning meeting. A kanban board is one facet of using lean to manage a project, the same way that using a sprint planning session is just one facet of using scrum.

My background with scrum is a little different from most software people.  I’ve used scrum since before it was called scrum.  I’ve even used scrum to stay on top of non-software projects like building houses or disassembling a paper machine and shipping it to Ecuador.

Although to be fair, on the paper machine project, we didn’t call it scrum. It was still scrum, time boxed sprints, sprint planning/retrospectives, daily standups where you answer the 3 questions. In short, scrum for non-software projects. The guy in charge just called it “The way we f$*&*^% do things to that we f@#$$#  stay on top of the f@#$*&% b@#*$ and get it f*&#$%* shipped to f%&^*$# Ecua-f*&%@$#-dor on f*#&@$# time!”

Likewise, I’ve used lean techniques for non-software work too, including using a personal kanban board to keep things organized around the house. Both lean and scrum are project management techniques, not software development techniques.

Part of the misunderstanding about the competing ideas of lean and scrum is that people don’t understand the basic philosophy of each of them.  Lean is premised on the idea of having a defined process and undefined amounts of work. Scrum is based on the idea of having a finite amount of work and an undefined process for completing it. So, what does this mean in real terms?

Think of lean as kind of like the help desk. You call the help desk and there is a defined process for how to handle the request. (Whether you like the process or not is irrelevant.) The call gets logged, the importance is evaluated, resources are assigned, it’s completed and closed.  There’s a defined process for how to handle a call, but the individual call is unique and changes each time.

Scrum is kind of the opposite, there is a finite amount of things to be done but each of those things may be done differently. Think of it like shooting a movie, you know how many scenes there are at the start of filming, but each scene requires different things to complete, different actors, locations, props, etc. So the tasks to complete each piece of work vary (perhaps by a lot), but the number of pieces is known pretty early.

Basically, you need to figure out at the start what kind of project you’ve got to figure out which project management techniques will work best. Although, for a lot of projects there is a grey area, where it’s not a clear case of which is definitively better.

For example, say your stories and tasks start looking like this:

  • Story 1
    • Design UI (Complete)
    • Implement Story (In Progress)
    • Create Test Plan (Complete)
    • Test (Not Started)
  • Story 2
    • Design UI (In Progress)
    • Implement Story (Not Started)
    • Create Test Plan (Not Started)
    • Test (Not Started)

How is that different from using a kanban board that looks like this:

Design UI Create Test Plan Implementation Test
Story 1
Story 2

To me, they are equivalent. When the tasks are pretty much all the same, that’s the time where a lean approach shines.  However, when you have a kanban board with all kinds of notes on it about what state the work item is really in because the board doesn’t contain all the special states, then a scrum type of story/task split is going to be more effective.

At then end of the day, it’s a matter of choosing the right tool for the job. Project management is just as demanding a discipline as software development and just as crucial to the success of a project.  Recognizing that you have multiple tools in your project management toolbox is an important, and often overlooked, skill.