Entscheidungsprozess zur Kanban-Methode

​​

​

Eingang

Was wird benötigt, um die Entscheidung zur Scrum-Methode sauber treffen zu können?

​

• Ergebnisse aus der Stacey-Analyse

• Werte aus den Projektsettings (POM-Analyse)

  • Planbarkeit & Unsicherheit (Anforderungsdynamik, Bekanntheitsgrad der Lösungswege)

  • Komplexität (Technische- und organisatorische Komplexität)

  • Wertschöpfungslogik (Liefermodell, Zielmarkt)

  • Organisationsreife (agile Reife, Selbstorganisation)

  • Projektanwendung (Softwareentwicklung, Transformationsprojekt ...)

Die Projektsettings sollten definiert werden, bevor das Projekt überhaupt in die Projektentscheidung geht. Zu den entscheidenden Parametern gehören Planbarkeit und Unsicherheit, die Komplexität des Projekts, der Projektkontext, der Anwendungsfall, die Projektgröße, die Organisationskultur, die Organisationsreife sowie die Wertschöpfungslogik.

​​

📝 Studienabgleich: "Scrum oder Kanban - welche Methode in welchem Kontext?"

​

Entscheidung

Wie wird die Entscheidung getroffen?

​

Folgende Parameter können als Orientierung für die Entscheidung zugunsten von Scrum herangezogen werden und sollten insgesamt in eine ähnliche Richtung zeigen. Die Kombination dieser Parameter ist jedoch keine Garantie für eine eindeutige Entscheidung, sondern dient lediglich als Hinweis bzw. Richtungsvorgabe.

​

Stacey-Analyse

Das Projekt befindet sich im "komplexen Bereich"

​

Projektsettings (PMO-Analyse)

• Planbarkeit & Unsicherheit

  • Anforderungen sind dynamisch, bleibenaber stabil und planbar für einen Zeitraum von zwei bis vier Wochen. Lösungswege sind unklar (geht einher mit den Ergebnissen der Stacey-Analyse)

• Komplexität:

  • klare Organisationsstrukturen: wird vorgegeben von Scrum

  • Technische/Inhaltliche Komplexität: Scrum ist das Werkzeug für technisch anspruchsvolle und komplexe Projekte (unbekannte APIs, neue Architekturen, KI-Integration).

• Wertschöpfungslogik

  • Die Wertschöpfung orientiert sich an einer Roadmap, die sich einer Vision orientiert.

• Organisationsreife

  • Scrum gibt eine Struktur vor. Das heißt, Scrum bietet vor allem weniger reifen Teams bezüglich Agilität eine gute Orientierung.

• Projektanwendung

  • Scrum ist gut geeignet für Produktentwicklungen (Softwareentwicklung und ggf. Hardwareentwicklung). Hier muss die Entwicklung geplant werden bei gleichzeitig dynamischen Umfeld.

  • Scrum ist weniger geeignet in Infrastruktur- und Bauprojekten, da hier hohe regularische und stabile Anforderungen herrschen.

​​

📝 Artikel: In welchem Rahmen kann ich Scrum an die Organisation anpassen?

📝 Artikel: Scrum vs. Manifest - wie agil ist Scrum?

📝 Artikel: Wann verwende ich Scrum und wann nicht?

​​

​

Ergebnis

Was konkret beinhaltet das Ergebnis der Entscheidung?

​

Das Ergebnis ist ein vordefiniertes Rahmenwerk, das als Einstieg und strukturierende Grundlage für das Projekt dient. Im Vergleich zu Kanban erfordert Scrum, dass sich die bestehende Organisationsstruktur an das Rahmenwerk anpasst (Achtung: nicht die Umsetzung der eigentlichen Umsetzung) – insbesondere in Bezug auf Rollen, Ereignisse und Artefakte. Dadurch ist die Einführungshürde bei Scrum höher und sollte entsprechend sorgfältig vorbereitet und begleitet werden.

​

• Grundprinzipien

  • Empirische Prozesskontrolle

    • Transparenz

    • Überprüfung

    • Anpassung

• Rollen

  • Product Owner​

  • Scrum Master

  • Entwicklungsteam

• Scrum-Events

  • Sprint​

  • Sprint Planning

  • Daily Scrum

  • Sprint Review

  • Sprint Retrospective

• Scrum-Artefakte

  • Product Backlog​

  • Sprint Backlog

  • Inkrement

​

Anwendung

Wie setze ich das Ergebnis nun ein?

​

Das Ergebnis der Entscheidung für die Scrum-Methode sollte zunächst dokumentiert werden. Darüber hinaus ist es wichtig zu prüfen, ob die erforderliche Expertise bei den beteiligten Projektmitgliedern für die Anwendung von Scrum vorhanden ist. Bestehen hier Wissenslücken, sollte aktiv gegengesteuert werden – beispielsweise durch Trainings in der Projektvorbereitung oder durch direkten Support während der Projektdurchführung.

Anschließend muss Scrum in der Projektdurchführung konsequent angewendet werden.

​

Kompetenz

Welche Kompetenzen werden zur Entscheidung der Kanban-Methode benötigt?

​​

Für eine fundierte Entscheidung zur Anwendung der Scrum-Methode sind vor allem drei Kompetenzbereiche erforderlich.

Erstens braucht es methodische Kenntnisse zu Scrum, inklusive Grundprinzipien, Rollen, Events und Artefakte, um die Effektivität von Scrum ausspielen zu können.

Zweitens ist ein gutes Verständnis des Projektkontexts notwendig, zum Beispiel hinsichtlich Unsicherheiten, Wertschöpfungslogik und Komplexität, da Scrum seinen Nutzen nur in passenden Rahmenbedingungen entfaltet.

Drittens sind Kenntnisse über Organisationskultur und Organisationsreife wichtig, weil Kanban besonders von Transparenz, Selbstorganisation und einer kontinuierlichen Lernkultur abhängig ist.

​

​

​

Informationen zur Kanban-Methode

​

Einordnung POM

Scrum im Projektmanagement ist ein agil orientiertes Framework, das auf den Prinzipien des Agilen Manifests von 2001 basiert und einen iterativen, teamzentrierten Ansatz zur Steuerung von Projekten verfolgt.

Im Rahmen des Project Operation Models (POM) ist Scrum Bestandteil der Projektdefinitionsphase, in der entschieden wird, ob dieses Vorgehensmodell für das jeweilige Projekt geeignet ist. Der Fokus liegt in dieser Phase also nicht auf der praktischen Umsetzung, sondern auf der bewussten Festlegung, ob das Projekt künftig nach Scrum gesteuert wird oder nicht.

​​

​

Warum Scrum?

Scrum zeichnet sich durch seine hohe Flexibilität, Transparenz und Anpassungsfähigkeit an veränderliche Anforderungen aus. Es ist klar strukturiert durch definierte Rollen (Product Owner, Scrum Master, Entwicklungsteam), Events (z. B. Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) und Artefakte (Product Backlog, Sprint Backlog, Increment). Diese Struktur fördert eine kontinuierliche Verbesserung, kurze Feedbackzyklen und eine enge Einbindung der Stakeholder.

​​​​

​

Studienergebnisse im Überblick

Die analysierten Studien zeigen übereinstimmend, dass Scrum in der Praxis selten unverändert eingesetzt wird. Stattdessen passen Organisationen Scrum systematisch an ihre bestehenden Organisations-, Governance- und Entscheidungsstrukturen an. Dieses Tailoring folgt wiederkehrenden Mustern und ist keine Ausnahme, sondern der Regelfall.

Besonders häufig betroffen sind Rollen, Events und Artefakte: Scrum Master übernehmen oft klassische Projektmanagement-Aufgaben, Product Owner verfügen nicht immer über volle Entscheidungshoheit, und Scrum-Events werden verkürzt oder in Richtung Reporting und formale Abnahme verschoben. Artefakte werden häufig um klassische Dokumentation, Roadmaps und Meilensteinlogiken ergänzt, um Steuerbarkeit und Transparenz sicherzustellen.

Vergleichende Studien zu Scrum und Kanban zeigen zudem, dass Scrum seine Stärken vor allem in planbaren Projekt- und Produktkontexten entfaltet: bei stabileren 2 - 4 Wochen-Anforderungen, klaren Zielsetzungen, hoher Stakeholder-Einbindung sowie erhöhten Qualitäts- und Governance-Anforderungen. In kontinuierlichen Arbeitsumgebungen ist Scrum hingegen weniger geeignet.

Insgesamt positionieren die Studien Scrum weniger als strikt einzuhaltendes Regelwerk, sondern als strukturierten Referenzrahmen, dessen Wirksamkeit stark vom organisationalen Kontext abhängt und der in der Praxis häufig hybrid interpretiert und eingesetzt wird.

​

📝 Studienabgleich: Scrum oder Kanban - welche Methode in welchem Kontext?

📝 Studie: Tailoring Choices Made in Scrum Projects: A Systematic Literature Review

​

​

Interviewergebnisse im Überblick

Im Interview wird deutlich, dass Scrum in der Praxis primär als strukturgebender Ordnungsrahmen genutzt wird, nicht als strikt umzzusetzende Methode. Scrum bietet vielen Organisationen zunächst Orientierung durch klare Rollen, Events und Artefakte – insbesondere dort, wo wenig agile Erfahrung vorhanden ist.

Gleichzeitig wird betont, dass Scrum häufig an bestehende Management-, Governance- und Entscheidungslogiken angepasst wird. Rollen werden umdefiniert, Events funktional umgedeutet und Entscheidungsbefugnisse eingeschränkt, um Anschlussfähigkeit an Organisation und Führung sicherzustellen. Dadurch entsteht oft ein Spannungsfeld zwischen formaler Scrum-Struktur und tatsächlicher agiler Arbeitsweise.

Das Interview unterstreicht zudem, dass Scrum nicht für jeden Kontext geeignet ist: In stark dynamischen, kontinuierlichen oder service-orientierten Umgebungen stößt Scrum schnell an Grenzen, während es in planbaren Produkt- und Projektkontexten seine Stärken ausspielen kann.

​

🎤 Interview: "Scrum oder Kanban - Studienanalyse und Praxiseinordnung mit Felix Huschka" - Felix Huschka

​

​

Wechselwirkung zwischen Methode und Organisationskultur

Scrum ist nicht nur ein Vorgehensrahmen, sondern wirkt direkt auf bestehende Organisationskulturen ein – und wird gleichzeitig stark von ihnen geprägt. Die folgenden Kulturdimensionen zeigen, wo Scrum kulturelle Voraussetzungen benötigt, wo es Spannungen erzeugt und wo es Kultur sichtbar macht.

​

• Werte- und Sinnkultur: Scrum basiert auf Transparenz, Fokus, Commitment, Offenheit und Respekt. In Organisationen mit klar geteiltem Sinnverständnis und hoher intrinsischer Motivation kann Scrum diese Werte verstärken. Fehlt ein dieses gemeinsamme Wertebild, wird Scrum häufig auf Prozesse reduziert und verliert seine kulturelle Wirkung.

• Führungs- und Machtkultur: Scrum setzt auf dienende Führung und dezentrale Entscheidungsfindung. In hierarchisch geprägten Machtkulturen entstehen Spannungen, die sich häufig in eingeschränkter Product-Owner-Autorität oder kontrollorientierten Scrum-Master-Rollen zeigen.

• Zusammenarbeits- und Beziehungskultur: Selbstorganisation und interdisziplinäre Teamarbeit sind zentrale Annahmen von Scrum. In kooperativen Kulturen fördert Scrum Vertrauen und gemeinsame Verantwortung. In siloorientierten Organisationen wird Zusammenarbeit oft formalisiert, ohne dass sich Beziehungen tatsächlich verändern.

• Kommunikations- und Informationskultur: Scrum lebt von offener, direkter Kommunikation und hoher Transparenz. Wo Informationen bisher selektiv oder hierarchisch gesteuert wurden, erzeugt Scrum Reibung. Häufig werden Events dann zu Reporting-Formaten umfunktioniert, um bestehende Kommunikationsmuster aufrechtzuerhalten.

• Arbeits- und Strukturkultur: Scrum folgt klaren Rollen, Ereignissen und Zyklen. In strukturaffinen Organisationen schafft dies Orientierung und Stabilität. In sehr stark formalisierten Umfeldern wird Scrum jedoch oft überreguliert, während in sehr freien Kulturen die notwendige Disziplin fehlt, um den Rahmen wirksam zu nutzen.

• Leistungs- und Erfolgskultur: Scrum misst Erfolg primär am Wertbeitrag von Inkrementen. In output- oder kennzahlengetriebenen Leistungskulturen wird Scrum häufig um zusätzliche Kontroll- und Reportingmechanismen ergänzt. Dadurch verschiebt sich der Fokus von Wertschöpfung und Lernen hin zu kennzahlgetriebenen Prozessen (vs. nutzerwertgetriebene Prozesse).

• Lern- und Innovationskultur: Inspect & Adapt ist der Kern von Scrum. In lernorientierten Kulturen entfalten Retrospektiven und Reviews ihre Wirkung. In fehleraversen Organisationen werden diese Formate häufig oberflächlich genutzt, wodurch Scrum seine Innovationskraft einbüßt.

• Sicherheits- und Risikokultur: Scrum setzt auf frühes Feedback und kontrolliertes Lernen mit Unsicherheit. In risikoscheuen Kulturen wird diese Unsicherheit oft durch Vorabplanung, Freigaben und Meilensteine kompensiert. Scrum wird dann stärker als Absicherungs- denn als Lerninstrument eingesetzt.

​

​

​Zu beachten!

Fehler bei der Entscheidung entstehen häufig, wenn Scrum nur aus Trendgründen gewählt oder ohne organisatorische und kulturelle Voraussetzungen eingeführt wird. Auch ein Missverständnis der agilen Prinzipien, etwa durch zu starke Hierarchien oder fehlende Selbstorganisation im Team, kann die Wirksamkeit des Frameworks erheblich beeinträchtigen. Eine fundierte und realistische Bewertung in der Definitionsphase ist daher entscheidend für den späteren Projekterfolg.