Pragmatisches Projektmanagement

Herzlich Willkommen zu einer neuen Ausgabe vom Pragmatischen Projektmanagement, deiner Quelle für Informationen und Inspiration zu alltäglichen Herausforderungen im Management von Softwareentwicklungsprojekten. Dich erwarten Einblicke, Erfahrungen und unsere individuellen Ansichten zu Methoden, Werkzeugen, Vorgehensweisen und Fragen aus dem Leben eines Projektmanagers.

Gern diskutieren wir mit Euch auf LinkedIn zu Euren Erfahrungen und Ansichten.

Kanban vs. Scrum – welches Modell passt zu deinem Team?

Wenn du meinen letzten Artikel gelesen hast, kennst du bereits die Grundlagen von Scrum: Feste Rollen, klar definierte Events wie Sprint Planning oder Retrospektive und ein zyklisches Vorgehen in Timeboxen. Scrum ist wie ein Framework mit Geländer – es gibt dir Struktur, Disziplin und regelmäßig Raum zur Verbesserung.

Doch was ist, wenn dein Team nicht in solchen festen Takten arbeitet? Wenn Aufgaben unvorhersehbar kommen oder ständiger Fluss statt Sprint wichtiger ist? Dann lohnt sich ein Blick auf Kanban.

Was ist Kanban?

Kanban ist kein Framework, sondern ein flussorientiertes Modell zur Steuerung von Arbeit. Bevor Kanban in der Softwareentwicklung Einzug gehalten hat, wurde es in der Automobilindustrie geboren – genauer gesagt im Toyota Production System (TPS). Dort war es ein zentrales Werkzeug, um Produktion effizienter, gleichmäßiger und belastbarer zu machen. Ziel war nicht einfach nur „schneller“ zu arbeiten, sondern intelligent zu produzieren – mit möglichst wenig Verschwendung, Überlastung und Chaos.

Drei Begriffe bilden dabei das Herzstück des TPS:

• Muda steht für Verschwendung – also alles, was keinen Wert für den Kunden schafft: unnötige Arbeit, Wartezeiten, Doppelungen.
• Mura beschreibt Unregelmäßigkeit – schwankende Auslastung, schlecht abgestimmte Prozesse, fehlende Standards.
• Muri meint Überlastung – also das permanente Arbeiten am Limit, das Menschen und Maschinen ermüdet und Fehler wahrscheinlicher macht.

Toyota erkannte früh: Wenn du Muda, Mura und Muri nicht aktiv bekämpfst, entstehen systematisch Fehler, Frust und Ineffizienz. Kanban wurde genau dafür entwickelt: als einfaches, aber wirkungsvolles Mittel, um Arbeit zu steuern und sichtbar zu machen, Engpässe früh zu erkennen – und den Fluss der Arbeit zu verbessern.

In der modernen Softwareentwicklung funktioniert Kanban nicht mehr mit physischen Karten auf einem Werkstatt-Board, sondern meist digital – in Tools wie Jira, Azure DevOps oder Trello. Doch die Prinzipien sind gleich geblieben: Arbeit wird in einzelne Aufgaben (Tickets, User Stories, Features) zerlegt, diese wandern über ein Board von „To Do“ über „In Progress“ zu „Done“.

Das Besondere: Es gibt keine festen Rollen, keine festen Sprints, keine festen Zyklen oder Events wie bei Scrum. Stattdessen liegt der Fokus auf einem kontinuierlichen Fluss (Flow) und Work in Progress (WIP) wird begrenzt, um den Fokus zu wahren. Die Teams ziehen Aufgaben nur dann nach, wenn Kapazität frei ist – nicht, weil ein Plan es sagt. Neue Aufgaben werden dann „gezogen“, wenn ein Platz frei wird – daher auch das Prinzip „Pull statt Push“. So wird sichtbar, wo es stockt, wo Überlastung droht und wo Prozesse verbessert werden können. Kanban fördert einen kontinuierlichen Fluss – ganz im Sinne von Toyota.

Und was ist mit Expedite Lanes? – Der Notfallknopf in Kanban

Kanban hat keine Sprints – aber es hat ein mächtiges Werkzeug für echte Ausnahmefälle: Die Expedite Lane. Sie ist gedacht für Aufgaben, bei denen wirklich jede Stunde zählt. Beispiel: Eine kritische Sicherheitslücke im Produkt, ein drohender Vertragsbruch oder ein Produktionsausfall beim Kunden. Dafür ist sie da – nicht für alles, was dringend klingt.

In der Realität landet dort aber oft etwas ganz anderes: Alles, was „irgendein Chef will“. Ein spontaner Kundenwunsch? Zack, Expedite Lane. Die Idee aus dem letzten Management-Meeting? Natürlich ganz wichtig. Wenn du ehrlich hinschaust, könntest du sie auch „Boss Pleasing Lane“ nennen. Klingt zynisch – aber frag dein Team mal, wie oft wirklich echte Notfälle dort landen.

Expedite Lanes sind wie ein roter Not-Aus-Knopf. Du willst ihn nicht ständig drücken, sonst stumpft das ganze System ab. Plötzlich wird jede kleine Anfrage zur Chefsache, jeder Mini-Bugfix zur Priorität. Und was passiert mit deinem Flow? Er kollabiert. WIP-Grenzen? Interessieren keinen mehr. Fokus? Gibt’s nicht mehr. Dann brennt vielleicht nicht das Haus – sondern deine ganze Organisation.

Expedite Lane oder Ausrede?

Manchmal ist die Expedite Lane einfach nur eine bequeme Ausrede. Eine Möglichkeit, sich um echte Priorisierung zu drücken. Statt sich im Team ehrlich zu fragen: „Was ist wirklich wichtig?“, wird die Karte einfach durchgeschleust – weil’s schneller geht, weil keiner widerspricht, weil „oben“ es so wollte. Aber das ist kein agiles Arbeiten – das ist Krisenmodus im Dauerbetrieb.

Wenn du also merkst, dass euer Team ständig Dinge „mal eben schnell“ reinschiebt, frag dich:
Ist das wirklich ein Notfall – oder nur schlechte Planung?
Wird hier ein Problem gelöst – oder einfach Verantwortung umgangen?

Ein Tipp: Tracke, wie oft die Expedite Lane benutzt wird. Und besprecht regelmäßig im Team: Was war der tatsächliche Impact? Wäre wirklich etwas Schlimmes passiert, wenn die Aufgabe nicht sofort erledigt worden wäre? So schärfst du gemeinsam den Blick für echte Notfälle – und entlarvst die Ausreden.

Scrum oder Kanban – wann passt was?

Beide Modelle haben ihre Stärken – und ihre Grenzen. Die Frage ist: Was braucht dein Team?

Scrum passt besser, wenn:

• Ihr ein neues Produkt entwickelt, bei dem noch nicht alles klar ist.
• Ihr strukturierte Prozesse braucht und euch an regelmäßigen Planungs- und Reflexionszyklen orientieren wollt.
• Das Team sich verbindlich committen soll, was in einem Sprint erreicht werden kann.
• Es klare Verantwortlichkeiten geben soll (z. B. ein dedizierter Product Owner).

Kanban passt besser, wenn:

• Die Aufgaben eher operativ oder reaktiv sind (z. B. Support, Wartung, Betrieb).
• Ihr mit wechselnden Prioritäten oder spontanen Aufgaben umgehen müsst.
• Ihr bereits bestehende Prozesse verbessern wollt, ohne gleich alles umzubauen.
• Euer Team autonom arbeitet, aber mit wachsendem Druck auf Effizienz.

Ein gutes Beispiel: Ein Entwicklungsteam arbeitet nach Scrum – aber das Support-Team, das Kundenanfragen bearbeitet, nutzt Kanban. Unterschiedliche Anforderungen, unterschiedliche Methoden – beide arbeiten agil, aber anders.

Regeln und Metriken in Kanban

Kanban ist flexibel – aber nicht regellos. Im Gegenteil: Ein gut funktionierendes Kanban-System lebt von klaren Vereinbarungen, die das Team gemeinsam trifft und regelmäßig überprüft. Eine zentrale Regel ist die Begrenzung des Work in Progress (WIP). Sie verhindert, dass zu viele Aufgaben gleichzeitig begonnen werden – denn Multitasking killt Fokus, verlangsamt den Fluss und erhöht das Risiko für Fehler. WIP-Limits sind dabei keine Einschränkung, sondern ein Schutzmechanismus für nachhaltiges Arbeiten.

Um die eigene Arbeitsweise zu analysieren und zu verbessern, nutzt Kanban einfache, aber effektive Metriken. Besonders wichtig ist die Lead Time – also die Zeitspanne von „Aufgabe startet“ bis „Aufgabe ist erledigt“. Je stabiler und kürzer diese ist, desto verlässlicher ist dein System. Eine weitere wichtige Visualisierung ist das Cumulative Flow Diagram (CFD): Es zeigt auf einen Blick, wie viele Aufgaben sich in welcher Phase befinden – und ob es irgendwo einen Stau gibt. Auch Durchsatz (wie viele Aufgaben pro Zeitraum abgeschlossen werden) und Aging Charts (wie lange Aufgaben schon in Bearbeitung sind) helfen, Engpässe zu erkennen.

Der Clou: Du brauchst keine komplexe Analyse, um Verbesserungen zu erkennen. Oft reicht schon ein Blick aufs Board: Hängen zu viele Aufgaben in einer Spalte? Dann ist hier dein Bottleneck. Kanban bringt Probleme nicht automatisch in Ordnung – aber es bringt sie ans Licht. Und das ist der erste Schritt zur Veränderung.

Meetings und Serviceklassen: Struktur im Fluss

Wenn du mit Metriken wie Lead Time und Cumulative Flow Diagram arbeitest, erkennst du Engpässe – aber was dann? Auch wenn Kanban keine festen Sprint-Zyklen kennt, braucht es klare Strukturen, um den Arbeitsfluss zu steuern. Dazu gehört das regelmäßige Replenishment Meeting, in dem das Team gemeinsam entscheidet, welche Aufgaben aus dem Backlog als Nächstes in den aktiven Arbeitsfluss aufgenommen werden. Es ist der Moment, in dem bewusst gepullt wird – basierend auf Prioritäten, Kapazitäten und Reife der Aufgaben. Zusätzlich helfen Serviceklassen, Aufgaben nach Dringlichkeit und Art zu unterscheiden. So wird zum Beispiel klar, welche Tickets Standard sind, welche einen festen Liefertermin haben oder ob es sich um ein seltenes, echtes „Expedite“-Ticket handelt. Das bringt Ordnung und Fokus – ohne die Flexibilität von Kanban zu verlieren. Häufig wird zur Besserung Visualisierung von Serviceklassen auf Swimlanes zurückgegriffen. Swimlanes sind horizontale Trennlinien auf dem Board, die dir z. B. zeigen, welche Aufgaben vom Backend-Team, vom Support oder von der Produktentwicklung bearbeitet werden. Sie helfen dabei, Komplexität zu reduzieren – vor allem, wenn mehrere Streams parallel laufen. Aber Achtung: Swimlanes sind wie Fahrspuren auf der Autobahn: gut, wenn du weißt, wo du hinwillst – aber sie bringen nichts, wenn jeder im Stau steht.

Die Relevanz des Backlogs für funktionierendes Kanban

Was gern vergessen wird: Auch das Backlog gehört zum System – und zwar nicht als unbegrenzter Parkplatz für jede Idee, sondern als bewusst gesteuerter Zulauf. Beim Umgang mit dem Backlog gilt es daher, ein paar wesentliche Aspekte zu berücksichtigen.

1. Visualisiere auch das Backlog: Das Backlog ist kein schwarzes Loch. Auch hier gilt: Visualisierung schafft Klarheit. Gliedere z. B. in: „Ready for Planning“, „Idea Funnel“ und „Wird evaluiert“. So sehen alle, was da drin ist – und vor allem: was nicht reif für’s Ziehen ist.
2. Limitiere auch den Backlog (indirekt): Nein, du brauchst kein hartes WIP-Limit auf dem Backlog. Aber wWenn dein Backlog tausend Tickets enthält, dann ist das kein Plan, das ist Verwirrung. Halte den Funnel kurz und gepflegt.
3. Pflege-Rhythmus etablieren: Ein Kanban-System lebt nicht von alleine. Wenn du das Backlog nie pflegst, versumpft es. Ein Fester Termin zur Backlog-Grooming-Session ist Pflicht (auch in Kanban!).

Was ist Scrumban?

Vielleicht merkst du: Es gibt kein Schwarz oder Weiß. Viele Teams starten mit Scrum – und merken irgendwann, dass sie mehr Flexibilität brauchen. Andere beginnen mit Kanban – und übernehmen dann Teile von Scrum, weil sie mehr Struktur wollen.

Scrumban ist genau das: Ein hybrides Modell, das das Beste aus beiden Welten vereint.

Zum Beispiel:

• Das Team arbeitet mit einem Kanban-Board, aber führt regelmäßige Retrospektiven durch.
• Es gibt Daily Standups, aber keine festen Sprints.
• Es gibt ein Sprint Planning – aber keine Timebox, sondern ein kontinuierlicher Fluss von Stories.

Scrumban eignet sich besonders gut für Teams, die zwischen Projekt und Betrieb stehen – z. B. DevOps, Maintenance oder Plattform-Teams.

Praktische Hinweise zur Auswahl

Wenn du unsicher bist, welches Modell zu euch passt, frag dich:

• Wie stabil sind unsere Anforderungen? Je klarer das Ziel, desto mehr spricht für Scrum.
• Wie oft ändert sich die Priorität von Aufgaben? Häufige Änderungen → eher Kanban.
• Wie gut kann sich das Team an feste Rhythmen halten? Scrum braucht Disziplin und Fokus.
• Brauchen wir Orientierung oder Flexibilität? Scrum bietet Struktur, Kanban bietet Flow.

Fazit

Scrum gibt dir Struktur und Rituale. Kanban gibt dir Fluss und Fokus. Und Scrumban? Holt dich genau da ab, wo du gerade stehst. Wichtig ist: Es geht nicht darum, Methoden „richtig“ oder „komplett“ zu machen – sondern darum, dass sie euch helfen, besser zu arbeiten. Du kannst auch klein starten. Probiere mit einem kleinen Team oder Projekt aus, wie es sich anfühlt. Du musst nicht gleich dein ganzes Unternehmen umstellen. Und denk immer dran: Agil heißt nicht, ein Framework zu befolgen – sondern Veränderung aktiv zu gestalten.

Was einen Project Manager (PM) vom Product Owner (PO) unterscheidet, schauen wir uns im nächsten Teil unserer Serie an. Bis dahin freue ich mich auf Eure Reaktionen auf LinkedIn.

Photo by Jakub Żerdzicki on Unsplash, Font 08 Underground by Johan Waldenström