Wie man Agilität in Projekten schafft (mit Dimitar Karaivanov von Kanbanize)

Lesen Sie das Transkript:

Wir testen aktuell eine automatische Transkription unserer Podcasts mittels einer Software. Bitte entschuldigen Sie etwaige Tippfehler – der Bot arbeitet nicht immer fehlerfrei.

Ben Aston:

Lean, Scrum, Scrumban, XP, SAFe, DaD, LeSS, DSDM, Kaizen, Kanban. Kommt Ihnen das bekannt vor? Nun, das sind nur einige der Frameworks, die es für agiles Arbeiten gibt. Doch welches ist das beste und warum? Bleiben Sie dran, um zu erfahren, wie Sie mehr Agilität in Ihre Projekte bringen können und welchen Nutzen ein Kanban-Ansatz mitbringt.

Danke, dass Sie eingeschaltet haben. Ich bin Ben Aston, Gründer des Digital Project Manager. Willkommen beim DPM-Podcast. Wir haben es uns zur Aufgabe gemacht, Projektmanager:innen dabei zu helfen, erfolgreich zu sein und Menschen, die Projekte steuern, bei der Verbesserung ihrer Arbeit zu unterstützen. Wir helfen Ihnen, Ihre Projektmanagement-Skills aufs nächste Level zu bringen. Schauen Sie auf thedigitalprojectmanager.com vorbei, um mehr über unsere Trainings und Ressourcen zu erfahren. Dieser Podcast wird gesponsert von Clarizen, dem Marktführer im Bereich Enterprise Project und Portfolio Management Software. Besuchen Sie clarizen.com, um mehr zu erfahren.

Heute habe ich Dimitar Karaivanov zu Gast. Dimitar ist Ingenieur, der zum CEO wurde, und Mitgründer von Kanbanize. Er denkt lean, ist Kanban-Praktiker und hat einen Hintergrund in Softwareentwicklung und Prozessverbesserung. Er hat mehrere Bücher geschrieben, darunter "Lean Software Development With Kanban" und "How Can Portfolio Kanban Benefit Your Business?" Sie merken schon – Kanban ist seine Leidenschaft. Hallo Dimitar, schön, dass du heute bei uns bist.

Dimitar Karaivanov:

Danke, Ben, für die Einladung. Es ist mir eine Freude, mich mit dir und deinem Publikum zu unterhalten. Ich freue mich auf den Podcast.

Ben Aston:

Es ist wirklich toll, dich hier zu haben. Du bist ja offensichtlich extrem begeistert von Kanban und hast ein ganzes Produkt rund um Kanbanize entwickelt. Aber als CEO – was bedeutet diese Rolle für dich? Wie sieht ein typischer Tag als CEO und Mitgründer von Kanbanize aus?

Dimitar Karaivanov:

Als CEO eines Unternehmens, besonders in einer späteren Startup-Phase, trägt man viele Hüte. Ich bin häufig im Gespräch mit Kunden, da ich häufig auch Aufgaben des Produktmanagements übernehme.

Ben Aston:

Verstehe.

Dimitar Karaivanov:

Dann spreche ich mit dem Engineering-Team, um das Feedback unserer Kunden weiterzugeben. Ich beschäftige mich mit Vertrieb auf Unternehmensebene und natürlich arbeite ich an der Strategie, wenn es meine Zeit zulässt, denn das ist ein wichtiger Teil meiner Aufgaben als CEO. Und übrigens, Strategie kann man auch mit Kanban umsetzen – vielleicht finden wir später dafür noch Zeit.

Ben Aston:

Unbedingt! Aber bevor wir tiefer einsteigen, interessiert mich dein Werdegang. Wie kamst du dazu, Software für Projektmanagement zu entwickeln?

Dimitar Karaivanov:

Meistens entsteht das aus eigenem Bedarf. Ich war Change Agent bei einem großen deutschen Unternehmen. Wir gingen von Wasserfall-Prozessen hin zu agilen Prozessen und haben etwa 500 Personen aus einer alten Projektwelt in Scrum überführt. Damals war Scrum die normale Praxis für neue agile Entwicklungen. Wir schulten alle in Scrum, hatten zahlreiche agile Teams, aber entdeckten, dass zwar die Teams einigermaßen stabil liefern konnten, jedoch das Management, wo die großen Arbeitspakete lagen (Features, Epics etc.), chaotisch blieb. Uns fehlten die Tools, um Arbeit sowohl auf Team- als auch auf Managementebene zu steuern. Daraus entstand Kanbanize – mit dem Ziel, agiles Arbeiten innerhalb der ganzen Organisation zu skalieren.

Ben Aston:

Spannend. Sicherlich gab es bei der Gründung eines Tools für ProjektmanagerInnen Inspiration von anderen Tools, die du mochtest – oder auch nicht mochtest. Was war der Auslöser für die Entwicklung von Kanbanize?

Dimitar Karaivanov:

Wir nutzten damals JIRA im Unternehmen – das ist der große 300-Pfund-Godzilla, wo auch immer man hingeht. Viele praktische Dinge sind darin enthalten, aber das Kanban-Element, besonders vor acht, neun Jahren, war eher dürftig. Während dort gute Konzepte exisitieren, kam die Inspiration zur Skalierung von Kanban und agilem Arbeiten tatsächlich mehr von einem physischen Kanban-Board. In Kanbanize wollten wir nachbilden, wie man Arbeit auf einem physischen Board visualisiert, ergänzt um die Vorteile der Digitalisierung: Verbindungen mit mehreren Teams und aggregierte Daten für das Management, um fundierte Entscheidungen zu treffen. Es sind also eigentlich zwei Inspirationsquellen: JIRA und physische Kanban-Boards.

Ben Aston:

Du hast ein eigenes Projektmanagement-Tool gebaut – aber welche anderen Tools integriert Kanbanize, oder nutzt du nebenbei noch andere Tools? Gibt es Tools, die du gerne nutzt oder entdeckt hast?

Dimitar Karaivanov:

Ja, ich will nicht Microsoft Teams unerwähnt lassen – das ist bestimmt die am schnellsten wachsende Anwendung der Internetgeschichte. Wir nutzen Kanbanize natürlich, aber ich verbringe auch viel Zeit in Teams, besonders jetzt im Homeoffice. Ein weiteres Tool, das ich viel nutze, ist Flow-e (flow-e.com) – überraschenderweise ist das auch von uns. Es ist quasi Kanbanize, aber für Ihr E-Mail-Postfach: ein Visualisierungs-Layer für Outlook, der daraus ein Kanban-Board macht, um E-Mails und Konversationen im Kanban-Stil zu managen. Für mich ist das ein Lebensretter. Ich würde ohne dieses Tool vermutlich untergehen. Es ist kostenlos, probieren Sie es unbedingt aus!

Ben Aston:

Das sehe ich mir an. Momentan habe ich 1189 ungelesene E-Mails. Wenn ich also noch nicht geantwortet habe, landet das in meiner „Zu lesen“-Spalte.

Dimitar Karaivanov:

Genau daher kam uns die Idee für Flow-e – weil es zu schmerzhaft war, all die Informationsströme zu koordinieren. Ich empfehle es weiter.

Ben Aston:

Super! Lass uns über Kanbanize sprechen. Du bist CEO, das war dein „Baby“ zusammen mit dem Gründungsteam. Kanbanize ist ein digitales Kanban-Board, das bessere Vorhersagbarkeit, Analysen, Daten sowie Regeln bietet. Für wen ist euer Tool perfekt geeignet? Wer nutzt Kanbanize typischerweise?

Dimitar Karaivanov:

Wir sind speziell auf Ingenieursunternehmen ausgerichtet – das kann Softwareentwicklung sein, IT/DevOps oder auch Fertigung, Bauwesen etc. Viele unserer erfolgreichen Kunden kommen aus dem Engineering-Bereich, aber auch Marketing- oder Betriebsteams (z.B. Banken, Versicherungen) profitieren davon. Es gibt im Grunde zwei Anwendungsfälle: Das Projektmanagement (Engineering) und das Service Management (Banken, Versicherer). Das sind unsere typischen Ideal-KundInnen. Und was das Projektmanagement angeht: Ich erläutere das gerne näher, wenn Sie möchten – besonders das Spezifische an Kanbanize.

Ben Aston:

Sehr gerne!

Dimitar Karaivanov:

Aus meiner Erfahrung planen Projektmanager Projekte, schätzen diese ab, und dann werden daraus Aufgaben gemacht, die meist in einem anderen System landen. Wir haben dann einen perfekten Plan – etwa in PowerPoint oder Microsoft Project – aber die eigentliche Arbeit läuft in JIRA oder anderswo.

Ben Aston:

Genau.

Dimitar Karaivanov:

Wie bekommt man dann die echten Statusinformationen? Man muss Leute nach dem Status fragen.

Ben Aston:

Genau.

Dimitar Karaivanov:

Und dann nervt man die Leute: Wie weit sind wir hier? Was ist der Fertigstellungsgrad dieser Aufgabe? Wir dachten, das kann man doch mit Kanban, speziell Kanbanize, besser lösen – indem man Planung und Ausführung miteinander verbindet. In Kanbanize gibt es eine spezielle Ebene zum Planen und eine zum Ausführen der Arbeit – diese sind miteinander verbunden und geben Feedback weiter. Wenn das Team etwas Neues anpackt, wird die Info automatisch an das Management weitergegeben, wo der Plan lebt. Wenn zum Beispiel klar wird, dass der Plan zu scheitern droht, erhält der Projektmanager direkt eine Benachrichtigung und ist sofort informiert – statt eine Woche auf den Status zu warten. Das ist ziemlich cool.

Ben Aston:

Also gibt’s eine Benachrichtigung: Ihr Projekt läuft Gefahr zu scheitern. Eine höfliche Warnung, die niemand mag. Aber das ist sehr hilfreich. Entscheidend dabei sind die Menschen im Team. Ein Tool ist immer nur so gut wie die Leute, die es pflegen. Wo du ansetzt, ist, dass die Leute Aufgaben aktualisieren. Aber meiner Erfahrung nach (auch mit JIRA): Viele aktualisieren Aufgaben und Stati gar nicht. Wie habt ihr Kanbanize gestaltet, dass dieser Echtzeit-Überblick entsteht und die Mitarbeitenden motiviert werden, Stati zu pflegen?

Dimitar Karaivanov:

Das ist wirklich ein Problem. Die Lösung: Vertrauen auf die Kanban-Methode. Kanban beinhaltet ein umfassendes Wissenssystem, nicht nur ein Whiteboard an der Wand. Es gibt das Kanban Maturity Model mit über 150 Praktiken. Wer Interesse hat: Schauen Sie sich das Kanban Maturity Model (KMM) an! Teil davon sind sogenannte Feedback-Schleifen – also regelmäßige Meetings: täglich, wöchentlich, monatlich oder quartalsweise. Da gibt es etwa das tägliche Kanban-Meeting – das Team stellt sich vor das Board (digital oder physisch auf dem Bildschirm), geht die in Arbeit befindlichen Karten gemeinsam durch und spricht über deren Fortschritt. Es geht nicht darum, was die einzelne Person gestern gemacht hat, sondern um die Arbeit an sich. Was ist mit dieser Karte passiert, passt sie noch in die Spalte? Mindestens einmal am Tag werden die Karten in die richtige Spalte geschoben – so stellen wir Aktualität sicher.

Ben Aston:

Dieser Fokus auf die Arbeit, nicht die einzelne Person, ist spannend. Viele kennen Standups, wo einfach nur erzählt wird, was man (vermeintlich) gestern gemacht hat, ohne größeren Erkenntnisgewinn. Die Konzentration auf Arbeitsfortschritt anstelle reiner Beschäftigung ist wertvoll. Wie unterscheidet sich Kanbanize deiner Meinung nach von anderen Tools wie JIRA oder Trello?

Dimitar Karaivanov:

Ich greife noch einmal das KMM auf: Das Kanban Maturity Model beschreibt sechs Reifegrade mit je eigenen Praktiken – von einfach bis sehr komplex. Tools wie Trello bringen Sie maximal auf Reifegrad 1 oder 2, da wichtige Kanban-Funktionen fehlen. Beispielsweise gibt es in Trello keine Begrenzungen für Work-in-Progress (WIP) – und mit Plugins sind diese eben nicht konsistent. In Kanbanize kann man WIP-Limits über mehrere Spalten, Swimlanes oder Boards hinweg und nach Personen einstellen – das ist ein großer Unterschied.

Auch bei den Metriken fehlen bei einfachen Tools wichtige Kennzahlen wie Durchlaufzeiten, Blockierungen, Monte-Carlo-Simulationen etc., meist nur als Add-On verfügbar. Das ist teuer und funktioniert oft nicht sinnvoll. Kanbanize bildet komplexe Kanban-Szenarien ab und ermöglicht es, das über eine ganze Organisation zu skalieren – so dass auch das Management gesteuert informieren kann. Trello eignet sich vor allem für einzelne Teams. JIRA kann mehr, ist aber eher auf Scrum ausgelegt. In JIRA basiert die Prognose auf Velocity – also Schätz-/Bauchgefühl des Teams. Im Kanban-Ansatz prognostizieren wir auf Basis tatsächlicher Durchsatzwerte. Das kann wie ein kleiner Unterschied wirken, bei vielen Teams ist das aber riesig – denn Punkte-Bewertungen sind meist nicht zwischen Teams vergleichbar. Kanban basiert auf realen Daten – das ist ein fundamentaler und wichtiger Unterschied.

Ben Aston:

Lass uns Kanban ganz grundsätzlich betrachten: Dimitar sprach über Prinzipien wie Erhöhung des Durchsatzes durch Begrenzung paralleler Arbeiten. Ziel von Work-in-Progress-Limits ist es, Fokus zu schaffen – statt Vieles gleichzeitig, lieber zielgerichtet abschließen. Gerade bei Agenturen mit mehreren KundInnen kennen viele das Problem von zu vielen parallelen Projekten und kollidierenden Deadlines. Kanban möchte den Durchsatz durch Begrenzung optimieren – weniger Dinge gleichzeitig, mehr Fertiggestelltes am Ende.

Dimitar Karaivanov:

Genau, das ist richtig. Aber ein zu niedriges WIP-Limit kann auch den Durchsatz behindern. Es braucht ein feines Gleichgewicht zwischen möglichst schnell fertig und bestmöglichem Durchsatz. Viele fragen: Was ist das beste WIP-Limit? Die ehrliche Antwort: Wir wissen es nicht – es hängt vom jeweiligen Kontext ab. Man muss experimentieren, die Zahlen jede Woche anschauen und das Optimum herausfinden.

Ben Aston:

Spannend. Wo steuert Kanbanize in den nächsten Jahren hin? Wie sieht der Fahrplan aus – sagen wir: Wo steht ihr in fünf bis zehn Jahren?

Dimitar Karaivanov:

Fünf bis zehn Jahre sind in meinem Kopf eine Ewigkeit…

Ben Aston:

OK, sagen wir sechs Wochen.

Dimitar Karaivanov:

(lacht) Sechs Wochen kann ich klarer beantworten: Unser Ziel ist, den Projektmanager immer mehr von administrativen Entscheidungen zu entlasten. Anstatt dass ein Mensch alles berechnet, was-wäre-wenn-Szenarien durchdenkt, wollen wir diese Fragen automatisch beantworten. Projektmanager sollen sich mehr auf die Wertschöpfung konzentrieren können und weniger auf Kontrolle. Wir möchten Überwachung und Benachrichtigungen komplett durch statistische Algorithmen und vielleicht KI automatisieren. Ich werfe das Stichwort KI vorsichtig in den Raum – oft sind klassische Algorithmen wie Monte-Carlo-Simulationen noch präziser als existierende KI. Aber die Richtung bleibt klar: Den Projektmanager entlasten, Monitoring automatisieren, damit Zeit für wichtigere Aufgaben bleibt.

Ben Aston:

Die meisten Zuhörer:innen sind vermutlich Projekt- oder Produktmanager. Wie siehst du bei der Evolution von Tools wie Kanbanize die Entwicklung der Rolle des Projektmanagers? Du sprichst von Wertschöpfung und Verbindung zum Produktmanagement – wie verändert sich die Rolle?

Dimitar Karaivanov:

Ich denke, Projektmanager sollten sich immer mehr als Schnittstelle sehen, die nicht einfach nur Daten weiterleitet (Kommunikation, Fristen etc.), sondern diese auch anreichert, etwa indem man kritisch hinterfragt: Ist es das Richtige, was wir bauen? Sind die Bedürfnissen der Kund:innen wirklich erfasst? Projektmanager sollten die Persönlichkeiten sein, die Fragen stellen und das System weiterentwickeln. Viele beschränken sich leider aktuell auf das reine Weiterleiten von Anforderungen. Das ist zwar wichtig, aber auch nur teilweise wertvoll. Mit mehr Zeit (und weniger Monitoring-Aufwand durch Tools) bleibt mehr Fokus auf die tatsächliche Lösung von Problemen und echte Wertschöpfung.

Ben Aston:

Lass uns noch kurz auf den PM-Tool-Landschaft im Allgemeinen schauen: Wie entwickelt sich der Markt, besonders mit großen Playern wie JIRA und neuen wie ClickUp? Wohin geht die Reise?

Dimitar Karaivanov:

Stimmt – es gibt eine Unzahl von Tools insbesondere für die Steuerung kleiner Teams. Wer da einsteigen will, braucht viel Optimismus! Unsere Strategie mit Kanbanize ist, nicht „nur“ ein Team-Tool zu sein, sondern ein agiles Portfolio-Management zu ermöglichen. Unsere Funktionalität dafür ist teils schon da, aber der Aufbau ist ein riesiges Unterfangen und dauert insgesamt sicher zehn Jahre. Im Portfolio-Management dominieren „Godzillas“, die Scrum-basiert sind – aber ich denke, die Zukunft liegt in der Etablierung echter Informationsströme durch alle Ebenen, von den Teams bis zum Management und zurück. Die Tool-Landschaft konsolidiert sich rund um Organisationen-skalierende Ansätze. Einzelteam-Tools wird es immer geben, aber der große Marktgewinn liegt dort, wo Agilität organisationsweit gelingt.

Ben Aston:

Lass uns über Business Agility sprechen. Du hast einen Artikel dazu geschrieben: Kanban Powered Business Agility. Was bedeutet aus deiner Sicht Business Agility?

Dimitar Karaivanov:

Business Agility bedeutet für mich die Fähigkeit, durch schnelle Lernzyklen und Experimente den Markt zu befriedigen und diese Erkenntnisse konsequent umzusetzen. Es ist kein Framework, sondern die Fähigkeit, schnell zu lernen, als Organisation dazuzulernen und dieses Wissen in Mehrwert für Kund:innen zu verwandeln. Das ist für mich Business Agility.

Ben Aston:

Du bist ein großer Befürworter von Kanban und hast Kanbanize danach benannt. Weshalb bist du überzeugt, dass gerade Kanban besonders gut für Business Agility geeignet ist? Wofür hältst du Kanban für besonders angebracht und wofür (vielleicht) weniger?

Dimitar Karaivanov:

Das ist eine gute Frage. Es gibt ein zentrales Prinzip von Kanban: Starte dort, wo du gerade bist, und entwickle dich dann experimentell weiter. Kein anderes agile System ermöglicht das so niederschwellig. Meist ist ja ein großer Sprung oder Umbau erforderlich. Kanban hingegen sagt: Starte mit dem, was ist, visualisiere die Lage auf einem Board und analysiere: Was könnten wir besser machen? Ich finde, das ist ein menschlicher Ansatz – und reduziert den Stress im Unternehmen (jedenfalls anfangs). Es bleibt eine Evolution. Und wenn Menschen daran wachsen können, wird Kanban als Ansatz akzeptiert. So ist zumindest meine Erfahrung.

Deshalb bin ich überzeugt, dass Kanban besser ist als andere Ansätze: Es ist menschengerecht. Werden die Prinzipien richtig umgesetzt, verringert Kanban die Überlastung und hilft, dass Arbeit besser läuft, dass sich die Menschen auf wenige Dinge fokussieren und weniger zwischen Aufgaben springen müssen. Leider glauben viele, Kanban sei nur ein Whiteboard. Das ist ein Irrglaube! Es gibt zahlreiche Bücher, z.B. über das Kanban Maturity Model. Ich ermutige alle, sich damit zu befassen – Kanban umfasst viel mehr als nur ein physisches Board.

Ben Aston:

Andererseits: Der Vorteil ist, dass viele zumindest eine grobe Vorstellung von Kanban haben. Man kann Kanban sehr einfach („Visualisiere Arbeit – Limitiere parallele Aufgaben – Fokussiere“) erklären, während Scrum durch Backlog, Sprints, viele Zeremonien und so weiter aufwendiger vermittelt werden muss. Kanban ist ein leichtgewichtiger Einstieg.

Dimitar Karaivanov:

Ich denke auch, das ist viel vernünftiger. Es ist arrogant, zu behaupten, man könne irgendwo hingehen und direkt vorschreiben, was zu tun ist – dabei ist jedes Unternehmen, das am Markt erfolgreich ist, schon auf einem guten Weg. Wer dann alles umkrempelt, zerstört womöglich die vorhandene Erfahrung. Ein besserer Ansatz ist: Hinschauen, verstehen, dann gemeinsam verändern – das gilt überall im Leben.

Ben Aston:

Du sprichst in deinem Artikel von Workflow-Optimierung. Wie passiert diese in der Praxis? Wie kann man konkret den Arbeitsfluss verbessern?

Dimitar Karaivanov:

Typisch ist das Arbeiten mit sogenannten Queues und WIP-Limits. Unerfahrene Teams merken schnell, wie sich Karten an bestimmten Stellen auf dem Board stauen. Das deutet auf Engpässe hin: Entweder arbeitet eine Station schneller als andere, oder die nachfolgende ist zu langsam. Dann gilt es zu untersuchen: Wieso stockt es? Möglich, dass neue Spalten wie „Bereit zur Überprüfung“ eingeführt werden. Man beobachtet dann, ob sich Karten dort stapeln. Falls ja: Ist die Review der Engpass. Dann hilft ein WIP-Limit – sobald das Limit im Review erreicht ist, produziert die vorige Station nichts Neues, sondern hilft dem Engpass. Das iteriert man ständig: Prüfung, Workflow-Optimierung, Limit setzen, erneut prüfen.

Ben Aston:

Das Ziel ist, Engpässe zu reduzieren – also Kartenstau vermeiden, sodass tatsächlich Wert entsteht, wenn Aufgaben abgeschlossen werden, und nicht nur vorrücken auf dem Board.

Dimitar Karaivanov:

Genau. Stetige Überprüfung ist wichtig – etwa anhand der Zykluszeit (Cycle Time), also der Zeit, die eine Karte bis zur Fertigstellung braucht. Wenn die länger wird, staut sich Arbeit – dann sollte man Workflow und Limits prüfen und angepasst weiterarbeiten.

Ben Aston:

Ein weiteres deiner Tipps war: „Hippos zu Hippos machen“ – gemeint ist: Die Meinung der am höchsten bezahlten Person (englisch „HiPPO: Highest Paid Person's Opinion“) zugunsten der objektiv wahrscheinlich besten Option zurückstellen – sprich: Entscheidungen datengetrieben fällen. Wie gehst du als CEO damit um, wenn im Team unterschiedliche Ansichten aufeinandertreffen?

Dimitar Karaivanov:

Das ist nicht einfach. Ich habe als Geschäftsführer viele Fehler gemacht, bis ich zum Lernen kam. Wenn jemand im Team Entscheidungen aus dem Bauch heraus trifft, frage ich sofort nach: Wie bist du zu diesem Schluss gekommen, hast du Daten herangezogen? Menschen wollen recht haben – gerade Führungskräfte. Wenn ich also eine Meinung habe, ist meine meist die dominante. Aber sobald Daten vorliegen, ändert sich das Gespräch. Ich habe oft gesagt: „Wir alle haben Meinungen – wenn ihr eure Meinung mit meiner messt, gewinnt meine immer. Also besorgt lieber Daten.“ Es ist ein langer Prozess, der Zeit und Beharrlichkeit braucht. Aber je öfter man es macht, desto mehr etabliert es sich. Also: Beharrlichkeit, immer wieder nach Daten fragen – selbst wenn man Ausnahmen macht, bricht sonst alles schnell wieder ein.

Ben Aston:

Zum Abschluss: Dein Artikel dreht sich um Business Agility und Kanban als Motor dafür. Für jemanden, der in Kanban einsteigen will – was ist ein guter Anfang? Du hast gesagt: Kanban akzeptiert dort zu starten, wo man ist. Was sind die ersten Schritte Richtung mehr Agilität durch Kanban?

Dimitar Karaivanov:

Ich finde drei Dinge entscheidend. Erstens: Visualisiere deine Arbeit! Das kann jede:r machen, ohne Expert:in zu sein. Einfaches physisches Board, Haftnotizen, Spalten – fertig. Wer Veränderung sucht oder Probleme lösen will: Das Visualisieren ist Schritt eins.

Zweitens: Begrenze Work in Progress – auch wenn erst mal hoch (z.B. 100 parallele Projekte), aber zumindest macht man sich die Situation bewusst. Dann das Limit schrittweise reduzieren, bis es besser funktioniert.

Drittens (wenn nicht schon am Anfang): Gute Kanban-Schulung! Wir sind Partner der Kanban University, der Zertifizierungsstelle hinter Kanban. Es gibt weltweit Hunderte Trainer:innen. So eine Schulung kann für eine gesamte Firma teuer sein, aber zumindest Schlüsselpersonen sollten sie machen.

Ben Aston:

Sehr wertvoll – vor allem der Hinweis, zunächst den aktuellen Prozess zu visualisieren und die Schmerzpunkte sichtbar zu machen. Oft zeigt sich dabei, dass verschiedene Teammitglieder ein anderes Bild vom Ablauf und den Review-Zyklen haben. Schritt eins: Prozesse visualisieren, Engpässe erkennen – danach kann man über WIP-Limits den Durchsatz erhöhen. Danke, Dimitar, für deine Einblicke! Wer Kanbanize ausprobieren will: kanbanize.com – der Link steht auch in den Shownotes. Herzlichen Dank, dass du bei uns warst!

Dimitar Karaivanov:

Danke, Ben! Es war ein tolles Gespräch. Ich habe es sehr genossen. Bis bald!

Ben Aston:

Wer noch mehr lernen und im Beruf weiterkommen will, sollte Mitglied bei DPM werden: thedigitalprojectmanager.com/membership – Zugang zu Team-Templates, Workshops, Sprechstunden, E-Books und vielem mehr! Und wenn euch der Podcast gefallen hat, abonniert uns auf thedigitalprojectmanager.com. Bis zum nächsten Mal – vielen Dank fürs Zuhören.