Amerikanische Unternehmen haben es vorgemacht, und immer mehr deutsche Teams ziehen nach. An einem Tag in der Woche hat der Entwickler die totale Freiheit, zu tun, wozu auch immer er Lust hat. Wir versprechen uns davon, dass unsere Entwicklerkollegen Spaß an ihrer Aufgabe haben, dass Sie sich an diesen Tagen weiterbilden, und tolle Ideen für neue Produkte, weil das bei Google so gut funktioniert hat. Oft genug bringt die ganze Sache aber viel weniger als wir erwarten. Weil wir es falsch angehen, oder weil wir das Falsche erwarten?
Bei Google hatte ein ganzes Heer von Entwicklern über Jahre die Möglichkeit zur freien Entfaltung. Herausgekommen ist eine Handvoll Produkte. Wenn Sie das auf die Größe Ihres Teams umrechnen, können Sie wirklich froh sein, wenn sich bei der ganzen Sache auch nur eine zu vermarktende Idee ergibt. Wenn das bei Ihnen der Fall sein sollte, freue ich mich für Sie. Dennoch sollte es nicht das Ziel des Tu-was-du-willst-Tages sein, die neue Gelddruckmaschine für das Unternehmen zu erfinden. Tolle Sache, wenn ein Entwicklerkollege eine gute Idee für ein neues Produkt hat. das ist jedoch nicht unser Ziel des freien Freitags, also ignorieren wir das in unseren zukünftigen Überlegungen.
Was wollen wir also?
1. Unsere Kollegen können sich mit Dingen beschäftigen, für die sie normalerweise keine Zeit haben, es sei denn, sie nutzen ihre Abende oder Wochenenden. Das bezieht sich vor allem auf Weiterbildung.
2. Unsere Kollegen können mit Spaß an einem Projekt arbeiten, in dem sie selbst alles bestimmen – von der Art über die Architektur bis zur Implementierung. Dabei beschäftigen sie sich zwangsläufig auch mit Dingen, mit denen sie sich an normalen Tagen nicht beschäftigen können. Sie lernen also dazu.
Wie Sie sehen, läuft es letzten Endes darauf hinaus, dass sich ein Entwickler am freien Freitag voran bringt. Er lernt neue Technologien kennen, arbeitet sich in Architekturfragen ein und verwaltet sich dabei selbst. Noch besser ist es, wenn zwei oder mehr gemeinsam an einem Projekt arbeiten. Ich erwarte von meinen Entwicklerkollegen nicht, dass sie tolle Ideen für neue Projekte entwickeln. Ich erwarte, dass sie sich selbst entwickeln. Wenn sie das tun, dann ist der freie Freitag ein Erfolg.
Man mag nun entgegnen, dass Weiterbildung im Idealfall in der Freizeit zu erfolgen habe, und dass es nicht Aufgabe des Unternehmens sei, den Angestellten dafür Raum zu geben. Dem gegenüber steht der wunderbare Begriff Work-Life-Balance und die simple Tatsache, dass dem einen oder anderen dazu die Möglichkeit fehlt. In einem meiner letzten Projekte hatte ich eine alleinerziehende Mutter in meinem Team. Wie soll man sich in seiner Freizeit weiterbilden, wenn man sich dann um ein Kind kümmern muss?
Die Mutter ist ein besonderes Beispiel. Viele Kollegen hätten die Zeit, sich abends oder am Wochenende in neue Dinge einzuarbeiten, aber widerspricht das nicht dem Grundsatz, dass Scrum auch den Entwickler schonen will, weil wir wissen, dass man nur entspannt und ausgeruht das Beste aus sich herausholt? In diesem Zusammenhang wird der freie Freitag zum gern genutzten Argument von den Unternehmen, die mit Work-Life-Balance für sich werben. Gute Softwareentwickler können sich ihre Jobs aussuchen. In Städten wie Hamburg überbieten sich daher Softwarehäuser sowohl bei der Bezahlung als auch bei Benefits und eben diesem für viele immer wichtiger werdenden Faktor Work-Life-Balance.
Den freien Freitag kann man nun als reines Verkaufsargument betrachten. Dafür wäre er allerdings ziemlich teuer, wenn ein Fünftel der Zeit unserer Kollegen nicht dem Unternehmen gehört. Ich ziehe es also vor, ihn stattdessen als einen Tag gegenseitigen Nutzens zu betrachten. Der Entwickler bekommt Zeit zu seiner freien Verfügung, das Unternehmen bekommt bessere Entwickler. Um das zu erreichen, sollte man den freien Freitag jedoch nicht einfach so auf die Kollegen loslassen. Das geht meistens schief.
Oft genug sehe ich, dass die Euphorie schon nach kurzer Zeit schwindet, und der Tag zur freien Verfügung irgendwann wieder gestrichen wird, weil alle den Eindruck haben, dass es nicht viel bringt. Die Geschäftsleitung war sowieso immer skeptisch, die Entwicklungsleitung sieht keine echte Weiterentwicklung im Team, und die Entwicklerkollegen wissen am freien Freitag nichts mit sich anzufangen.
Der Grund ist in aller Regel die mangelnde Begleitung. Den Teammitgliedern wird gesagt, dass Sie einen Tag in der Woche zu ihrer freien Verfügung haben, und dann lässt man sie mit ihrer Zeit und ihren Überlegungen allein. Die Kollegen fragen sich nun, was sie an diesem Tag machen sollen, und kommen nur selten zu einem Ergebnis. Am Anfang fühlt man sich noch verpflichtet, irgendetwas Sinnvolles zu tun, und liest sich in eine neue Bibliothek ein oder bastelt ein Miniprojekt, dass den Teamkollegen das Leben erleichtert, ein Deployscript oder Ähnliches. Nach ein paar Wochen sind alle Löcher scheinbar gestopft, man kann sich auch nicht ständig in eine Bibliothek einlesen, so beginnt man bald damit, zum Solitärprofi zu mutieren. Irgendwann kommt die Geschäftsleitung vorbei und fragt die Entwicklungsleitung, was sich am freien Freitag so tut, diese kann nur mit den Schultern zucken. Man fragt dann die Entwicklerkollegen, was eigentlich Sache ist, diese zucken aber auch nur mit den Schultern, und bald wird der freie Freitag wieder gestrichen.
Das Problem dabei ist nicht, dass wir nur Faule Säcke in unserem Team haben, die lieber Tetris spielen, als sich mit irgendeiner neuen spannenden Sache zu beschäftigen, das Problem ist, dass wir sie dabei vollkommen allein lassen. Softwareentwickler sind es nicht gewohnt, dass Sie selbst vollkommen frei über ihre Projekte entscheiden können. Der eine oder andere hat ein Hobbyprojekt, um das er sich an den Abenden oder am Wochenende kümmert. Das möchte er aber nur selten ins Büro tragen. Das neue Verwaltungssystem für die ganzen aus dem Web heruntergeladenen Filme und Musikdateien möchte man nicht unbedingt im Büro weiterentwickeln.
Ich rate Ihnen dazu, den freien Freitag, nicht einfach auf ihr Team loszulassen, sondern ihn mit angezogener Handbremse einzuführen. Holen Sie ihre Kollegen zusammen und sagen Sie Ihnen, dass sie sich an einem Tag in der Woche mit Dingen beschäftigen können, die sie selbst bestimmen. Sie können dabei vorgehen, wie sie wollen, und sie können sich dabei organisieren, wie sie wollen. Das Wie ist nur selten die Schwierigkeit. Das Was ist viel schwerer.
Tragen Sie anfänglich gemeinsam mit ihren Kollegen Ideen zusammen. Fragen Sie gezielt nach kleinen Lösungen, die Ihnen des Leben als Entwickler im Unternehmen erleichtern würden. Wichtig ist, dass Sie Ihrem Team einen Ansatzpunkt geben und es nicht vollkommen frei in der Luft schweben lassen. Sehr schön finde ich den Ansatz, dem Team ein Projekt vorzuschlagen, alles Weitere jedoch komplett offen zu lassen. Das sollte auch keine Vorgabe sein, machen Sie lediglich einen Vorschlag, wenn das Team keine eigenen Ideen entwickelt. Besonders begeisterungsfähig sind die Kollegen häufig bei Dingen aus den Bereichen Gaming oder Medien.
Sie sollten als Ansprechpartner verfügbar sein, so dass jeder Entwickler sich mit Ihnen beraten und austauschen kann. Helfen Sie nach, wenn die Kollegen keine eigenen Ideen entwickeln, aber achten Sie darauf, nichts vorzugeben. Sie werden feststellen, dass Sie sich im laufe der Zeit immer weiter zurückziehen können. Meistens braucht es nur etwas Starthilfe.
Vermeiden Sie es, den Jungs und Mädels zu häufig über die Schulter zu schauen. Das erweckt den Eindruck von Kontrolle und nimmt damit viel von der Leichtigkeit, die wir erreichen möchten. Kümmern Sie sich als Product Owner, Scrum Master oder Entwicklungsleiter um ihre eigenen Dinge. Seien Sie verfügbar, wenn man Sie nach Ihrer Meinung fragt oder um Hilfe bittet.
Nun scheint es so, dass die ganze Sache viel Vertrauen von Ihrer Seite voraussetzt. Sie geben einem kompletten Team einen ganzen Tag in der Woche, von dem Sie nicht wissen, ob nicht vielleicht alle nur Tetris spielen. Wenn Sie diese Befürchtung haben, müsste sowieso an der Vertrauensbasis zwischen Ihnen und dem Team gearbeitet werden – ohne gegenseitiges Vertrauen lassen sich Agile Methoden nur schwer einsetzen. Früher oder später sollten die Kollegen allerdings auch die Ergebnisse präsentieren.
Ich mache es gerne so, dass an jedem dieser freien Freitage ein oder zwei Kollegen (je nach Teamgröße – jeder sollte so alle vier oder fünf Wochen mal dran sein) ihre Projekte dem Team vorstellen, Fragen beantworten und einen kurzen Blick unter die Haube ermöglichen. Stellt sich dabei heraus, dass man sich mit Technologien beschäftigt hat, die auch für andere interessant sein dürften, kann man eine Schulung vereinbaren.
Machen Sie Ihrem Team von Anfang an klar, dass es vollkommen egal ist, womit sie sich an diesem Tag beschäftigen. Es sollte nur in irgendeiner Weise etwas mit dem Job zu tun haben. Ein Kollege hat sich einmal über Wochen tiefer in die SEO-Thematik eingearbeitet. Er hat nicht eine Zeile Code geschrieben, sondern nur viel gelesen. Nach einiger Zeit hat er die wichtigsten Grundlagen seinen Kollegen in einer zweistündigen Schulung vermittelt. Auch das kann an einem freien Freitag herauskommen.
