Bei vielen Projekten und daraus resultierenden Tasks kann man schnell den Überblick verlieren – alles pressiert, kommt kurzfristig rein, und auf nichts kann verzichtet werden. Da den überblick zu behalten ist nicht ganz einfach. Lösungen wie Scrum funktionieren nur bedingt, wenn man auf mehreren Projekten gleichzeitig arbeitet. Zeit für einen neuen Ansatz. 

In unserer Zunft arbeiten die meisten von uns auf mehreren Projekten, oft für mehrere Kunden gleichzeitig, und oftmals ausserhalb eines einzelnen Scrum-Prozesses, wo alle Tasks in Jira-Stories abgebildet werden können. Da fällt es manchmal schwer, den Überblick über alle Tasks und “To dos” zu behalten, insbesondere wenn sie nicht als Stories definiert sind. 

Kanban für den Überblick

Unter anderem dafür hat Ôno Taiichi in den Nachkriegsjahren für Toyota die Kanban-Methode erfunden. In der westlichen Welt ist sie vor allem durch das Kanban-Board bekannt (eigentlich ein Pleonasmus, denn “Kanban” bedeutet bereits “Board” oder “Tafel”). Wie dem auch sei. Das Kanban-Board hat sich bewährt, die Fortschritte in einem (halbwegs) agilen Team dazustellen, wenn auf Scrum und/oder Jira verzichtet wird. 

Ich verwende das Kanban-Board in seiner ursprünglichen Form auf einem Whiteboard mit PostIt-Zetteln, um die Tasks der verschiedenen Projekte im Griff zu haben; wo wir Jira verwenden, verweise ich auf den enstprechenden Jira-Task. Der Aufwand, das Jira-Board des Projektes und mein Kanban-Board synchron zu halten ist minimal und die Dopelspurigkeit durchaus wert. 

Ich verwende die einfachste Form des Kanban-Board und teile es nur in folgende drei Spalten auf: 

• To do: Was ich erledigen muss; 
• Doing: Woran ich gerade arbeite; das sind meist zwei bis maximal fünf Tasks gleichzeitig; 
• Done: Was erledigt ist. 

Eigentlich könnte ich auf “done” verzichten, denn schmeisse die erledigten Zettel direkt ins Altpapier, da mir der psychologische Effekt zu sehen, was bereits alles erledigt ist, nicht soo wichtig ist. Aber dennoch, man ist halt ein bisschen Traditionalist. 

Auf dem Kanban-Board trage ich übrigens auch einzelne private Tasks ein, die “Business-Charakter” haben und nicht vergessen gehen sollten, etwa das Ausfüllen der Steuererklärung oder das Schreiben eines Blog-Artikels wie diesen hier. 

So weit, so gut. Doch ich stosse immer wieder auf das gleiche Problem: Meine “To do”-Spalte quillt über, und ich verliere den Überblick, was wichtig ist, was sofort erledigt werden sollte, und jedesmal wenn ich einen neuen Task in die “Doing”-Spalte übernehmen soll, muss ich alle durchgehen und abschätzen was als nächstes gemacht werden soll. 

Einfach gesagt, es fehlt die Priorisierung. 

Priorisieren mit der Eisenhower-Matrix

Doch auch hierfür gibt es eine Lösung, sogar ein bisschen älter noch als die Kanban-Methode. Die Eisenhower-Matrix wird dem amerikanischen General und späteren Präsidenten Dwight D. Eisenhower zugeschrieben (obwohl nicht bekannt ist, ob der sie wirklich verwendet hat). 

Die Eisenhower-Matrix unterscheidet zwischen zwei verschiedenen Attributen eines Tasks: 

• Dringlichkeit (Urgency): Wie dringend muss ein Tasks erledigt werden?
• Wichtigkeit (Importance): Wie wichtig ist der Tasks?

Dabei werden Dringlichkeit und Wichtigkeit komplett unabhängig voneinander betrachtet; häufig ist es gar so, dass dringende Sachen nicht wichtig sind, oder wichtige Dinge nicht dringend sind. 

Eisenhower (bzw. der Anwender der Matrix) benutzt ein Quadrat dass er in vier Quadranten unterteilt, anhand der Achsen Dringlichkeit und Wichtigkeit: dringend: ja – nein, wichtig: ja – nein. 

Die vom Kanban-Board her bekannten PostIt-Zettel können verwendet werden, um Tasks in den vier Quadranten zu verteilen – die Priorisierung ist erstaunlich einfach, wenn man nur nach Dringlichkeit und Wichtigkeit unterscheidet. Ist dies erledigt, geht es ans abarbeiten: 

• Dringend und wichtig: Diese Aufgaben sollten sofort, bzw. als nächstes erledigt werden. Ohne Kompromisse. 
• Dringend, aber nicht wichtig: Diese Aufgaben sollten nach Möglichkeit delegiert werden; ansonsten nach “dringend und wichtig” zu erledigen.
• Nicht dringend, aber wichtig: Später erledigen; das ist gewissermassen das Backlog. 
• Nicht dringend und unwichtig: Diese werden schlicht nicht beachtet und entsorgt. 

Ich habe mich dazu entschieden, dass ich die anstehenden Tasks nicht nach Projekten bewerte, sondern alle in den gleichen Topf schmeisse – unabhängig davon, wie viel Zeit ich für ein Projekt wann reserviert habe – unter dem Strich spielt dies interessanterweise keine Rolle, und geht meist relativ gut auf, sofern die Schätzungen zur Planung halbwegs realistisch waren. 

Die GEO-Methode

Die Eisenhower-Matrix hilft mir, Tasks zu priorisieren, und eignet sich hervorragend dazu, die erste Spalte eines Kanban-Board (“To do”) abzulösen. Grafisch setze ich anstelle der ersten Spalte eines Kanban-Boards einfach eine Eisenhower-Matrix ein, et voila: 

Da dies meines Wissens (nach einer kurzen Internet-Recherche) noch niemand so wirklich offiziell versucht hat, nenne ich diesen Ansatz einfach mal “Grob-Eisenhower-Ôno-Methode” (kurz: GEO-Methode). 

Die Methode funktioniert erstaunlich gut: Ich nehme mir jeden morgen fünf bis zehn Minuten Zeit, um die Tasks in der Eisenhower-Matrix neu zu bewerten (das hilft auch, sich den Überblick ins Gedächtnis zurückzurufen) und in erster Linie die Dringlichkeit aufgrund der Deadlines anzupassen. So kann ich einfach entscheiden, welchen Task ich als Nächstes bearbeite. 

Im Gegensatz zum “normalen” Kanban-Ansatz, wo man einfach einen Task auf einen PostIt-Zettel schreibt, sind meine PostIts ein bisschen strukturierter, indem ich verschiedene Attribute verwende: 

• Projekt: Um den Task einordnen zu können, schreibe ich das Projekt zuoberst auf den Zettel. Interessanterweise ist dies aber die Information, die für die Priorisierung für mich am wenigsten wichtig ist. 
• Jira-Referenz: Gibt es ein Ticket für den Task in Jira oder einem anderen System, notiere ich die entsprechende Ticket-ID auf dem Zettel. 
• Task: Eine kurze Beschreibung des Tasks, wie es in Kanban üblich ist.
• Deadline: Ist eine Deadline vorhanden, wird sie aufgeführt, um die Dringlichkeit abschätzen zu können. 

Ich habe die Trennlinie zwischen “Wichtig” und “Nicht wichtig” durchgängig durch das Kanban-Board weitergeführt; dies erlaubt mir das Tracking von delegierten Tasks. 

Fazit

Für mich persönlich funktioniert die Methode sehr gut und erscheint mir als logische Kombination von zwei Vorgehensweisen, die wie für einander geschaffen erscheinen – deshalb wundert es mich, dass ich in der freien Wildbahn dieser Kombination noch nie begegnet bin. Vielleicht gibt es einen Haken, von dem ich noch nichts weiss?

Ob die Methode auf ganze Teams skaliert, kann ich nicht sagen, da ich dies nicht versucht habe. Aber ich würde mal sagen: warum nicht’ Auf den ersten Blick spricht nichts dagegen; die Kanban-Spalten müssten mit Swimlanes für die einzelnen Mitarbeiter ergänzt werden, die sich die Tasks aus einer Eisenhower-Matrix “für alle” beziehen. 

Wer probiert’s aus?