Neulich hatte ich eine Kollegin (könnte auch ein Kollege gewesen sein) bei mir sitzen, mit der ich viel zu tun habe. Wir sprachen über einige gemeinsame Aktionen, wo es nicht so recht voran geht. Warum geht es nicht voran? Und was können wir tun, damit es besser voran geht?
Mit fast derselben Frage kommen bisweilen Kunden in Projekten, meist nicht explizit als Aufgabe, sondern oft als Problemstellung, die irgendwo implizit herum wabert.
Wir unterhalten uns. Wir, das sind zum Beispiel Kollege Maier und Kundin Mustermann. Bisweilen gibt es eine Software, mit der gemeinsam auf anstehende Aufgaben geschaut wird, wie zum Beispiel das Ticket-System „Jira“. Das hat schon mal den Vorteil, dass ja eigentlich alles transparent sein könnte, was ansteht. Eigentlich und könnte. Trotzdem sitzen Herr Maier und Frau Mustermann vor ihren Jira-Boards, schieben virtuelle Karten hin und her und kommen nicht weiter.
Herrn Maier gefällt das nicht, denn er möchte gerne mehr schaffen, mehr erledigt kriegen, ohne noch länger im Büro zu sitzen. „Was soll ich denn noch machen, Herr Schlosser, der Tag muss ja mal enden.“
Wir sind ja meist für Projekte da, doch Projekte bestehen eben aus Menschen, die gemeinsam etwas erschaffen. Und deshalb geht es in letzter Konsequenz meistens um die Menschen in diesen Projekten. Also hilft es dem Projekterfolg auch, wenn einem einzelnen Menschen geholfen werden kann, der eine sehr zentrale Rolle hat. Quasi das christliche Motiv: „Was ihr dem geringsten Mitmenschen getan habt, das habt ihr mir getan.“
Warum geht es nicht voran?
Mit dem erkennbaren Umstand, dass Dinge nicht voran gehen, ist oft das Gefühl verbunden, dass Menschen sich überfordert fühlen, oder zumindest aufgabenmäßig überfüllt.
Klar, Menschen haben faktisch eine unterschiedliche Arbeitsbelastung, deutlich mehr wirkt noch die gefühlte Arbeitsbelastung. Wieso nehmen Menschen ihre Aufgabenvielfalt unterschiedlich wahr?
Wenn wir auf die Aufgabenlisten oder Jira-Boards schauen, dann stellen wir oft zwei Dinge fest:
- Der Titel der Aufgabe benennt ein Thema, bestenfalls eine Idee, bleibt darin aber bestenfalls unklar.
- Das Ziel der Aufgabe ist nicht definiert, und somit weiß niemand, was das „Fertig“-Kriterium der Aufgabe ist.
Wir haben also viele Tickets im Jira stehen, bei denen zwar der Eigner auf Nachfrage sagen kann, was denn Inhalt der Aufgabe ist, aber ihr eben nicht ganz klar ist, woher sie weiß, dass sie die Aufgabe tatsächlich so abgeschlossen hat, wie es gedacht war.
Oft ist auch dem Eigner der Aufgabe selbst nicht ganz präsent, was genau der Inhalt oder das Ziel der Aufgabe sein soll.
Das Problem ist also: Unklarheit.
Unklarheit über das Wesen der Aufgabe. Unklarheit über das Erfolgskriterium der Aufgabe.
Mir selbst geht das bisweilen genauso wie Herrn Maier oder Frau Mustermann. Da sitze ich da wie der Ochs vor dem Berg und kriege das Zeug nicht weg. Betrachte ich mir das Wesen des „Zeugs“, dann muss ich erkennen, dass ich zu wenig Klarheit geschaffen oder eingefordert hatte. Und dann geht es meinem Gehirn wie jedem anderen: Eben mal eine konkrete, zielgerichtete Handlung aus einem Berg an undefiniertem zu ziehen geht halt nicht ohne den Zwischenschritt der Klärung.
Klarheit schaffen
Ich will hier kein Produktivsystem aufsetzen, auch wenn ich selbst seit vielen Jahren Getting-Things-Done von David Allen für mich angepasst und in Verwendung habe. Klarheit schaffen auch die Lehren der „7 Wege zur Effektivität“ von Stephen R. Covey, und die Praktiken aus Scrum von Jeff Sutherland und Ken Schwaber, insbesondere in der Ausprägung von Boris Gloger.
Klarheit in der Aufgabenbeschreibung: Aktiv und spezifisch
David Allens „Getting Things Done“ [1] hat einige ganz wesentliche Hinweise in Sachen Aufgaben:
- Eine Aufgabe hat ein Verb. Erst das Verb impliziert eine Handlung.
„Workshop Kunde X“ ist keine Aufgabe. „Workshop für Kunde X vorbereiten” kann eine Aufgabe sein, „Workshop für Kunde X terminieren” eine andere. Ich empfehle – und halte mich bisweilen auch selbst daran – die Aufgabe immer mit einem Verb beginnen zu lassen.
Es heißt also:- „Vorbereiten Workshop für Kunde X“
- „Terminieren Workshop für Kunde X“
- „Bestellen Material für Workshop für Kunde X“
- Eine Aufgabe ist allein stehend verständlich. Sie ist spezifisch und kontextfrei.
„Terminieren Workshop“ ist keine Aufgabe, sondern ein Fragment. „Website aktualisieren“ auch nicht, sondern missverständlich.
„Terminieren Workshop Kunde X“ ist spezifisch, weil ich sofort sehe, um welchen Workshop es geht.
Die Forderung, eine Aufgabe solle kontextfrei sein, bezieht sich also darauf, dass ich den Titel der Aufgabe auch als allein für sich stehende Zeile verstehen können sollte, und nicht nur, wenn die Aufgabe unter dem Kunden oder unter der Kapitelüberschrift des Kundenprojekts steht.
Mehr ist es nicht, wir wollen ja die Sache nicht verkomplizieren.
Klarheit in der Fertigstellung: Definition of Done
Gerade dann, wenn du mit anderen zusammen arbeitest, hat oft Frau Mustermann etwas anderes als gewünschtes Ergebnis im Sinn als Herr Maier. Thematisieren die beiden dies nicht, arbeiten sie wahrscheinlich oft aneinander vorbei. Das führt zu Mehrarbeit, Zeitverlust und Frust. Und das alles nur, weil die beiden nicht genug Klarheit haben über das, was am Ende stehen soll.
Drei Selbstführungsprinzipien aus drei Schulen weisen alle auf dasselbe hin:
- Stephen R. Covey [2] hat für die Klarheit in der Fertigstellung eine Gewohnheit geschaffen: Am Anfang schon das Ende im Sinn haben.
- Sutherland/Schwaber [3,4] haben in Scrum einen wesentlichen Begriff im Kontext der Softwareentwicklung geschaffen, der aber in ziemlich allen Lebenslagen passt: Definition of Done. Und Boris Gloger hat diesen Begriff in [5] noch prägnanter gefasst.
- Peter Drucker [6] und Andy Grove [7] sagen es in der Definition der S.M.A.R.T. Objectives: Messbar soll ein Objective sein.
Wie will ich eine Aufgabe erfüllen, wenn ich gar nicht weiß wohin? Positiv gefragt braucht eine Aufgabe genau die Antwort auf folgende Frage:
- Woher weiß ich, dass ich mit der Aufgabe fertig bin?
Die Antwort darauf hilft bereits sehr weit. Denn die Unsicherheit wird beseitigt. Ist die Antwort darauf „nie“, dann ist es keine Aufgabe, sondern ein Verantwortungsbereich. - Was ist der Liefergegenstand und wo lege ich diesen ab?
Liefergegenstand ist so ein hässliches Wort, aber so nützlich. „Konzept“ ist kein Liefergegenstand, „Konzeptdokument in Projekt-Ablage“ schon. Der Liefergegenstand einer Terminvereinbarung ist beispielsweise eine bestätigte Outlook-Termineinladung. Liefergegenstand einer Workshopvorbereitung kann eine handschriftliche Agenda mit Stichpunkten zu Zielen und Auswahl der Moderationsmittel sein.
Beide Fragen lesen sich auf den ersten Blick sehr technokratisch, haben jedoch eine große Auswirkung aufs Gefühl. Denn mein Gehirn möchte ja immer wissen: „Wie kann ich in der Aufgabe gewinnen? Geht das weg? Habe ich eine Chance?“ Und ohne eine Definition, was das Erfolgskriterium ist, kann unser Denken oft nicht spezifisch genug eine Lösung ersinnen.
Ich brauche das nicht zu allen Zeiten und in allen Aufgaben, aber wenn ich bei einigen Aufgaben hänge, dann meist daran.
In den meisten Aufgabensystemen, egal ob Outlook-Aufgaben oder Jira-Tickets gibt es ein Feld für ergänzenden Freitext. In Jira wird oft sogar explizit ein Feld angelegt, das dann beispielsweise „Testspezifikation“ oder sogar explizit „Definition of Done“ benannt ist. Nutze dies.
Klar werden – klar bleiben
Klar ist auch: Das gelingt nicht immer. Ich vergesse das bisweilen, oder es schleichen sich Nachlässigkeiten ein. Wenn ich aber dann erkenne, dass ich nicht mehr durchblicke, dann liegt das meist genau daran: an fehlender Klarheit über das Wesen der Aufgabe und der Definition of Done.
Oft sagen Menschen, es würde ja reichen, dass sie wüssten, was zu tun ist, sobald sie den abstrakten Titel der Aufgabe lesen. Das kann schon sein, doch wenn das Gehirn diese Denkleistung jedes mal bei der Durchsicht der Dutzenden von Aufgaben erbringen muss, wird es schwierig. Ist dann auch noch jedes Mal zu denken, was denn das Ziel und den Zustand der Erledigung kennzeichnet, gerät das Hirn rasch in Überforderung.
Schreib es auf, spezifisch und messbar. Die Aktion und die Definition of Done. Das hat erstmal nichts mit agil, mit Scrum oder mit Kanban zu tun. Das ist nur ein Gedanke, der die geistige Gesundheit bei der Arbeit fördert.
Photo: www.joachimschlosser.de, License Creative Commons Attribution Share-Alike
Literatur
- [1] David Allen – Getting Things Done. Meine GTD-Rezension.
- [2] Stephen R. Covey – 7 Habits of Highly Effective People. Meine 7Habits-Rezension.
- [3] Sutherland/Schwaber – Software in 30 Tagen
- [4] Jeff und JJ Sutherland – Scrum. Die Kunst, doppelt so viel Arbeit in der halben Zeit zu schaffen. Meine Scrum-Story-Rezension
- [5] Boris Gloger – Scrum: Produkte zuverlässig und schnell entwickeln
- [6] Peter Drucker – Was ist Management? Das Beste aus 50 Jahren
- [7] Andy Grove – High Output Management
Schreibe einen Kommentar