Scrum: Right. I represent a fundamental mindshift in the way that people do projects.

Kanban: So do I. My mindshift is different to yours; it feels subtler.

Scrum: I doubt that. I help teams collaborate and deliver working software iteratively.

Kanban: As do I. Unlike you, I don’t tie people down to fixed iterations; I let them find their own cadence.

Scrum: You say that like it’s a good thing! What if people aren’t even used to delivering iteratively? How can you possibly stop novices from taking weeks over their increments of code?

Kanban: Well, maybe I don’t work so well with novice teams. A high-discipline team, though, who can keep their flow consistent, will find themselves more responsive with me than they will with you.

Scrum: I help new teams get started. I give them easy, simple approaches that they can follow. You’re all about the maths.

Kanban: Actually, I’m all about the theory of constraints. By limiting work in progress, I make the bottlenecks obvious.

Scrum: I do that by focusing on getting the work through to production. What’s more, I was designed for software. You’re just the bastard offspring of manufacturing; you have no relevance!

Kanban: If I have no relevance, then why do so many people believe that I’m valuable, and fight to defend me?

Scrum: They’re in it for the money…

Kanban: Says the world’s fastest-growing pyramid scheme…

Scrum: I resent that! There are plenty of successful Scrum projects out there. We’re good people; we just want to change the world.

Kanban: I’ll settle for continuous improvement, thanks.

Scrum: We’ve got that too, except we call them Retrospectives.

Kanban: You don’t need to batch up your improvements if everyone is focused on it.

Scrum: There’s nothing to prevent us from continually improving.

Kanban: There’s nothing to prevent us from having retrospectives, if we need them, or in fact from taking on any of your valuable practices. I’m just like you, except that I have sensible limits.

Scrum: You’re not just like me. You don’t even worry about estimates half the time.

Kanban: We estimate in time to deliver, not story points. The business understand this.

Scrum: The business don’t trust my teams; they haven’t delivered successfully for a while. My planning enables them to regain that trust. You can’t even work without it.

Kanban: That’s true. Once we have the trust, though, we don’t need to waste as much time on planning and estimating as you do.

Scrum: How can you call a practice that establishes trust wasteful?

Kanban: You’re right. We value people too, you know – we work well with the Lean principles, and “Respect for People” is one of the pillars.

Scrum: Well, that’s good to know. People are the most important part of the process.

Kanban: We seem to have quite a lot in common. Thinking about it, you’d probably make quite a good stepping-stone for people learning to deliver software iteratively for the first time. I guess they could turn to me later, once the discipline is there.

Scrum: That might work. I know some people have used you in odd ways, and found value. Maybe we should just be friends?

Kanban: Let’s call it a draw.

XP: Let’s not. You may have the planning and estimation sewn up; you may be shifting your constraints and delivering responsively. Neither of you can survive without my technical practices. Get over here!

Liz, Thanks for pointing me here. I appreciate the humor, but I am weary of the discussion.

…you see, I don’t even think of Scrum as a process to develop software. It is a framework for improved mental and spiritual health. In truth, I don’t actually care how fast or slow people build their software. I do care that they build beautiful things, and that may just be relationships as much as websites, or bicycles.

I don’t think it’s Scrum, Tobias. It’s just you, and the way you teach. I want to teach you the joy of Kanban that I know, just to watch the games you come up with and the play that comes out of it. I wish I had half your skill!

1. The trust, once gained, is gained forever. This is rather naive since it can be lost much easier than gained. And you don’t have any chances to gain it back after it has been lost.

2. The trust is a binary thing: either it exists or it doesn’t. This is a bit naive too since trust and its level depend on many circumstances. I trust you in this situation, but not in that; you trust me “to certain extent” (never heard this?); i trust you if my boss trusts you; you trust me on the condition that i prove blah to someone who’s opinion is important to you; etc, and so on. Trust is a combination of many subtle things.

I realize that the conversation is not aimed to address any serious matters and is rather fun, but still…

@Marcelo, I always think of Scrum as being a useful way of informing Kanban, the same way that we might allow design patterns to inform our refactoring – we’re not necessarily coding them in, just allowing them to emerge naturally. From that perspective Scrumban is like MVC; if you’re starting from scratch, it makes so much sense that you wouldn’t do anything else.

Good one. Liked it. But there are plenty of teams out there who still don’t get Agile at all.
Scrum and KanBan would be saying to those teams WTF ?!? Stop using either of us.
Great article! Time estimation part is quality. 😀