Kanban oder Scrum, Design Thinking, V-Modell oder Wasserfallmodell? Was ist für mein Softwarenentwicklungsprojekt die richtige Wahl, welche Methode eignet sich am besten? Wir schauen uns in diesem Artikel an, wo die wesentlichen Unterschiede und wo die Stärken der beiden Methoden Scrum und Kanban liegen.
Kanban ist zunächst nicht per se eine agile Methode, denn das Prinzip der Kontinuierlichen Verbesserung lässt sich auf jegliche Arbeitsprozesse in einem Unternehmen anwenden (auch auf den Prozess des Jahresabschlusses in der Finanzabteilung), Kanban betont ja, dass diese Methode immer dort startet, wo ein Arbeitsprozess gerade steht, um dann mit inkrementellen Verbesserungsschritten die Performance oder die Qualität zu verbessern. In der Praxis der Softwareentwicklung jedoch wird Kanban häufig in agil strukturierten Projekten eingesetzt, darum wird es gerne als Agile Methode bezeichnet.
Zentral für Kanban sind die Visualisierung eines Arbeitsprozesses und der Aufgaben. Ebenso zentral ist die Verankerung von Kommunikationsroutinen rund um eine Softwareentwicklungsprojekt (z.B. Queue Replenishment Meeting oder das Retrospective Meeting).
Auch Scrum setzt auf eine Verbesserung der Kommunikation und die Selbstorganisation des Teams. Damit wird eine der Hauptursachen von Fehlschlägen/Verzögerungen/Qualitätsproblemen in IT Projekten adressiert, nämlich mangelhafte soziale Kommunikation (die anderen: Machtkämpfe zwischen Linienmanagement, Topmanagement und IT; unzureichende Anforderungsspezifizierungen). Im Gegensatz zu Kanban ist Scrum aber deutlich strikter, das Regelwerk ist deutlich umfassender und strukturiert ein Projekt mehr. Scrum erfordert auch mehr Disziplin. Trotz all des Gesagten gilt, dass dennoch Scrum in sehr unterschiedlicher Weise in Unternehmen umgesetzt, teilweise finden sich auch innerhalb des gleichen Unternehmens abweichende Scrum Regelwerke wieder.
Nun haben wir einige Unterschiede herausgearbeitet; die Frage bleibt offen, für welche Art von Projekten eignet sich dieses, für welche Art von Projekten jene Methode mehr?
In einem Artikel vergangenen Jahres (Die richtige Projektmanagementmethode) hatte ich als Orientierungsrahmen ein Koordinatensystem für Typen von Projekten vorgestellt, das entlang folgender Dimensionen strukturiert ist; dies kommt aus dem Innovations-/Changemanagement: „Die Erste Dimension ist stabil/instabil: Ein stabiles System verhält sich vorhersagbar. Instabil meint, das System macht Sprünge; die Kenntnis der Vergangenheit erlaubt mir nicht, die Zukunft vorherzusagen. Die zweite Dimension ist einfach/komplex. Im einfachen System gibt es nur wenige Elemente mit wenigen Beziehungen untereinander. Ein komplexes System besteht aus vielen Elementen mit hochgradiger Vernetzung.“
Diesmal möchte ich die Stacey-Matrix heranziehen, der ähnliche Überlegungen zugrunde liegen, dies aber noch praktischer für Softwareentwicklungsprojekte in ein Koordinatensystem überführt. Die nachfolgende Darstellung dürfte weitgehend selbsterklärend sein:
Abbildung: Stacey-Matrix
Für einfache Projekte (also: Anforderungen sind klar, die zu verwendenden Technologien sind klar) wird typischerweise die Anwendung der Wasserfall-Methode empfohlen.
Für komplizierte Projekte eignet sich Kanban; die Anforderungen sind noch vergleichsweise übersichtlich, es geht bei diesem Projekttyp nicht so sehr darum, ein nicht-planbares Projekt in den Griff zu bekommen und den damit verbundenen Kreativitätsprozess zu bänden. Es geht vielmehr darum, einen bestehenden Prozess effizient zu gestalten.
Komplexe Projekte lassen sich nicht mehr planen. Der Fokus wird darum auf Iterationen gelegt, es wird nur wenig Zeit auf Planung verwendet. Scrum eignet sich sehr gut für diesen Kontext schnelllebiger Anforderungen, für einen Feedbackprozess mit hoher Veränderungsdynamik (vor allem bei den Anforderungen), heißt: bei unklaren Vorstellungen der Auftraggeber. Scrum ist auch ein gutes Instrument, um den Kreativitätsprozess zu strukturieren, schnelle Prototypen zu entwickeln und damit Entscheidungsgrundlagen zu schaffen. Das ist im dynamischen Marktumfeld unter dem Motto Fail fast. Fail cheap ein wichtiges Kriterium.
Für chaotische Projekte mag Scrum vereinzelt noch hilfreich sein; häufiger zum Einsatz kommen hier aber Methoden wie Startup Thinking, Design Thinking.
Abschließend sei erwähnt: In der Praxis sind häufig auch Mischformen von Scrum und Kanban zu beobachten.
