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.
Scott's Thoughts 
> How is that different from using a kanban board that looks like this?
It’s different for multiple reasons:
1. Not all stories will go through all of those steps, but by having the swimlanes you are force fitting the statuses.
2. By having the swimlanes, you are giving the picture that Create Test Plan cannot be done concurrently with Implementation, which it clearly can. Same thing with test. Actually, your swimlanes look like waterfall with test at the end, which is another Kanban bias.
Most Scrum practitioners avoid workflow step swimlanes because they limit creativity. ToDo, In progress, Done — is all you need.
Even layering Kanban on top of scrum has its downfalls. The kanban bias will try to describe software dev as an assembly line, thus getting rid of most of the room for creativity. Can your developers still be creative? Sure, but they generally won’t, because they’re being biased towards the assembly line steps. Throw in WIP limits at each assembly step and then you really have an assembly line.
Assembly lines are not exactly known for their creativity. I’d rather get creativity from a group of people sitting around collaborating in ways that are not described by assembly line queues and stations.
That’s why I was saying that the approach that you use depends on the problem domain and the team dynamics. When the tasks for a story vary between stories, then a kanban style approach isn’t optimal. However, when there is a natural flow to a lot of the stories it’s kind of a pain to list the same set of tasks for every story; that’s when a kanban type of approach is more suited.
The current project that I’m involved with, the scrum master for one of the team has been trying to introduce the concept of WIP limits without the vocabulary to describe it. There is a lot of crossover between these two styles of agile, it’s a matter of figuring out what works for the project and team.
> It’s kind of a pain to list the same set of tasks for every story; that’s when a kanban type of approach is more suited.
I still don’t agree with that view. Things change. The swimlane or “standard steps” might work fine for a little while, but change happens in software dev. Team members (with different skills/specialties) change, features change (they may not always be as static as you suggest), tools change (maybe you need to do some tool research with a story), designs/architectures change (maybe you need to have a meeting/collaboration to adjust the overall design or architecture), users change habits (and thus features will change), new information is learned about user usage (therefore features will evolve), business domain changes (new business logic might be needed)… All of these are changes that don’t fit nicely into the swim lanes you have designed, IMO.
I hear a lot of people talk about how “simple software projects” can be done successfully in waterfall. I agree in principal. Where I disagree, in practice, is that any such “simple software projects” of nontrivial size actually exist. All the simple stuff has been done. What’s left is the complex, and Kanban doesn’t bias towards the creativity(self organization, avoidance of swim-lane/assembly line mentality) and risk mitigation(sprint burndown, sprint review, sprint retrospective) that’s needed for complex software development.
If you’re really sick of writing the same stickies over and over again, keep the ones from last sprint and use them for this sprint. But ALSO, ask yourself, for each story “Are there any other tasks we want to do that we might want to describe differently than these standard stickies?”