Tag Archives: PM

Posts about Product Management

Kanban vs. Scrum

Scrum vs. Kanban: Rezepte für Agiles Arbeiten in der Entwicklerküche

In der Welt der Softwareentwicklung stehen uns zahlreiche Methoden zur Verfügung, um das Chaos des Alltags zu managen und den Weg zu klaren, effizienten Prozessen zu ebnen. Scrum und Kanban sind zwei der prominentesten Vertreter agiler Methoden. Doch welcher Ansatz eignet sich besser für welche Situationen? Diese Frage lässt sich am besten mit einem Blick in die Welt des Alltags – speziell in die Küche – beantworten.

Stellen Sie sich vor, Sie planen ein großes Familienessen. Scrum wäre hierbei vergleichbar mit einem festen Menüplan, der in verschiedenen Gängen aufgeteilt ist, wobei jeder Gang einer Sprint-Phase entspricht. Der Koch – oder das Entwicklungsteam – setzt sich klare Ziele für jeden Gang, mit festen Zeitfenstern und vorher definierten Ergebnissen. Der Vorteil? Jeder weiß genau, was zu tun ist und wann das Ergebnis fertig sein muss. Nach jedem Gang erfolgt eine Prüfung: Ist das Gericht gelungen? Erfüllt es die Erwartungen der Gäste? Basierend auf dem Feedback können Anpassungen für die nächsten Gänge vorgenommen werden. Diese strukturierte Herangehensweise hilft dabei, komplexe Projekte in überschaubare Abschnitte zu gliedern und regelmäßig Ergebnisse zu liefern.

Kanban dagegen ist wie das Zubereiten einer großen Platte mit Fingerfood. Es gibt keine festgelegten Gänge, sondern die Speisen werden kontinuierlich vorbereitet und serviert, sobald sie fertig sind. Die “Kanban-Küche” ist durch ihre Flexibilität charakterisiert: Kochen (oder Entwickeln) erfolgt nach Bedarf und Kapazität. Die Kochenden ziehen neue Aufgaben – oder Zutaten – heran, sobald Platz auf der Arbeitsfläche frei wird. Diese Methode eignet sich besonders gut in Umgebungen, wo Anforderungen und Prioritäten schnell wechseln können und eine ständige Anpassung erforderlich ist. Das Kanban-Board, ähnlich einer Einkaufsliste am Kühlschrank, gibt dabei stets Auskunft über den Status der einzelnen Aufgaben.

Der wesentliche Unterschied zwischen Scrum und Kanban liegt in der Flexibilität und Strukturierung der Arbeitsprozesse. Während Scrum mit festen Sprints und klar definierten Zielen punktet, überzeugt Kanban durch seine Anpassungsfähigkeit und kontinuierlichen Durchfluss von Arbeit. In unserer Küchenmetapher entspricht Scrum dem sorgfältigen Planen eines mehrgängigen Dinners, während Kanban das spontane Zubereiten von Gerichten ermöglicht, die sofort serviert werden können.

Abschließend lässt sich sagen, dass die Wahl zwischen Scrum und Kanban von den spezifischen Anforderungen des Projekts, der Teamdynamik und den Unternehmenszielen abhängt. Während Scrum für Projekte geeignet ist, die eine hohe Struktur und klar definierte Phasen erfordern, bietet Kanban Flexibilität für Teams, die auf schnelle Änderungen reagieren müssen. Beide Methoden haben ihre Berechtigung und können sogar in einem hybriden Ansatz kombiniert werden, um die Vorteile beider Welten zu nutzen.

Diese Betrachtung zeigt, dass sowohl Scrum als auch Kanban wertvolle Werkzeuge in der agilen Toolbox sind, die, richtig eingesetzt, zu einer effizienteren und zufriedenstellenderen Projektrealisierung führen können. Wie in der Küche kommt es auch hier auf das richtige Rezept und die passenden Zutaten an.

Der Trugschluss der Roadmap-Planung: Eine Lektion aus dem Garten

In der agilen Welt der Softwareentwicklung gelten Roadmaps oft als heiliger Gral der Projektplanung. Sie verheißen Orientierung und Sicherheit auf dem Weg durch den Dschungel der Entwicklungsaufgaben. Doch betrachten wir sie zu Unrecht als Allheilmittel der Planung? Lassen Sie uns diese Frage mit einer Geschichte aus einem ganz anderen Bereich – dem Gartenbau – beleuchten.

Stellen Sie sich vor, Sie träumen von einem idyllischen Gartenhaus in Ihrem Garten, das auf einem soliden Fundament ruhen soll. Sie beginnen enthusiastisch mit der Planung: Ein Kubikmeter großes Loch muss gegraben werden. Dann ein Fundament gegossen und schließlich das Haus aufgestellt werden. Die Roadmap dafür ist schnell erstellt – ein scheinbar einfacher Plan für einen klaren Output. Maximal 2 Wochen.

Doch schon der erste Anruf bei den Technikern lässt das Übel hochkommen. Der lokale Erdbauer weiß, dass in der Gegend oft Granit im Boden vorkommt. Sprengungen sollten auf die Roadmap. Auch der Zugang zum Grundstück stellt sich als schwierig heraus. Nur ein kleiner Bagger kann zum Einsatz kommen. Auch der Abtransport muss in kleinen Fuhren, mit einer Schubkarre erfolgen. Schotter und Beton müssen geliefert und mühevoll an die schwer zugängliche Position gebracht werden. Die rechtliche Prüfung ergibt, dass es das Grundstück einer WEG gehört und ein Beschluss gefasst werden muss. Der erste Umlaufbeschluss scheitert. Eine Eigentümerversammlung muss einberufen werden. Das Bodengutachten ergibt eine erhöhte Bleibelastung. Das Erdreich muss teuer entsorgt werden. Die Komplexität des Projekts wächst exponentiell. Sie benötigen Sprengstoff, müssen Sicherheitsvorkehrungen treffen, die Genehmigung der Wohneigentümergemeinschaft einholen, und der Zugang für den Bagger wird zur logistischen Herausforderung. Die einst so klare Roadmap erweitert sich um zahlreiche unvorhergesehene Aufgaben. Die neue Roadmap zeigt 8-12 Monate.

In diesem Moment der Frustration kommt die Erleuchtung: War das Ziel wirklich der Bau eines Gartenhauses? Oder ging es schlicht darum, einen geeigneten Platz für die Unterbringung der Gartenmöbel zu finden? Plötzlich erscheint der bisher übersehene Kellerraum als die optimale Lösung. Der neue Plan ist schnell gefasst: Entrümpeln, Möbel einräumen, fertig. Dauer 2 Tage.

Diese scherzhafte Geschichte illustriert nicht nur die Tücken der Planung in der physischen Welt, sondern wirft auch ein Licht auf ein häufiges Missverständnis in der Softwareentwicklung. Roadmaps werden oft fälschlicherweise als Planungswerkzeug betrachtet. In Wahrheit sind sie jedoch nichts anderes als eine Visualisierung einer bereits abgeschlossenen Planung. Sie sollten die Ergebnisse eines umfassenden Planungsprozesses darstellen, in dem Ziele definiert, Optionen bewertet und Entscheidungen getroffen wurden.

Der wahre Wert von Roadmaps liegt in ihrer Fähigkeit, einen Überblick über die geplanten Schritte zu geben und so das Team sowie Stakeholder über den bevorstehenden Kurs zu informieren. Doch ohne die zugrundeliegende, tiefgreifende Planungsarbeit, die durch Methoden wie OKR (Objectives and Key Results) und Scrum angeleitet wird, sind sie nicht mehr als eine hübsche Zeichnung ohne Fundament.

OKR und Scrum zwingen uns, zuerst das “Was” und das “Warum” zu klären, bevor wir uns dem “Wie” und “Wann” zuwenden. Sie ermutigen Teams, über den gewünschten Outcome nachzudenken und sich nicht von vornherein auf einen spezifischen Output zu versteifen. In unserem Gartenbeispiel wäre das Ziel nicht das Graben eines Lochs gewesen, sondern die effektive Unterbringung der Gartenmöbel – ein Ziel, das, einmal richtig verstanden, auf ganz andere, überraschend einfache Weise erreicht werden konnte.

Abschließend lässt sich sagen, dass Roadmaps eine wichtige Rolle in der Kommunikation und Visualisierung von Plänen spielen, aber sie dürfen nicht mit dem Planungsprozess selbst verwechselt werden. Die wahre Kunst der Planung in der Softwareentwicklung – wie im Leben – liegt darin, flexibel zu bleiben, Ziele klar zu definieren und offen für unerwartete Lösungen zu sein, die uns letztendlich zum gewünschten Ergebnis führen. So können wir sicherstellen, dass wir nicht nur bauen, was wir geplant haben, sondern planen, was wir wirklich benötigen.