Von Agilität hat vermutlich mittlerweile jeder gehört. Dennoch kommt es immer wieder vor, dass verschiedene Personen der Meinung sind, dies sei nichts für sie.
Agile Methoden für mich allein ist doch sinnlos?!
Warum ist das so? In vielen Köpfen überwiegt das Verständnis, dass Agilität und speziell auch agile Methoden, wie zum Beispiel die beiden gängigen Scrum oder Kanban, etwas für Teams und damit für die Zusammenarbeit zwischen Menschen ist. Grundsätzlich ist dies auch nicht falsch! Man kann sich jedoch, für die Einzelarbeit beziehungsweise das individuelle Arbeiten, seine Arbeitsorganisation oder Zeitmanagement, aus dem „Agilen Werkzeugkoffer“ sehr gut bedienen. Wie die agile Methode Kanban mit den einzelnen (agilen) Bausteinen als dafür am besten geeignetstes Instrument dazu verwendet und angepasst werden kann, findet sich in diesem Artikel. Zusätzlich gibt es an einigen Stellen Tipps und Trick für die konkrete praktische Anwendung.
Doch: Kanban – Ergänzt und vereinfacht für Sie persönlich
Neben Scrum ist Kanban (siehe Abbildung 1) die verbreitetste Methode unter agilen Teams. Sie stammt ursprünglich aus dem Lean Management beziehungsweise der Lean Production. Aufgrund dieser Historie wird Kanban meist für (zeitnahe) Wartungs- und Ticketabarbeitungsaufgaben eingesetzt.
Das Herzstück von Kanban ist das sogenannte Kanban-Board zur Visualisierung des aktuellen Status der Aufgaben über verschiedene Spalten (in der simpelsten Form: „ToDo“, „In Arbeit“, „Fertig“). Neben dem Board gibt es noch viele weitere agile Bausteine, die erst in der Summe die gesamte Methode Kanban ergeben. Diese sind: das Work-in-Progress-Limit (WiP), das Pull-Prinzip, ein regelmäßiges Planungs-Meeting, das Daily, die Definition of Done (DoD), das Kumulative Flussdiagramm und gegebenenfalls weitere Diagramme und die Retrospektive. Mehr Details zu Kanban finden sich in [And11]. In unserem „persönlichen“ Szenario wäre das reine Kanban-Board zu kurz gedacht, denn Arbeitsorganisation und Zeitmanagement bedürfen mehr als der reinen Transparenz über Visualisierung. Wichtig ist hier speziell der kontinuierliche Verbesserungsprozess (KVP oder Kaizen, aus dem Japanischen). Aus diesem Grund dient Kanban als Methode unserem „persönlichen“ Szenario als Grundlage und wurde dafür noch ein wenig angepasst und vereinfacht.
Dennoch hat sich gezeigt, dass es noch nicht ausreicht für das gängige Szenario. Ganz häufig wird man nämlich mit der Frage konfrontiert: Was kommt denn dann überhaupt in mein Kanban-System beziehungsweise auf mein Kanban-Board? Natürlich mit dem Hintergedanken, dass nicht die allerkleinsten oder schnell zu erledigende Aufgaben dort im Mikromanagement getrackt werden (müssen).
Abb. 1: Kanban – Überblick
Überblick der Lösung
Die Lösung hierfür ist eine Kombination aus einem angepassten Kanban und der Idee beziehungsweise dem Ablauf von „Getting Things Done“ [All19]. Diese Kombination dient speziell dazu, das Befüllen des Kanban-Systems zu vereinfachen und zu systematisieren. Die Übersicht in Abbildung 2 zeigt den Weg von der „Inbox“ bis hin zum Backlog des Kanban-Boards. Generell ist die Lösung komplett unabhängig von der Tool-Nutzung. An der einen oder anderen Stelle werden jedoch Tools aus der Praxis als Beispiele erwähnt
Abb. 2: Personal-Kanban-Prozess
Die „Inbox“
Jeder kennt das Problem, dass verschiedenste Aufgaben über ganz verschiedene Kanäle, Medien, Tools usw. kommen können, zum Beispiel Mails mit Aufgaben, konkrete Tickets in einem Ticketsystem wie JIRA, Projektaufgaben, organisatorische Themen aus mündlichen Meetings usw. Die Idee der Inbox ist es, diese Aufgaben zentral möglichst an einer (oder wenigen) Stelle(n) zu sammeln. Dies kann ein konkretes Tool oder eine Liste sein (gerne genutzt z. B. die Aufgaben in Outlook oder der persönliche Confluence-Bereich mit dem „Einsammeln“ aller eigenen Aufgaben – Makro „Aufgabenbereich“) oder auch einfach nur im Kopf behalten werden. Wobei Letzteres speziell bei vielen Aufgaben aus verschiedenen Kanälen nicht zu empfehlen ist, denn so gehen immer wieder Aufgaben verloren.
Dabei stellt sich die Frage, ob es für diese Aufgaben nötig ist, persönlich etwas zu tun. Wenn es für einen selbst nichts zu tun gibt, sollte es nicht in der Inbox bleiben, sondern dort entfernt werden. Laut „Getting Things Done“ [All19] sollte es entweder in den „Papierkorb“, auf „Wiedervorlage“ oder als „Ablage als Referenz“ zur Seite geschoben werden (siehe Kasten 1).
| Konkrete Fragen, die Sie bei der „Inbox“ beantworten müssen: |
| ■ Aus welchen Kanälen kommen (normal) Aufgaben auf mich zu? |
| ■ Welches Tool (ACHTUNG: Nicht zwingend Software) will ich nutzen für meine gesammelte Inbox? |
| ■ Bei welchem Input beziehungsweise welchen Aufgaben muss ich etwas tun? |
Von der Inbox zum Kanban-Board
Bei allen Aufgaben, die dann noch übrig sind, stellt sich jeweils die Frage, ob diese Aufgabe direkt in einem Schritt abzuarbeiten ist oder nicht. Ist das nicht der Fall, kann die Aufgabe beziehungsweise können die Aufgaben entweder mit den zugehörigen Teilaufgaben oder nur die Teilaufgaben ins Backlog des Kanban-Boards. Welche der beiden Varianten hierbei gewählt wird, kann jeder frei entscheiden.
Für den Fall, dass die Aufgabe in einem Schritt zu erledigen ist, stellt sich die Frage der Größe beziehungsweise Dauer der Aufgabe. Denn häufig kommt die Frage, ob man dafür wirklich ein Ticket anlegen muss oder ob die Aufgabe selbst nicht schneller abgearbeitet werden kann. Auch wenn „Getting Things Done“ [All19] von der Zwei-Minuten-Regel spricht (alles, was unter zwei Minuten zu erledigen ist), empfiehlt es sich, hier zu überlegen, was für einen selbst das geeignete Kriterium ist, Aufgaben direkt zu erledigen oder diese ins Backlog des Kanban-Boards zu geben. In der Praxis wird häufig genannt: Wenn das Anlegen des Tickets länger dauert als das eigentlich Bearbeiten, dann ist es sinnvoller, dies direkt zu bearbeiten. Die Unterscheidung, ob eine Abhängigkeit bei der Bearbeitung vorhanden ist oder nicht, spielt für die Aufgaben auf dem Kanban-Board keine Rolle. Dies ist der Fall, da „Wartezeiten“ über das Board abgebildet werden können und das Einplanen zum einen über die Priorisierung im Backlog und zum anderen über ein Fälligkeitsdatum, als Teil der Definition of Ready [DoR] stattfinden kann. Das Priorisieren der Aufgaben sowohl auf dem Kanban-Board als auch auf dem Weg dorthin kann dabei über verschiedene Wege ausgestaltet werden. Ein gängiges Beispiel ist die Eisenhower-Matrix [Wiki], um nach Wichtigkeit und Dringlichkeit zu priorisieren.
Grundsätzlich ist die Definition of Ready, also die allgemeingültige Definition, wann jede Aufgabe bereit („Ready“) ist, als eine Art Checkliste eine sinnvolle Ergänzung zu Kanban. Im Bereich des Personal Kanban, mit vielen ganz verschiedenen Aufgaben, sind folgende Kriterien für die generische Checkliste der DoR ein häufig gewählter Vorschlag: ein Ticket-/ Aufgabenname, eine (Kurz-)Beschreibung und Akzeptanzkriterien (mind. eines). Sinnvolle, aber optionale Aspekte sind das Fälligkeitsdatum, Teilschritte (kann auch einhergehen mit Akzeptanzkriterien) und Abhängigkeiten zu anderen Tickets. Im Fall vom Personal Kanban sind die Akzeptanzkriterien sehr wichtig, da es meist ganz unterschiedliche Aufgaben sind, wofür somit keine (oder nur eine sehr abstrakte) DoD [Scrum] möglich ist. Die Akzeptanzkriterien müssen dies dann ersetzen. Die DoD als eine allgemeingültige Checkliste zur Fertigstellung („Done“) aller Aufgaben lässt sich im Personal Kanban nur sehr selten anwenden, da die Vielfalt und Art der Aufgaben zu unterschiedlich ist, von ganz verschiedenen Mails über Supportanfragen bis hin zu konkreten Projektaufgaben (die im Idealfall schon eine DoD des Projekts beinhalten). Es besteht jedoch die Möglichkeit, für verschiedene Arten an Aufgaben jeweils eine Definition als Checkliste zu erstellen: Für Mails könnten beispielsweise folgende Kriterien eine Überlegung sein: Mail ist bearbeitet, beantwortet und aus dem Postfach entfernt, ggf. in Unterordner verschoben (siehe Kasten 2).
| Konkrete Fragen, die Sie bis zum Kanban-Board beantworten müssen: |
|
■ Ist bei Ihnen die Zwei-Minuten-Regel als Größe für ein Ticket sinnvoll oder haben Sie ein anderes Kriterium? |
|
■ Wie sieht die für Sie passende DoR aus beziehungsweise welche Kriterien gelten für alle Aufgaben? |
| ■ Ist eine DoD für mein Personal Kanban sinnvoll? Wenn ja, wie sieht diese aus beziehungsweise welche Kriterien gelten für alle Aufgaben? |
Das (personal) Kanban-Board
Das Kanban-Board und sein Aufbau starten mit der DoR, denn diese „unterteilt“ die erste Spalte „Backlog“ von der zweiten „Ready“ und unterscheidet sich darin, dass letztere mehr Details (passend zur DoR) beinhaltet. Durch diese Ready-Spalte wird auch das kanbansche Pull-Prinzip des eigenen Ziehens von Aufgaben noch mal verdeutlicht, auch wenn es auf einem persönlichen Board automatisch der Fall sein sollte. Diese Unterscheidung macht zum Beispiel das Tool JIRA automatisch, wenn das Backlog eine gewisse Menge an Einträgen oder Aufgaben überschreitet. Die „In Arbeit“-Spalte zeigt dann die Aufgaben, an welchen man aktuell arbeitet. Hierbei ist es sinnvoll, aus Kanban das WiP-Limit zu verwenden, also die Anzahl an parallelen Aufgaben, die in Arbeit sind, zu limitieren, um Kontextwechsel zu vermeiden. Wie bei jedem WiP-Limit wäre eins (pro Person) perfekt für die Effizienz, jedoch ist dies aus der praktischen Erfahrung unrealistisch. Jahrelange Praxis hat gezeigt, dass ein Wert von drei oder vier vermutlich am sinnvollsten ist. Dies hängt jedoch sehr stark vom jeweiligen Kontext ab.
Die Erfahrung hat auch gezeigt, dass gerade aus einem persönlichen Board neben der „In Arbeit“-Spalte auch noch eine weitere Spalte notwendig ist, um Aufgaben, die blockiert sind oder wo zum Beispiel auf Rückmeldung gewartet wird, darzustellen. Die Empfehlung ist hier, „Waiting“ als Spalte einzuführen, da auch auf blockierte Aufgaben gewartet werden muss und es damit eine Teilmenge bildet. Abgeschlossen wird das Board durch die Spalte „Fertig“ oder „Done“, um zu signalisieren, dass eine Aufgabe fertiggestellt ist. Da, wie vorhin beschrieben, eine DoD in unserem Szenario nicht sinnvoll ist, wird hier das Prüfen der Akzeptanzkriterien als Übergang in diese Spalte gesehen. Zusätzlich zu den Spalten als Unterteilung des Kanban-Boards können auch noch Zeilen (im Englischen Swimlanes) zur Unterteilung genutzt werden. Dies ist zu empfehlen, wenn mehrere Aufgaben aus unterschiedlichen Projekten oder Themenbereichen kommen. Bei bis zu drei Projekten ist es sinnvoll, eine Zeile pro Projekt anzulegen. Zusätzlich ist es häufig eine gute Idee, eine Zeile für organisatorische Aufgaben anzulegen. Grundsätzlich ist es hier aber jedem individuell überlassen, wie die Zeilen zu gestalten sind. Dies liegt auch daran, dass verschiedene Rollen ganz unterschiedliche Bedürfnisse und damit auch Aufgaben haben, zum Beispiel ein Hauptabteilungsleiter und ein Mitarbeiter in zwei Projekten (siehe Kasten 3).
| Konkrete Fragen, die Sie beim Kanban-Board beantworten müssen: |
| ■ Welche Zeilen sind für mein Kanban-Board sinnvoll? |
| ■ Welche Arten an „Status“ fallen bei Ihnen unter die „Waiting“-Spalte? |
| ■ Ist eine DoD für mein Personal Kanban sinnvoll? Wenn ja, wie sieht diese aus beziehungsweise welche Kriterien gelten für alle Aufgaben? |
| ■ Wie viele Projekte haben Sie (parallel) und was gibt es sonst noch für mögliche Themenblöcke? |
Der Rest: Weitere Bausteine (die auch noch sinnvoll sind)
Neben den gerade genannten Schritten beziehungsweise dem Workflow inklusive des Kanban-Boards geht es darum, zu schauen, welche agilen Bausteine von Kanban noch ins „Personal Kanban“ mit einfließen.
Ein essenzieller Teil des kontinuierlichen Verbesserungsprozesses ist die Retrospektive zur Reflexion der Vergangenheit mit dem Ziel, für die Zukunft etwas zu verbessern. Auch wenn Retrospektiven ursprünglich für ein Team gedacht waren, gibt es das spezielle Format der „Personal Retrospektive“ [Zuck21], welches zur individuellen Selbstreflexion ideal geeignet und Teil des Personal Kanban ist.
Die Termine des „Daily“ und der „Planung“, die auch Teil von Kanban sind, lassen sich im Personal Kanban sehr gut kombinieren. Im alleinigen Arbeitsalltag muss jeder für sich entscheiden, wie häufig man die Aufgaben (um-)planen und (um-)priorisieren muss. Damit wird im Grunde jedes Daily (auch wenn es nicht täglich stattfindet) zu einem Planning. Ich persönlich selektiere und priorisiere die Aufgaben für den jeweiligen Tag morgens noch vor dem Aufstehen, beispielsweise über Microsofts ToDOs.
Abschließend kann man Personal Kanban auch mit den gängigen Metriken (Cycleoder Lead-Time) und Diagrammen (z. B. kumulatives Flussdiagramm) aus Kanban anreichern und diese nutzen (siehe Kasten 4).
| Konkrete Fragen, die Sie für weitere agile Bausteine beantworten müssen: |
|
■ Wie häufig ist bei Ihnen eine persönliche Retrospektive sinnvoll? (Legen Sie sich einen Rhythmus z. B. als Terminserie an)? |
| ■ Wie häufig ist bei Ihnen das „Daily Planning“ sinnvoll? |
Auf die (Arbeits-)Plätze, fertig, los!
Mit dieser Erläuterung von „Personal Kanban“ sollten Sie damit starten können, Ihr Aufgaben- und Zeitmanagement noch ein wenig zu verbessern. Wie Sie in dem Artikel feststellen konnten, spielen eingesetzte Software-Tools nur eine untergeordnete Rolle, da sich die Idee, der gesamte Ablauf und die Prozessschritte in vielen verschiedenen Tools oder Tool-Kombinationen abbilden lassen. Am besten analysieren Sie den aktuellen Ist-Stand – dabei können die mitgelieferten Fragestellungen sehr gut helfen – und starten dann Ihren Weg in Ihr persönliches Kanban. Wie am Anfang erwähnt, spielt sich Agilität jedoch nicht nur auf der methodischen Ebene ab, welche auch hier im Artikel betrachtet wurde, sondern auch weniger sichtbar in der Kultur. Von daher geht es bei der ganzen „Personal Kanban“-Thematik immer auch darum, für sich selbst die passenden Werte zu leben, egal ob dies dann irgendwelchen Scrum, Kanban oder agilen Werten entspricht.
Weitere Informationen
[All19] D. Allen, Getting Things Done: The Art of Stress-free Productivity, Piatikus, 2019
[And11] D. J. Anderson, Kanban: Evolutionäres Change Management für IT-Organisationen, dpunkt.verlag, 2011
[Ben13] J. Benson, T. DeMaria Barry, Personal Kanban, dpunkt.verlag, 2013
[DoR] t2informatik GmbH, Definition of Ready, siehe: https://t2informatik.de/wissen-kompakt/definition-of-ready/
[Scrum] K. Schwaber, J. Sutherland, Scrum Guide, Nov. 2020, siehe: https://scrumguides.org/download.html
[Wiki] Address at the Second Assembly of the World Council of Churches. Dwight D. Eisenhower (19. August 1954), siehe: https://de.wikipedia.org/wiki/Eisenhower-Prinzip
[Zuck21] A. Zucker, A Personal Retrospective, 1.1.2021, siehe: https://pmessentials.us/a-personal-retrospective/
