Brauchen agile Teams eine Zeiterfassung?

Im Mai 2019 hat der EuGH entschieden, dass die komplette Arbeitszeit von Mitarbeitern erfasst werden muss. Kurz darauf titelte die Süddeutsche Zeitung „Hilfe, die Stechuhr kommt.“ [1] Wieso soll auf einmal nicht mehr jedes Unternehmen selbst entscheiden dürfen, ob eine solche Dokumentation überhaupt Sinn macht?

Zeiterfassung als Grundrecht

Weil das Erfassen der Arbeitszeiten Arbeitnehmer vor Ausbeutung schützen soll. Laut Deutschem Gewerkschaftsbund sind im Jahr 2018 zwei Milliarden Überstunden angefallen, die Hälfte davon unbezahlt. Dabei waren die Arbeitszeiten doch schon viel lockerer geregelt als zu Zeiten der so in Verruf geratenen Stechuhr. 1998 hatte IBM (einst selbst Hersteller von Stempeluhren) dieses System der Arbeitszeiterfassung abgeschafft. Als Gründe wurden damals Vertrauen und Selbstorganisation statt Kontrolle kommuniziert. Stellt sich die Frage, wie diese Werte mit dem aktuellen EuGH Urteil zu vereinbaren sind. Können Arbeitnehmer mit Vertrauensarbeitszeit auf die Dokumentationspflicht verzichten? Rudolf Buschmann, Jurist am Gewerkschaftlichen Centrum für Revision und Europäisches Recht, beantwortet diese Frage so:

Eindeutig nein. Es geht um ein europäisches Grundrecht, begründet mit dem Ziel der gesunden, sicheren und würdigen Arbeitsbedingungen (Art. 31 Abs. 1 EU-Grundrechtscharta). Wäre dieses Recht verzichtbar, würden morgen Millionen von Arbeitnehmern in ganz Europa von ihren Arbeitgebern vorgedruckte Verzichtserklärungen präsentiert bekommen. Diese wären aber unwirksam. Hier gilt nichts Anderes als bei Versuchen, die Arbeitnehmer zum Verzicht auf tarifliche Leistungen zu drängen. [2]

Stundenzettel sind anti-agil

Wenn die Zeiterfassung in erster Linie Arbeitnehmer schützen sollte, warum hätte man sie denn dann aufgeben sollen? Einer der Väter des agilen Manifests, Jeff Sutherland, schrieb 2012 in seinem Blog Time Tracking is Anti-Scrum, dass das Weglassen der genauen Stundenerfassung administrative Zeitverschwendung minimiere, was Unternehmen generell entlaste und produktiver mache. Eine Maßnahme hin zur Lean Organization [3].

Was sollte man denn seiner Meinung nach tun, wenn man für die Rechnungs-/Angebotserstellung eine Zeiterfassung bzw. Aufwandsschätzung braucht? Sutherland empfahl eine Schätzung bzw. automatische Berechnung über Burn Down Charts mithilfe von Story Points anstelle von Arbeitsstunden. Die Schätzung der Aufwände mit Story Points ist heute weit verbreitet. Velocity Charts liefern darüber hinaus eine Prognose der Entwicklungskosten auf Basis der bisherigen Projektdurchführung. Allerdings wird dabei die Geschwindigkeit eines Teams ermittelt, nicht die Arbeitszeiten einzelner Mitarbeiter und der Wert stabilisiert sich meist erst nach ein paar Sprints.

Warum überhaupt agil?

Agiles Vorgehen macht vor allem in Projekten Sinn, in denen Anforderungen wenig konkret und volatil sind und die Technologie zur Umsetzung eher unbekannt ist.

Viel zitiert, heute aber nicht mehr ganz im Sinne ihres Erfinders: die Stacey Matrix

Wenn das Was und Wie etwas erreicht werden soll, eine große Unbekannte ist, muss man eher situativ vorgehen und sich experimentell herantasten. Das funktioniert besser, wenn man iterativ und inkrementell vorgeht. Welche Methode wann Sinn macht, wird gerne mit Ralph D. Stacey’s Matrix erklärt. Je mehr man sich im Bereich komplex oder chaotisch bewegt, desto besser greifen agile Methoden. Stacey selbst hat diese Matrix inzwischen verworfen, weil er Komplexität neu definierte. Organisationen und deren Management begreift er nicht als feststehendes „Ding“, sondern als komplexe, soziale Prozesse mit Beziehungen zwischen Menschen. Die Komplexität entstehe aus dieser Interaktion und dem generellen Vorhandensein von Paradoxien (wie z.B. Vorhersehbarkeit und Unvorhersehbarkeit), mit denen man sich auseinandersetzen müsse. [4] Komplexität ist also gewissermaßen Normalität und damit hat Stacey bestimmt nicht unrecht.

Agilität bedeutet, den Zeitaufwand gut einzuschätzen statt kleinteilig vorzuplanen

In Zeiten von VUKA braucht man deshalb Methoden, um mit Ungewissheit konstruktiv umzugehen. Erfahrungen und Analogien helfen dabei. Learning bei Doing ist die Devise. Planung ist relativ, d.h. soll sich auf das Wesentliche beschränken und Menschen arbeitsfähig machen. Mitarbeiter sollen bewusst auf Veränderungen reagieren anstatt – überspitzt dargestellt – geistlos und unmündig einem von oben festgelegten Plan zu folgen.

Deshalb soll die Planung von Aufgaben auch nicht mehr ein übergeordneter Projektmanager machen, sondern besser im Team erfolgen. Gemeinsam werden Aufwände zur Realisierung von User Stories geschätzt. Methoden wie Planning Poker oder die T-Shirt Größen-Zuordnung haben nicht den Anspruch, alle Aufwände genau im Voraus zu kalkulieren, sondern die Komplexität der Aufgaben zueinander in Relation zu setzen. Solche abstrakten Schätzungen sind weniger zeitraubend als absolute Planungen mit Arbeitsstunden einzelner Mitarbeiter. Außerdem gilt als erwiesen, dass Menschen besser relativ als absolut schätzen. So argumentiert beispielsweise auch der Buchautor und agile Coach Janko Böhm:

Wenn Sie Ihren Kollegen fragen, wie hoch ein Haus auf der gegenüberliegenden Seite der Straße ist, wird das für ihn schwieriger sein, als zu entscheiden, ob das linke Haus höher oder niedriger als das rechte ist. [5]

Im Idealfall ergibt sich aus diesen Schätzungen eine Messgröße für die Entwicklungsgeschwindigkeit (Velocity) des Teams. Denn schließlich wird nicht nur einmal vor Projektbeginn geschätzt, sondern kontinuierlich nach jedem Sprint. Der Product Owner nutzt die Velocity bei der Einschätzung des Business-Wertes der unterschiedlichen Backlog Items. Für die Vorausplanung des Mitarbeitereinsatzes ist das Schätzen schneller und pragmatischer als eine haarkleine Planung in Personentagen und Stunden, die dann vielleicht von der Realität wieder einkassiert wird.

Die Abrechnung

Aber was ist mit dem Blick zurück auf die wirklich angefallenen Aufwände? Geleistete Arbeitsstunden müssen bezahlt werden, als Dienstleister will ich eine Rechnung über konkrete Aufwände stellen. Echte Agilität mit Möglichkeit zu permanentem Change lässt sich in einem Vertragsmodell mit Abrechnung nach Aufwand vielleicht besser leben als in einem Festpreiskorsett. Da im Zeitalter von New Work nicht alle Mitarbeiter mehr projektgebunden an einem festen Platz täglich von Nine-to-Five arbeiten, sondern sich flexiblere Modelle etabliert haben, sind moderne, schlanke Zeiterfassungssysteme gefragt. Jedenfalls findet man online eine Vielzahl von Apps, wenn man „agile Zeiterfassung“ googelt. Offensichtlich gibt es dafür einen Markt. Und wenn Mitarbeiter projektübergreifend eingesetzt werden (z.B. als Team Consultants), muss man deren Arbeitsstunden zur Abrechnung irgendwo zentral verwalten.

Retrospektive

Der Blick zurück auf die Zeit, die man gebraucht hat, um eine Story zu erfüllen, hilft bei der nächsten Schätzrunde bestimmt. Auch die Velocity wird ja am Faktor Zeit bemessen, nämlich an der festen Sprintdauer. Ziel agilen Vorgehens ist es aber nicht (wie viele glauben), nur die Geschwindigkeit zu steigern und immer mehr Stories innerhalb eines Sprints zu entwickeln. Die Qualität und der Nutzen sollen im Vordergrund stehen. Wenn dafür mehr Zeit als geplant gebraucht wird, soll man sich die auch nehmen. Im Idealfall fließt die Zeit, die durch den Verzicht auf eine kleinteilige Vorkalkulation gespart wird, in die Qualität des Produktes. Trotzdem soll es agile Entwickler geben, die Story Points in Stunden umrechnen und umgekehrt. Beim gemeinsamen Schätzen überschlägt man ja auch grob Stunden oder Tage, die man vermutlich brauchen wird. Für manche Menschen wirkt die Analyse der eigenen Arbeitszeiten sogar motivierend. Wahrscheinlich gilt auch hier: Solange man die Daten, die man erfasst, produktiv nutzt, macht Zeiterfassung immer noch viel Sinn.

Quellen:

[1]  https://www.sueddeutsche.de/karriere/arbeitszeiterfassung-urteil-gesetz-1.4464438

[2]  https://www.bund-verlag.de/aktuelles~arbeitszeiterfassung-vertrauensarbeitszeit-keine-Loesung~

[3]  https://www.scruminc.com/time-tracking-is-anti-scrum-what-do-you/

[4]  https://www.youtube.com/watch?v=Ee_3Pg5zvRg

[5] Böhm, Janko: Erfolgsfaktor Agilität: Warum Scrum und Kanban zu zufriedenen Mitarbeitern und erfolgreichen Kunden führen. Springer. 2019