Kanban vs. Scrum: Wann sollten Sie was verwenden?

Key elements of scrum include definitions for:

• Teamrollen: Entwicklerteam, Product Owner und Scrum Master.
• Events: Sprint, Sprint Planning, Daily Scrums, Sprint Review, Sprint Retrospektive.
• Artefakte: Product Backlog, Sprint Backlog und (Produkt-)Inkrement.

Ein wesentlicher Vorteil von Scrum besteht darin, dass Teams ihre Teamstruktur, einen konsistenten Arbeitsrhythmus und das zu liefernde Produkt mithilfe des Scrum-Frameworks schnell definieren können. Der 15. Annual State of Agile Survey zufolge ist der Ansatz so beliebt, dass 66% der Teams Scrum verwenden. Wissen über die Implementierung von Scrum ist in der Softwarebranche weit verbreitet.

Kanban vs. Scrum: Die Hauptunterschiede

Kanban und Scrum haben auf der Makroebene viele Gemeinsamkeiten, aber auch entscheidende Unterschiede. Diese Unterschiede können sich ausschlaggebend dafür sein, welchen Ansatz Sie für Ihr Low-Code-Projekt wählen.

Agile Teams, insbesondere solche, die mit Low-Code arbeiten, sollten sich die Merkmale der jeweiligen Ansätze genau ansehen, um zu entscheiden, welcher am besten zu ihren Zielen passt. Wenn Ihr Team derzeit Scrum verwendet, können Sie anhand einer bestimmten Aufgabe evaluieren, wie Sie mehr Kanban integrieren können – z. B. durch neue Metriken –, um Ihren Prozess zu beschleunigen.

Was ist Scrumban?

Scrumban beschreibt einen Ansatz, bei dem Teams Elemente aus Scrum und Kanban kombinieren, um die Teamleistung zu verbessern und den Mehrwert für Kunden zu steigern. Agile Teams, die Scrum-Events, -Rollen und -Artefakte zusammen mit einem physischen oder virtuellen Kanban Board in JIRA oder anderen Tools verwenden, praktizieren bereits Scrumban.

Darüber hinaus verwenden agile Teams häufig Scrum-Techniken wie Sprint Commitments, um die Gesamtarbeit in einem Sprint zu definieren. Gleichzeitig verwalten sie die Arbeit des Teams mit dem Kanban-Konzept zur Begrenzung parallel laufender Aufgaben. Dies kann die Entwicklereffizienz verbessern, da die Kosten für häufige Kontextwechsel reduziert werden.

Scrumban kann eine ausgezeichnete Wahl für agile Teams sein, die die Struktur und Anleitungen zur Organisation des Teams von Scrum mit Kanban-Techniken kombinieren möchten, die bei der Definition der Arbeitsweise helfen.

Wie entscheiden Sie, welcher Ansatz am besten ist?

Ob Sie ein neues Team gründen oder Ihren Ansatz für ein bestehendes Team neu evaluieren: Denken Sie zunächst daran, dass es keinen Ansatz gibt, der für alle Teams optimal ist. Die „eine“ Definition von Agile existiert nicht. Die Definition des besten Ansatzes für Sie und Ihr Team basiert auf Ihren spezifischen Teamzielen, Ihrer Kultur, Ihrem Reifegrad, Ihrer technischen Kompetenz und weiteren Faktoren. Es gibt keinen Endzustand, sondern nur einen Prozess der kontinuierlichen Verbesserung und des Lernens.

Dennoch sollten Teams anhand eines strukturierten Entscheidungsfindungsansatzes evaluieren, ob Scrum, Kanban oder Scrumban am besten zu ihnen passt. Hier sind wichtige Punkte, die Sie beim Evaluieren beachten sollten:

• 1. Informieren Sie sich über alle drei Ansätze. Wenn Sie Scrum verwenden, sollten Sie sich die Zeit nehmen, sich auch über Kanban zu informieren. Online sind zahlreiche hochwertige Inhalte frei verfügbar. Lesen Sie Blogs, führen Sie kostenlose Assessments durch und melden Sie sich für Online- oder Präsenzkurse an.
• 2. Verstehen Sie die Ziele Ihrer Organisation. Viele Teams wählen einen falschen Ansatz, weil sie nicht wissen, wie ihre Arbeit sich in die Gesamtziele ihrer Organisation einfügt. Konzentriert sich Ihre Arbeit auf die Speed-to-Market, die digitale Transformation, die Reduzierung von Applikations-Backlogs oder die technische Unterstützung für eine neue Plattform? Diese Ziele können Ihren Ansatz beeinflussen.
• 3. Bitten Sie um Hilfe von außen. Manchmal ist es schwierig, das eigene Wissen und die eigene Performance objektiv zu betrachten. Externe Hilfe muss nicht bedeuteten, dass Sie Berater oder Coaches einstellen – auch wenn diese sehr hilfreich sein können. Mitarbeiter aus anderen Teams oder aus Ihrem beruflichen Netzwerk können ebenfalls hilfreichen Input liefern.
• 4. Holen Sie Feedback von Ihren Kunden ein. Die Kunden, für die Sie arbeiten – ob intern oder extern –, können Ihnen wichtiges Feedback zum Wert, zur Klarheit und zur Effektivität Ihres aktuellen Prozesses geben. Auch wenn sie keine Experten für den Prozess sind, wissen Kunden doch, wie er funktioniert und sich für sie anfühlt. Wir sollten ihnen zuhören und auf ihr Feedback und ihre Bedürfnisse eingehen.
• 5. Bewerten Sie Ihre Prozessreife. Hat Ihr Team momentan Schwierigkeiten, einen klar definierten Prozess zu bestimmen? Verfügt Ihr Team über einen Prozess, der Ihren Kunden dauerhaft einen Mehrwert bietet? Müssen Sie sich darauf konzentrieren, mit Ihrem aktuellen Prozess eine hohe Performance zu erreichen, bevor Sie etwas Neues ausprobieren?
• 6. Schätzen Sie Ihre technische Reife ein. Wenn Ihr Team noch daran arbeitet, seine Kenntnisse im Umgang mit Ihrem Technologie-Stack zu verbessern, ist ein Ansatz, der Struktur und Konsistenz bietet, möglicherweise die beste Strategie. Sobald Ihr Team mehr Fachwissen mit der verwendeten Technologie entwickelt, können Sie erwägen, zu einem Framework mit mehr Fluidität und Flexibilität überzugehen.
• 7. Ermitteln Sie, wie viel Struktur Ihr Team braucht. Einige Teams bevorzugen mehr Struktur in ihrem Prozess – selbst wenn sie diese nicht unbedingt brauchen. Sprechen Sie mit Ihren Teammitgliedern. Beobachten Sie, wie sie arbeiten und hören Sie ihnen zu. Fühlen sie sich mit mehr oder mit weniger Struktur wohler? Welche Auswirkungen hat Struktur auf ihre Performance? Diese Fragen können Sie bei der Auswahl ihres Ansatzes unterstützen.

Welchen Ansatz sollten Sie für Ihr Low-Code-Projekt verwenden?

Ob Sie mit Low-Code, High-Code oder an einer geschäftsorientierten Aufgabe arbeiten – es gibt nie eine einzige, statische Antwort darauf, welchen agilen Ansatz Sie verwenden sollten. Wenn Sie Ihre Organisations- und Teamanforderungen mithilfe der Fragen im vorherigen Absatz analysiert haben, sollten sich jedoch einige Merkmale, Anforderungen und Muster abzeichnen, die Ihnen dabei helfen, den besten Ansatz zu ermitteln.

Scrum oder Scrumban

Für Teams, die mit mehr Struktur und einem regelmäßigen Rhythmus besser zurechtkommen, kann Scrum oder Scrumban die beste Wahl sein. Scrum ist aus gutem Grund das beliebteste agile Framework. Es ist leicht verständlich und sehr effektiv. Hier sind einige Situationen, in denen Scrum oder Scrumban der beste Ansatz sein könnte:

• Neue Teams. Wenn Sie sich noch am Anfang von Tuckmans Phasen der Teamentwicklung befinden, ist Scrum möglicherweise die beste Wahl. Die klar definierten Rollen in Scrum bieten Teammitgliedern einen guten Leitfaden, um sicherzustellen, dass sie ihre Rolle und ihren Beitrag zum Team genau verstehen.
• Gemischte Teams. Gemischte Teams können eine Kombination aus On- oder Off-Shore-Teams, Mitarbeitern des Unternehmens und Beratern sowie aus Citizen Developern und professionellen Entwicklern umfassen. In entsprechenden Situationen haben Teammitglieder oft unterschiedliche Erfahrungen und Ansichten bezüglich der Entwicklung digitaler Produkte. Hier bietet Scrum eine Struktur und Definition dafür, wie Sie Ihre Produkte erstellen. Insbesondere unterstützt Scrum Gespräche in multikulturellen und funktionsübergreifenden Teams über die Strukturierung und Bereitstellung eines Product Backlogs.
• In größere Ökosysteme integrierte Teams. Wenn Sie Teil einer größeren Organisation sind und für Lieferungen an oder von anderen Entwicklungs- und Geschäftsteams verantwortlich sind, dürfte Scrum ebenfalls die beste Wahl sein. Die feste Sprint-Dauer in Scrum macht die Planung einfacher und vorhersehbarer und erleichtert so die Arbeit mit voneinander abhängigen Teams.
• Mit Scrum vertraute Teams. Einige Teams fühlen sich mit der Vorhersagbarkeit und den Definitionen von Scrum einfach wohler. Scrum ist eine beliebte Wahl, weil viele Menschen es mögen und erfolgreich einsetzen. Wenn Ihr Scrum-Team stabil, leistungsstark und wertschöpfend ist, können Sie nach Wegen für weitere Verbesserungen suchen, statt den Ansatz radikal zu ändern.
• Skalierbarkeit. Skalierbarkeit ist ein kritischer Aspekt für jedes Entwicklungs-Framework. Produktentwicklungsteams entwickeln sich zunehmend zu großen Netzwerken miteinander verbundener Teams. Scrum ist sehr gut geeignet, um die Anzahl der Teams, die für die Entwicklung eines Produkts erforderlich sind, schnell zu vergrößern oder zu verkleinern. Frameworks wie Nexus oder Scrum at Scale bieten hervorragende Modelle für die Skalierung von Scrum – unabhängig davon, ob Sie mit High-Code- oder Low-Code-Plattformen arbeiten.
• Scrum oder Scrumban ist in vielen Situationen der beste Ansatz. Der beste Ansatz besteht oft darin, einen Ausgangspunkt zu definieren, etwas auszuprobieren, dazuzulernen und Anpassungen vorzunehmen.

Kanban

Für Low-Code-Teams, die weniger Struktur und mehr Flexibilität mögen, kann Kanban die bessere Wahl darstellen. Kanban wird zuweilen für eine natürliche Weiterentwicklung von Scrum oder Scrumban gehalten, doch das ist nicht unbedingt zutreffend. Die beste Option ist oft, von Anfang an mit Vollgas in Kanban einzusteigen. In folgenden Situationen ist Kanban der beste Ansatz:

• Geschwindigkeit hat oberste Priorität. In Situationen, in denen Sie ein ausgereiftes Team haben und die Markteinführungszeit der wichtigste Faktor ist (wann ist sie das nicht?), ist Kanban meist die beste Wahl. Kanban fördert die Selbstorganisation und ermöglicht Flexibilität und Lieferung bei gleichzeitiger Minimierung von Formalitäten und Prozesskosten. Teams nutzen quantitative Metriken, um Effizienz und Verbesserung voranzutreiben.
• Ausgereifte technische Teams. Teams mit starker Expertise in der Low-Code-Entwicklung können von der Fokussierung auf Effizienz profitieren, die durch die Begrenzung der laufenden Arbeiten und dem sogenannten Flow durch das System erreicht wird. Da weniger grundlegende technische Fragen zu berücksichtigen sind, können sich Teams z. B. auf eine verstärkte Zusammenarbeit in Echtzeit mit Product Ownern und Endnutzern konzentrieren.
• Reife agile Teams. Wenn Ihr Team ein tiefgreifendes Verständnis der agilen Entwicklung und die Fähigkeit zur beständigen Wertschöpfung demonstriert, kann Kanban dazu beitragen, die Low-Code-Entwicklung weiter zu beschleunigen. So können ausgereifte agile Teams davon profitieren, Release-Termine basierend auf den zu erledigenden Aufgaben zu definieren, statt mit festgelegten Sprints zu arbeiten. Dies kann den Aufwand für die Planung und Kosteneinschätzung reduzieren und das Produkt schneller auf den Markt bringen.
• Leistungsstarke funktionale Teams. Der Erfolg mit Kanban erfordert maximale Flexibilität und Reaktionsfähigkeit. Diese Eigenschaften müssen auch die Teammitglieder aufweisen, die für die Definition von Anforderungen verantwortlich sind. Kanban legt die Product-Owner-Rolle nicht fest. Doch in der Praxis muss jemand in der Lage sein, den Wert für Anwender zu beschreiben und Entscheidungen darüber zu treffen, was erstellt werden soll. Denn Teams ohne einen umfangreichen Backlog qualitativ hochwertiger User Stories und einen Prozess zur Definition neuer Anforderungen, der mit dem Tempo der Low-Code-Entwicklung mithält, können die Schnelligkeitsvorteile von Low-Code nicht maximieren.
• Flexibilität bei der Auswahl von Rhythmus und Dauer. Es ist nicht immer effizient oder praktikabel, Produkte in Sprints mit fester Länge zu entwickeln. Vielleicht haben Sie einzelne oder mehrere Teams, die Applikationskompontenten unterschiedlicher Größe erstellen. Anstatt Elemente so aufzuteilen, dass sie in reguläre Sprints und ihre festgelegten Zeiträume passen, ist es effizienter, sie in Form von unterschiedlich langen Releases zu erstellen. In Fällen, in denen parallele Teams – manchmal mit variierenden Fähigkeiten und Reifegraden – Produktkomponenten unterschiedlicher Größe erstellen, lassen sich die Releasezyklen mit Kanban sinnvoll verwalten.
• Skalierbarkeit. Kanban bietet keine vorgeschriebenen Anleitungen für die Skalierung auf mehrere Teams. Erfahrenen, ausgereiften agilen Teams gibt Kanban jedoch die Flexibilität, die Zusammenarbeit zu definieren, um Geschwindigkeit und Effizienz zu maximieren. Dadurch können Kanban-Teams bei Bedarf schnell und einfach skaliert werden und später in ihrer Größe angepasst werden. Eine wichtiger Aspekt bei der Definition der Kanban-Skalierung ist ein klares Verständnis dafür, wie voneinander abhängige Teams mit Abhängigkeiten umgehen.

Wenn Ihr Team die Fähigkeiten und die Reife zur Implementierung von Kanban hat oder entwickeln kann, kann dies Ihre Entwicklung beschleunigen und die Teameffizienz verbessern. Indem Sie einen Teil der Formalitäten und des Overheads in Ihrem Prozess reduzieren, kann sich das Team stärker auf Design, Entwicklung, Tests und Benutzerfeedback konzentrieren.

Die Bedeutung von kontinuierlichem Lernen

Unabhängig davon, welchen Ansatz Sie für Ihr Low-Code-Entwicklungsteam wählen, sollte Ihr Schwerpunkt auf kontinuierlichem Lernen und kontinuierlichen Verbesserungen liegen. Ihr Team sollte sicherstellen, dass Ihr Prozess der Geschwindigkeit und Qualität der Low-Code-Entwicklung entspricht und deren Potential maximiert.