Fazit

Bei der Wahl zwischen Kanban und Scrum ist es in jedem Fall wichtig zu verstehen, mit welchem Hauptaugenmerk die beiden Ansätze entwickelt wurden, und zu prüfen, ob dieser Zweck mit den eigenen Absichten und Zielen zusammenpasst. Es wäre falsch, Scrum einzuführen, damit die Entwickler schneller arbeiten – denn der Fokus von Scrum liegt auf der Effektivität des Produkts, nicht auf der Effi­zienz der Personen. Ebenso wenig sinnvoll ist Scrum in einem stabilen Umfeld, in dem langfristige Planungen problemlos möglich und keine Änderungen zu erwarten sind.

In diesem Fall wäre der Nutzen im Vergleich zum Aufwand zu gering. Schwierig wird es, wenn wegen äusserer Umstände das ­Scrum-Team und der Prozess nicht richtig aufgesetzt werden, weil etwa viele externe Parteien beteiligt sind und die Aufgaben durch mehrere Übergaben nur zeitversetzt und in längeren, schlecht planbaren Abschnitten bearbeitet werden können. Sinnvolle Sprintziele und -umfänge zu bestimmen, wäre dann kaum möglich. In einem solchen Fall ist Kanban die bessere Wahl. Eventuell lassen sich auch beide kombinieren.

Festzuhalten bleibt, dass eine Entscheidung für eine Arbeitsweise nach Scrum bedeutet, dass Sie die Vorgehensweise im Ganzen implementieren sollten, um tatsächlich von ihr zu profitieren. Führen Sie die Rollen ein und bauen Sie den Prozess mithilfe der fünf beschriebenen Scrum- Ereignisse vollständig auf.

Entscheiden Sie sich aber für Kanban, können Sie schlanker und mit einzelnen Elementen starten. Um­gekehrt würde – gerade in Teams ohne Erfahrung mit diesen Methoden – weder ein Scrum-Prozess gut und wie beabsichtigt funktionieren, der nur auf ausgewählten Teilen des Frameworks beruht, noch wäre Kanban ein Erfolgs­garant, nur weil Sie mit sieben Regelterminen und den zwei Kanban-Rollen beginnen. Hier ist weniger mehr.