Kanban ist eine denkbar einfache Methode, um den Überblick über die parallelen Arbeiten zu behalten. Dennoch gibt es einige Tricks...
Durch Kanban behält man den Überblick über die Anzahl paralleler Arbeiten und verkürzt durch eine Verknappung dieser deren Durchlaufzeiten - soweit so klar. Langweilig. Grundlagenwissen. Dennoch kann mit wenigen Tricks eine zusätzliche Fokussierung auf einzelne Aufgaben und Engpässe durch Transparenz geschaffen werden. In diesem Beitrag gehe ich auf diese Tricks ein:
Also. Los! Erfahrungsschatz teilen - #sharingiscaring:
Tönt komisch, ist jedoch meiner Erfahrung nach ein riesiger Unterschied und ein grosser Vorteil:
Alles Vorteile, die mit einem digitalen Kanban-Board à la JIRA, Trello & Co verspielt werden. Schade.
Digitale Kanban-Boards haben jedoch auch ihre Vorteile: Verteilte Teams sind darauf gar angewiesen. Lösung? Gibt es! Z. B.: Master ist das digitale, Slave das analoge Kanban-Board. Oder Videostreaming des analogen Kanban-Boards - schon gemacht, kam super an! Ja, ist Mehraufwand. Aber jeden Rappen/Cent/Penny/Jimmy wert! Und so eine Videostreaming-Anwendung zu bauen, kann sogar ein richtig spassiger Team-Event sein! Fun!
"In Analysis" > "To Do" > "In Implementation" > "Ready to review" > "Under review" > "Ready to test" > "Under test" > "Done" - sieht dein Kanban-Board (noch) so aus? Hm. Mich interessiert ja eh bloss "Done". Aber ja... also:
Grundlegend basiert ein Kanban-Board auf den Spalten "To do" > "In progress" > "Done". Und mit diesem schlanken Design läuft es super, mehr braucht es nicht. Wirklich! Doch? Hm, aber... : Jede zusätzliche Spalte zwischen "To do" und "In progress" unterteilt den Flow in Teilschritte:
Mal mit wenigen Spalten zu starten und über die Zeit weitere, (wirklich!) notwendige Spalten hinzuzufügen, geht i.O. - die Frage, die ich immer stelle, ist: Was wollen wir unterscheiden? Interessiert es uns wirklich, welche Teilschritte "In progress" bilden, machen wir wirklich einen Unterschied? Brauchen wir diese Information, hilft es in der Zusammenarbeit? Was ist denn der Unterschied zwischen "In progress" vs. "In implementation", "Ready to review", "Under review" usw.? Denn: Das Ziel ist es, Aufgaben zu erledigen! Bloss "Done" ist "Done"! "Under Review" usw. ist nicht "Done" - also vollkommen uninteressant. Wirklich. Waste. Uncool. Brauchen wir nicht. Ohne mich. Nope.
Die Abkürzung WIP steht für "Work In Progress". Einfach gesagt ist WIP die Anzahl der Aufgaben, an denen ein Team gerade arbeitet. Das WIP bildet jeweils die aktuelle Workflow-Kapazität eines Teams ab und begrenzt die Anzahl der Issues pro Status (Spalte). Die WIP-Begrenzung ist eine der grundlegenden Kanban-Praktiken: So kannst du deinen Prozess optimal verwalten und es entstehen reibungslose Workflows und Überlastungen können vermieden werden. Flow also. Das wollen wir!
Das WIP hilft, auf Angefangenes zu fokussieren und dieses zu Ende zu bringen, denn: Was bringt es, 10 Dinge in parallel in Angriff zu nehmen und nichts davon zu Ende zu bringen? Nada, oder? Unfertig ist unfertig und unbrauchbar - genau betrachtet. Korrekt? Gerade zu Beginn, wenn man mit Kanban noch nicht so vertraut ist, empfehle ich, das WIP tief zu halten, um ein Gefühl für den Flow entwickeln zu können. Für Teams empfehle ich ein WIP, das dem 1- bis das 1,5-fachen der Anzahl Team-Mitglieder entspricht. Das WIP kann über die Zeit den Bedürfnissen des Teams angepasst werden, es gibt keine Vorgaben. Logisch. Denn: Der Prozess unterstützt uns! Wehe, er behindert uns!
Als gute Praktik empfiehlt es sich, das Kanban-Board entgegen des "Arbeits-Flusses" (Arbeits-Fluss: von "To do" links, nach "Done" rechts) zu lesen - also von rechts nach links - um so den Fokus der eigenen Aktivitäten auf Issues zu legen, welche bereits angefasst wurden und vor dem Abschluss stehen. So wird z. B. der Fokus auf Issues gelegt, welche Kollegen in der Umsetzung haben, bevor ein neues Issue in Bearbeitung gesetzt wird. Dies fördert den Flow sowie die Zusammenarbeit im Team. Das tönt super! Das wollen wir! Nice!
Alchemie (genauer: die Goldsynthese) ist IMHO in der Informatik weit verbreitet. Wie es in anderen Industriezweigen aussieht, entzieht sich meinen Kenntnissen. Wie auch immer: Immer wieder wird versucht, aus unklaren, sehr (also eher: extrem) vage beschriebenen Anforderungen ein konkretes, wertbildendes Resultat zu erzeugen. Dies ist beinahe immer sehr schwierig, oft unmöglich. Man kann es ja mal probieren. Klar. Mutige vor!
Es empfiehlt sich, Anforderungen kurz zu prüfen, bevor sie angenommen werden: Sind alle Informationen so vorhanden, dass ich die Arbeit in Angriff nehmen kann? Kenne ich allfällige Ansprechpartner, um später aufkommende Detailfragen klären zu können (eine User Story ist ja eine Einladung zur Zusammenarbeit)? Weiss ich, wen ich bei oder nach Abschluss der Arbeit informieren muss, sodass weitere Schritte angegangen werden könne? Usw. Etc. Pp. Einem Team kann eine sog. "Definition of Ready" (DoR) helfen, sich auf einen "Minimal-Standard" zu einigen, welcher es bei der Definition von Anforderung zu berücksichtigen gilt. Dieser "Minimal-Standard" wird schriftlich definiert, zugänglich gemacht und von Zeit zu Zeit überarbeitet. Im Idealfall wird eine DoR über die Zeit obsolet durch die verbesserte Zusammenarbeit im Team. Perfekt! Denn, Collaboration lieben wir!
Analog zu "Fokus: Von rechts nach links lesen": Das Ziel von Kanban ist es, Engpässe möglichst schnell zu erkennen und zu beseitigen. Hindernisse frühzeitig zu erkennen und fokussiert in Angriff zu nehmen, bedingt jedoch, dass sich alle auf diese mit erster Priorität fokussieren. Tönt einfach. Ist es nicht (unbedingt), denn:
Wer mag es schon, wenn sein Issue jenes ist, was blockiert und der Rest des Teams sich um seinen Arbeitsplatz versammelt? Mehrmals "Kann ich helfen?" gefragt wird? Unangenehm. Und wer will sich schon immer um die Schei**e der andern kümmern? Ne, muss nicht sein. Hm. Halt. Denn Zusammenarbeit ist halt genau das. Fokus auch. Und wenn Fokus und Zusammenarbeit zusammenkommen, so fokussiert man zusammen auf jene Dinge, welche blockieren. Dafür kann das Teammitglied ja nichts. Sicher nicht! Also: Bevor ich ein neues Issue in Angriff nehmen, prüfe ich, ob es etwas gibt, was unseren Flow blockiert und wenn ja, setze ich meinen Fokus darauf. BTW hierzu dient ja auch das Daily-Scrum in Scrum. Vielleicht ergibt so ein Standup-Meeting auch in einem Kanban-Team Sinn? Wer weiss.
Die Arbeit wird immer wieder blockiert? Durch Abhängigkeiten? Durch Umsysteme, welche nicht up and running sind? Ansprechpartner, die schwierig zu fassen sind? Ja, das kennen wir alle. Doof. Genau. Ja, und jetzt? Faust im Sack? Hm. Wie wäre es mit einer "Landkarte der Abhängigkeiten"?
Erstelle einfach eine Mindmap mit dem Startknoten "Team" (oder "Unser cooles Vorhaben") und hänge pro Abhängigkeit einen Ast an diesen. Pro Ast hältst du den Status der Beziehung zum Zeitpunkt X fest und die Entwicklung über die Zeit derer (X+n). So sehen alle, dass z. B. die Instabilität eines Umsystems aktuell den Flow des Teams beeinträchtigt - obwohl das mal perfekt war. Des Weiteren kann über die Zeit eine Verbesserung oder Verschlechterung der Beziehung transparent aufgezeigt werden. Kein Manager muss mehr fragen. Kein Rapport-Meeting ist mehr notwendig. Einfach. Klever. Smart. Transparent.
Selbstverständlich gibt es noch weitere Tipps & Tricks wie z. B. Durchlaufzeit von Issues erheben, das Nachfragen und Nachfassen bei Fragen zu einem Issue dokumentieren, pro Thema/Bereich eine Farbe der Karten des Issues wählen, mit einem Avatar (z. B. aufgeklebt auf einen Magneten) auszuweisen, wer am Issue arbeitet, eine "Definition of Done" im Team auszuarbeiten und festzuhalten usw. Eine schier endlose Liste. Unglaublich, nicht? Wie auch immer:
Das Wichtigste ist, dass das Vorgehen (aka. der Prozess) den Bedürfnissen des Teams entspricht. Und dazu empfiehlt es sich, dieses von Zeit zu Zeit zu prüfen, bei Bedarf eine Änderung (eine im selben Moment) zu vollziehen, ein Experiment zu definieren und das Resultat auszuwerten, sodass der Prozess sich stetig verbessern kann. Eigentlich logisch. In einem agilen Umfeld sowieso. Aber eben. Wir vergessen gerne. Oder?
Wenn auch der Prozess anfangs einfach erscheint, stolpert man gerne über das Prinzip WIP. Dies aus Gewohnheit, viele Dinge parallel "vorantreiben" zu wollen. Gerade als Chef/in. Dabei delegiert man gewaltig. Meist ins Leere, und oft kommen viele Fragen zurück, die einen mehr zurückwerfen als voranbringen. Hin und her. Eigentlich Stillstand. Nervend. Doof.
Die Erfahrung ist, dass wenn man konsequent versucht, sich ans WIP zu halten, der notwendige Fokus auf ein Issue entsteht und dieses gezielt vorangetrieben wird. Man geht der Sache nach, auf den Grund und im Regelfall findet man sich im Kooperations-Modus wieder (was IMHO Delegation nicht ist). Dies hat uns im Team geholfen. Denn "done" ist "done". Das wollen wir.
Natürlich ist man immer mal wieder mit Issues konfrontiert, welche man nicht selbst lösen kann. Auch im Team nicht. Dinge wie z. B. fehlende Budgethoheit, fehlende Unterschriftsberechtigung usw. können ausbremsen. Zwangsläufig. Und dann. Stillstand, weil WIP? Hm. Uncool. Nein!
Anstelle dessen haben wir eine weitere Spalte auf dem Board definiert: "Fenced" (engl. für eingezäunt) nach "In progress". In dieser Spalte haben wir diese Issues platziert. Und der Spalte ein WIP gegeben. Dies erlaubt uns, an solchen Abhängigkeiten begrenzt "vorbei" zu arbeiten. Dennoch war klar, dass da was ist, was uns bremst. Und wenn vieles davon sich anhäufte, dann mussten wir als Team den Fokus ausschliesslich darauf legen. WIP halt. Diese Idee entstammt dem Ansatz von Personal Kanban. Was ist das? Siehe Lesetipps:
Einfache, grafische Darstellung, wie Kanban genutzt werden kann als Comic: One day in Kanban land von Henrik Kniberg. Der schreibt allgemein noch interessante Dinge. Lesenswert. Unbedingt.
Du fühlst dich überflutet von Aufgaben, die an dich herangetragen werden? Du willst deinen Fokus (wieder-)gewinnen? Du magst Kanban mal für dich ausprobieren? Willkommen. Schau dir mal Personal Kanban an: Ich mach das seit ca. 3 Jahren und habe sehr, sehr gute Erfahrungen damit gemacht.
Kanban ist einfach. Einfach mächtig. Und mit wenigen Tricks wird es supermächtig. Sei es im persönlichen Gebrauch oder für die Zusammenarbeit im Team. IMHO ist Kanban gar einer der Königsweg der agilen Methoden. Noch vor Scrum (ok, Scrum ist ein Framework - klar). Aber das wäre dann eine andere Diskussion. Oder?
Wenn du mehr zu Kanban erfahren magst, kontaktiere uns ungeniert! Gerne tausche wir unsere Erfahrungen aus. Und gerne helfen wir, die Methode kennenzulernen.
Zudem bieten wir dir auch unseren dot.benchmark an, womit wir nicht bloss Potenziale hinsichtlich der Teammethoden identifizieren können, sondern auch im Kontext z.B. der Teamdynamik.
Keine Kommentare bis jetzt
Lass uns wissen, was du darüber denkst.