Scrum oder Kanban – ein Glaubenskrieg?

Die Diskussion um die passende Methode artet rasch in einen ideologischen Glaubenskrieg aus: Jeder glaubt die eine richtige Vorgehensweise zu kennen, überschätzt diese und ignoriert die Vorzüge der anderen. Dabei lohnt sich etwas Zeit zu reservieren und die beiden Methoden Scrum und Kanban einem Vergleich zu unterziehen, um die Stärken und Schwächen beider Prozessmethoden zu erkennen. Und es wird deutlich: Scrum und Kanban haben zunächst einiges gemeinsam:

  • Beide Methoden werden überwiegend in der Softwareentwicklung eingesetzt.
  • Beide haben das Ziel die Produktivität zu steigern.
  • Beide sagen Leerlauf und Doppelgleisigkeiten den Kampf an.

Eine erste Übersicht über Unterschiede gibt hier Wikipedia vor:

Kanban Scrum
Iterationen sind optional. Es kann unterschiedliche Takte für Planung, Releases und Prozessverbesserung geben. Iterationen mit gleichen Längen sind vorgeschrieben.
Commitments sind optional. Das Team vereinbart, eine bestimmte Menge an Arbeit während der nächsten Iteration zu erledigen.
Die Durchlaufzeit (Cycle Time) wird als Basis-Metrik für Planung und Prozessverbesserung verwendet. Die Team-Geschwindigkeit (Velocity) ist die Basis-Metrik für Planung und Prozessverbesserung.
Cross-funktionale Teams sind optional. Experten-Teams sind erlaubt. Cross-funktionale Teams sind vorgeschrieben.
Keine Vorschrift bezüglich der Größe von Anforderungen. Anforderungen müssen so aufgeteilt werden, dass sie sich innerhalb einer Iteration erledigen lassen.
WiP wird direkt limitiert. WiP wird indirekt limitiert (durch die Menge an Anforderungen, die in einen Sprint „passt“).
Schätzungen sind optional. Schätzungen sind vorgeschrieben.
Neue Anforderungen können zu jedem Zeitpunkt an das Team gegeben werden, falls Kapazitäten frei sind. Während eines laufenden Sprints können keine neuen Anforderungen an das Team gegeben werden.
Gibt keine Rollen vor. Schreibt drei Rollen vor (Product Owner, Scrum Master, Team).
Ein Kanban-Board kann von mehreren Teams und/oder Einzelpersonen geteilt werden. Ein Scrum-Board gehört einem einzelnen Team.
Ein Kanban-Board wird kontinuierlich weitergepflegt. Das Scrum-Board wird nach jedem Sprint gelöscht und neu aufgesetzt.
Priorisierung ist optional. Schreibt vor, dass alle Einträge im Backlog priorisiert sein müssen.

Unsere Meinung:

Wir haben mit verschiedenen Entwicklern aus unserem Netzwerk gesprochen. Dabei haben wir ein doch sehr interessante Feststellung gemacht. Einer der wesentlichen Vorteile von Kanban ist die integrierte Validierung. Einfach formuliert: Man möchte mit der Validierung immer den Nachweis führen, dass das System (Modul, etc.) das leistet, was es leisten soll.  Eine Konsequente Softwarequalitätssicherung garantiert dem Endkunden mitunter den erhofften Erfolg.

Links zum Thema: