Taskliste? Logbuch? Kanban!

Logbücher gehören verboten. Zumindest wenn sie als Sammelbecken für Vorhaben und Aufgaben dienen, die man hätte tun wollen, aber seit längerem nicht gemacht hat. Und wöchentlich starrt dann das Team auf all die Ideen, Wünsche, Neigungen oder Forderungen, die gestern einmal gut waren.

Vielleicht waren sie auch gar nicht gut. Deshalb stecken sie noch immer in Logbüchern. Na, macht nichts.Wir hängen einfach neue „Todos“ dazu und nehmen uns ganz fest vor: morgen legen wir los.

Wie auch immer. Logbücher verführen als Werkzeug rückwärts gewandt zu (re)agieren und sind somit ungeeignet für Wertschöpfende Projektarbeit. Die Projektarbeit erfordert den Blick nach vorn. Richtiges richtig machen, da bleibt wenig Zeit für eher ungeeignete Praktiken. Autofahren allein über den Blick in die Rückspiegel gelingt in der Praxis auch selten. Man ist nicht mehr mit dem Ankommen, dafür mit dem Autofahren selbst beschäftigt und man wird deutlich langsamer.

Ok, Logbücher sind ungeeignet. Na gut. Dann nehmen wir eben Tasklisten. Wer schon einmal in die Taskliste eines anderen geschaut hat, kennt sicher das Gefühl, zwar alles zu sehen, aber nicht zu erkennen, was das bedeutet.

Projektarbeit ist anspruchsvoll, ist oft komplex und somit voller Überraschungen. Wenn es um zügiges Vorankommen und Wertschöpfung im Vorhaben geht, dann braucht es Zusammenarbeit und viel Kommunikation. Tasklisten geben zwar Einblick, aber nicht unbedingt Überblick. Und es stapeln sich auch hier – ähnlich wie in Logbüchern – die Aufgaben.

Und so richtig spannend wird es, wenn im Team zusammen Ergebnisse erarbeitet werden sollen und aufgrund der knappen Zeit jeder für sich beginnt, seine Aufgaben zu priorisieren. Dann wird Zusammenarbeit zum Glücksspiel. Viel Zeit und Aufwand werden nutzlos vertan.

Früher, zu Hochzeiten der industriellen Massenproduktion, als der Fertigungsprozess noch übersichtlich war, da haben Logbücher und Tasklisten vermutlich ihren Zweck gut erfüllt.

„Sie können einen Ford in jeder Farbe haben – Hauptsache er ist schwarz.“
(Henry Ford, 1863-1947)

Zur Vorbereitung einer Produktion mit hohen Stückzahlen, wenigen Umrüstaufgaben, sequentieller Fertigung (Fliessband) und einer Variantenversions-Vielfalt von nahezu 0 sind Logbücher und Tasklisten eine gute Wahl. Viel Zusammenarbeit braucht es da nicht.

Wie oft kommen diese Produktionsbedingungen noch vor?

Wenn Transaktionen nahezu in Echtzeit über Kontinente hinweg erfolgen, wenn sich Produktions-Losgrössen immer schneller in Richtung „1“ entwickeln, wenn Services immer modularer und vernetzter werden, dann werden Zusammenarbeit und Kommunikation wesentliche Erfolgsfaktoren. 

Zusammenarbeit kann man verbessern, folgendes sollte dann gelingen:

  1. alle wesentlichen Aufgaben müssen berücksichtigt und bearbeitet werden
  2. die Reihenfolge der Bearbeitung muss optimal sein
  3. unnötige Aufgaben müssen eliminiert werden (kontinuierlich)
  4. der Informationsfluss muss sichergestellt und optimal sein
  5. die richtigen Mitarbeiter müssen die Aufgaben übernehmen

Kontinuierlich, über das gesamte Vorhaben und über die gesamte Organisation hinweg soll das gelingen und eigentlich sollte das ein sich selbst regelndes System sein. Denn wer kann bspw. allein festlegen, was alle wesentlichen Aufgaben sind? In komplexen Vorhaben lauern viele Überraschungen und somit werden Praktiken benötigt, die den Blick nach vorn unterstützen und helfen das Vorhaben erfolgreich zu navigieren und ins Ziel zu bringen. Wir müssen agil=beweglich werden. 


Mindset-Kampagne, Themenkarte: Agile Projektarbeit


Abbildung: Themenkarte „Agile Projektarbeit“, Training „Wertschöpfende #Projektarbeit“

Agilität ist das Vermögen, eine Anordnung zu verändern. Auf der Suche nach geeigneten Methoden zwischen Scrum und klassischem Projektmanagement-Vorgehensmodell fand sich eine bemerkenswert einfache und effektive Methode: Kanban.

Kanban („Signalkarte“) ist nicht nur eine Methode, es ist eine Philosophie. Kanban kommt ursprünglich aus der Produktionsprozesssteuerung (Toyota Produktionssystem). Wikipedia weiss: „Ziel der Kanban-Methode ist es, die Wertschöpfungskette auf jeder Fertigungs-/Produktionsstufe einer mehrstufigen Integrationskette kostenoptimal zu steuern.“ Was für Komponenten und Baugruppen in der Produktion klappt, kann auch für Arbeitspakete gut sein. So entwickelten schlaue Berater und Praktiker eine Kanban-Variante, die die Leistungssteuerung in Vorhaben optimieren hilft.

Ich möchte auch gleich auf die Nebenwirkungen hinweisen: Kanban in der Projektarbeit ändert das Mindset, es führt nach ersten Gehversuchen schnell zu bemerkenswerten Veränderungen in der Zusammenarbeit und in der Erreichung anspruchsvoller Ziele. Alles was benötigt wird, ist eine Wand, ein Whiteboard oder am besten ein Pin-up Board sowie Kärtchen und ein neugieriges, aufgewecktes Team, das bereit ist, sich von Tasklisten und Logbüchern zu lösen und sich täglich kurz zu treffen, um über die Projektarbeit zu reden. Ja, es braucht auch – einfache – Spielregeln.

Wesentliche Spielregel: Begrenze die Menge paralleler Arbeit, „work in progress/WIP“ genannt. Das muss man üben, gerade am Anfang neigen Projektteams dazu, viele Aufgaben parallel zu beginnen. Der Kanban-Ansatz verfügt u.a. deswegen über einige wenige Prinzipien und Praktiken. Dies ist Kernpraktik 2.

Die Grundprinzipien, formuliert von David Anderson als Begründer der administrativen Kanban-Variante, sind auch eingängig und schnell ausprobierbar, das bekannteste und für mich bemerkenswerteste ist: „Beginne mit dem, was Du gerade tust“. Die Kernpraktiken betonen das Wesentliche an dem Ansatz (in kurzen Aussagen): 

  1. Visualisiere
  2. Limitiere die Menge paralleler Arbeit
  3. Flow! Manage der Arbeitsfluss
  4. Policies! Vereinbart einfache Regeln
  5. Feedback! Richtet Feedbackzyklen ein
  6. Erziele kooperativ Verbesserungen, entwickle experimentell (mit bewährten Praktiken, Methoden und Modellen)

„People ask me: What is the difference between lean and kanban? Answer: lean is a destination; kanban is means to get there.“
(David J. Anderson)

Kanban hilft, die Projektarbeit effektiv zu gestalten. Was ist zu tun, damit die oben formulierten Erwartungen zur Zusammenarbeit erfüllt werden können? Erprobt und bewährt haben sich einfache Regeln und Rituale in den Projekten. Das ist wie spontan mit ein paar anderen eine Runde Fussball zu spielen. Nichts kompliziertes. Ein Mitmachspiel.


Themenkarte „Spielregeln“, Training „Wertschöpfende #Projektarbeit“


Es gibt einen Moderator (im Scrum der Scrummaster), der legt die täglichen kurzen Treffen aller Teammitglieder sowie die regelmässig alle 14 Tage stattfindenden inhaltliche Abstimmung fest. Auch ein monatliches Review-Treffen organisiert der Moderator. Das Team ist vollständig dabei. Der Moderator agiert auf Augenhöhe zum Team. Stehen ist besser als Sitzen. Bilaterale Abstimmungen erfolgen nach der gemeinsamen Abstimmung.

Die 14-tägigen Treffen dienen der Abstimmung der Arbeitspakete, pro Arbeitspaket wird eine Karte geschrieben und ans Board geheftet. Jede Karte startet in der Spalte links. Im Scrum heisst die linke Spalte „Backlog“, es werden alle vorgeschlagenen und noch nicht bearbeiteten Aufgaben hier gesammelt. Es werden nur wenige Karten akzeptiert. Das Notwendige und das Leistbare wird transparent gemacht. Nicht wertschöpfende Aufgaben werden schnell identifiziert. Die Aufgaben müssen aufeinander abgestimmt sein, der für die Aufgabe geeignete Mitarbeiter muss verfügbar sein. Konflikte scheinen somit zügig auf. Und es entstehen Gruppenentscheide, es gibt ein Commitment der Beteiligten. Selbstorganisation gelingt.

In den kurzen täglichen Treffen berichtet jeder kurz über den erreichten Arbeitsfortschritt. Statt Status wird über Fortschrittsgrad und verbleibendem Aufwand gesprochen, Unterstützung und Zusammenarbeit werden bedarfsgerecht koordiniert. Auch hier werden Konflikte schnell sichtbar. Jeder weiss Bescheid, insbesondere weiss jeder, wo und was er wem liefern muss (was der Kunde seiner Leistung erwartet). In diesen Treffen werden neue Aufgaben zu Aufgaben in der Umsetzung und erfüllte Aufgaben zu abgeschlossenen Aufgaben. Das Board lässt sich bedarfsgerecht strukturieren, bspw. etwas detaillierter in der Form: Vorgeschlagen > Vereinbart > In Umsetzung > Erstellt/in der Prüfung > Übergeben > Akzeptiert. Aber meist ist weniger mehr.

In den monatlichen längeren Treffen, der Retrospektive, werden gemeinsam die Regeln und Rituale angesehen. Dinge die gut gelungen sind, Praktiken, Modelle und Methoden, die sich bewährt haben oder die Störungen erzeugt haben, werden kritisch gewürdigt. Das Team bestimmt die weitere Zusammenarbeit.

Damit dieses Modell der Zusammenarbeit gelingt, ist mindestens ein Spezialist für das Fachgebiet, in dem sich die Projektarbeit bewegt, stets dabei. Er arbeitet massgeblich an der Vorbereitung, Planung und Führung des Vorhabens mit. Angelehnt an Scrum ist das der Product Owner. Der Moderator ist fit in der Verwendung der Kanban-Methode und führt schrittweise das Team zu einer professionellen Anwendung des Kanban-Ansatzes und kümmert sich um das Mindset.

Kanban ist eine Methode, es ist darüber hinaus eine Philosophie, die hilft, einen Paradigmenwechsel im Umgang mit Transparenz, Führung (Leadership), mit der Ausgewogenheit der Projektleistungen, mit dem Zusammenspiel unterschiedlicher Menschen in vielfältigen Rollen und bestimmtem Knowhow herbeizuführen. Es gelingt zudem ein komplett anderes Verständnis von Zusammenarbeit (weg vom „Toll ein anderer machts“-Teamdilemma). Es werden viel robustere Vereinbarungen getroffen und alle im Team bringen sich aktiv und einander wertschätzend ein. Die Kundenorientierung wird stimmuliert und es gelingen besser auf einander abgestimmte Zuarbeiten, der Arbeitsfluss wird ohne komplizierte Planungstechniken optimiert.

Wo sind die Haken? 

Einen wesentlichen Haken gibt es: das Team muss Zeit haben für das Vorhaben. Ohne vereinbarte Projektarbeitsquote (optimal 100% der effektiv zur Verfügung stehenden Arbeitszeit, aus Erfahrung heraus mindestens 40%/2 Tage pro Woche für Kernteammitarbeiter) wird die Zusammenarbeit massiv gestört.

Es gab auch schon Mitarbeiter, die das Kanban-Vorgehen als PostIt-Methode titulierten und nur physisch im Vorhaben dabei waren. Das stört enorm. Es braucht für agile Vorgehensmodelle stets die richtigen Mitarbeiter. Ja, nicht jeder eignet sich für diese Form der Zusammenarbeit. Es muss möglich sein, das Team optimal zu besetzen. Damit ist nicht das Knowhow gemeint, eher die „Chemie“. Knowhow erwächst aus den Aufgaben. Wissen kann man sich aneignen. Können basiert auf Übung und erlangter Fitness. 

Die tägliche Interaktion erzeugt einen gewissen Druck in der Gruppe. Es braucht einen, der das beobachtet und bei Bedarf behutsam regulierend eingreift. Das aktuelle Vorhaben ist sicher nicht das einzige und letzte, die Zusammenarbeit darf nicht auf Verschleiss ausgelegt sein. Das „Resource Balancing“, also der ausgewogene Einsatz von Menschen im Vorhaben ist wichtig. Bedarfsgerechte Kompetenzentwicklung und Zugehörigkeit verleihen allerdings „Flügel“. Das kann man nutzen.

Darüber hinaus gilt für alle Vorhaben, unabhängig vom Vorgehensmodell: das Management muss hinter dem Vorhaben stehen. Ressourcenverantwortliche sorgen bspw. für optimale Ressourcenauslastung. Der Sponsor ist aktiv beteiligt und kennt sein Vorhaben. Verantwortlichkeiten sind klar zugeordnet. Das Zusammenspiel klappt nicht nur im Projektteam, sondern auch mit dem Sponsor und den Ressourcenverantwortlichen.


Kanban-Board-Beispiel: pragmatisch und einfach, dafür lebendig


Abbildung: Kanban-Board-Beispiel – pragmatisch und einfach, dafür lebendig … nicht jede Regel wird 100%ig durchgehalten. Was funktioniert hat Recht. (2017)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.