Scrum or Kanban – It does not matter

This is a guest post by Boris Gloger (@borisgloger)

A couple of days ago I commented on Matthias’ post about the myth that Scrum forces a team to release new functionality only after a sprint is finished while Kanban would is more flexible.

I wanted to know the difference between Scrum and Kanban, and why people start to blame Scrum as the enemy saying that it’s too disciplined, too inflexible, and, and, and… So, I attended David Anderson’s intermediate class about Kanban.

What I found in David’s class was truly eye-opening. David claimed that Kanban won’t change anything. It only visualizes the current work procedures and openly discusses any hidden policies. And, by imposing a slightly difficult to achieve Work in Progress Limit, organizational change starts to emerge. He said this self-change is the difference between Kanban and Scrum. Evolution instead of Revolution.

First off, I really like the ideas and insights of the lean production philosophy. I think it’s great that David was able to adapt these insights for software development. Especially funny were the people who recognized me in the training and wondered why I had joined. I am “Mr. Scrum”. So, how could I associate myself with Kanban?

Well, since 1994, I’ve actually believed these ideas are very, very useful having studied Lean Production Theories, System Theory and the Toyota Production Way in Germany. When I discovered Scrum in 2002, I was convinced that Scrum handles all the issues I saw addressed with lean production ideas.

I think David’s super elegant way of bringing lean production into the world of Software Development is a big step in the right direction.

But, it really bothered me that people in his class didn’t ask the kinds of questions they ask in mine, like:

• What if people don’t want to create a task board?
• What if they simply don’t want to collaborate?
• What if they don’t want to sit together?
• What if management doesn’t want to work this way?
• How do I get a release plan?
• How do I get the project costs … ?

I know some people who haven’t been able to run 3 consecutive Sprints, who couldn’t find a Product Owner, or who didn’t solve the issues of a team getting disturbed all the time.

The same people say Scrum doesn’t help with these problems and that Kanban is the now the cool way. Well, maybe I shouldn’t bother, but Kanban fails to address tons of issues for which Scrum Enthusiasts have already found a solution.

Today, Scrum Practitioners know how to:

• Scale large projects,
• Address the issues of large teams
• Address the issues of dependencies between teams
• Build large architecture frameworks with Scrum
• Work with departments for change in corporate culture
• Calculate the cost of a project upfront
• Create estimation techniques that are fast and valid
• and much more …

i.e. The famous swim lane pattern for big enterprises that David explains in his book is a pattern I developed in 2004 at WEB.DE in Germany for 4 Scrum teams. We use it today in a large-scale project with 180 people – and I’ve explained this idea in my trainings since 2005!

But, neither Scrum nor Kanban nor ASD nor Crystal are able to deal with one issue:

People fail to change course even after seeing impediments. They don’t want to change for the better. Most people, and, sad but true, even most Scrum Masters, need a person who helps them improve. A person that shows them the high road.

Someone using Kanban, Crystal or ASD must be able to convince his team or a manager that what they see is justification for improvement. Ken Schwaber always said: Don’t say it, show it. I must admit that even I didn’t see it: David’s genius lies in the fact that he makes people believe it’s the new method, and not their own ability to simply fix what’s broken.

His way of convincing people that the new idea was their own is wonderful and very elegant – congratulations. David is a born change agent, a leader. I admit that his way of starting a project looks much simpler than Scrum. Kanban might be beneficial in some environments, and, of course, we’ll use these techniques in our Scrum implementations.

But, at their core, Scrum, Kanban, Crystal, ASD and even well done Project Management are very, very similar. Find the Impediments, the Source of Dissatisfaction (very cool wording) or Issues (project management phrase) and act accordingly.

I suggest you do what works for you. Start with Kanban and add some aspects of Scrum, or start with Scrum and add some aspects of Kanban: i.e. The definition of Service Levels for tasks is a very cool way for clustering types of work, or making cycle time more visible. These are helpful additions for a Scrum team.

What I care about: We want to change how people work in our companies. We want to empower them. We want them to be happy at work and give their best because they love what they do.

Instead, more often than not, and even in most Scrum teams, I see people who silently quit their jobs, people who do not act as adults, people who are happy to be told what they have to do today. These are the same people who ask in Scrum trainings “Do we really have to split out tasks? What happens if we’re not able to finish every story? What happens if a Story wasn’t 5 points but 8 points”.

I know a lot of Scrum consultants lead their customers into these questions because it’s the only thing they understand or, unfortunately, they don’t dare to confront the customer with uglier process problems. These consultants give Scrum a bad name because they don’t ask the hard questions. The questions that might embarrass the customer or force them out of their comfort zone. So, to keep their contract, they just don’t ask.

And, yes, sometimes we get fired by our customers! They hate it when we show them the truth. And, no, we aren’t religious about Scrum! We always do what works. We’re very pragmatic! We stick to facts and make things really transparent. That’s because Scrum is simple but hard to do!

About The Author

Boris Gloger is a “Scrum evangelist”. He works in Germany, Austria and Brazil, and is the founder of b!g training and b!g consulting.