Agile Success Stories: Side Project Time

Karte: Open Street Map - CC BY-SA 2.0

Weiter geht es mit den "agilen Erfolgsgeschichten". Der Grund für ihre Veröffentlichung bleibt der gleiche: wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen, und schlimmstenfalls eine negative Weltsicht entwickeln. Wer sich die durch agile Praktiken und Methoden erzielten Erfolge und Fortschritte vergegenwärtigt, wird sich dagegen leichter damit tun, erfolgreich für sie zu werben.

Zu den Mythen die seit einiger Zeit durch die Arbeitswelt wabern, gehört der, dass Silicon Valley-Firmen (vor allem Google) ihren Mitarbeitern angeblich 20 Prozent ihrer Arbeitszeit zur freien Verfügung stellen, und dass zentrale Produkte wie Adsense und Google News in dieser Zeit "selbstorganisiert entstanden" sind. Zum Wahrheitsgehalt dieser Aussagen findet man unterschiedliche Aussagen, wahr ist aber, dass viele Firmen inspiriert davon ihren Mitarbeitern eine ähnliche, so genannte "Side Project Time" gewähren.

Eine dieser Firmen durfte ich eine Zeit lang begleiten. Die Zeit, die den Entwicklern hier für selbstgewählte Nebenprojekte (→ Side Projects) zur Verfügung stand, war vier Stunden pro Woche, plus längeren Zeiträumen für die in den Ferien arbeitenden Rumpfteams. Die Sinnhaftigkeit dieser Regelung wurde von anderen Abteilungen regelmässig in Frage gestellt, was irgendwann dazu führte, dass die Ergebnisse aller derartigen Seitenprojekte gesammelt und zur Überprüfung veröffentlicht wurden.

Angesichts der Grösse von mehreren hundert Entwicklern war natürlich ein gewisser Anteil an Unsinn dabei, wie z.B. ein Chatbot, der auf alle Fragen zu Konkurrenzunternehmen mit wüsten Beschimpfungen antwortete, oder ein Zufallsgenerator für die Erstellung möglicht absurder User Stories, es gab aber auch einige Ergebnisse, die auch den grössten Kritikern Respekt und Anerkennung abnötigten, und dafür sorgten, dass die Side Project Time erhalten blieb.

Einige Entwickler hatten sich z.B. gemeinsam der Aufgabe verschrieben, die technischen Probleme zu beseitigen, die bis dahin dazu geführt hatten, dass ein Grossteil der Meetings deutlich verspätet begonnen hatte. Als Lösung hatten sie jeden Meetingraum mit einem Computer versehen, der fest mit Beamer und Internet verbunden war und einen eigenen Videoconferencing-Account hatte. Ab da musste man nur den Raum betreten, den Rechner anschalten, und es konnte losgehen.

Ein Team hatte eine Intranet-Website gebaut, auf der alle, die sich dort anmeldeten, zu nach Zufallsprinzip erstellten Mittagessens-Verabredungen zusammengebracht wurden. Auf diese Seite entstanden Bekanntschaften kreuz und quer durch das ganze Unternehmen, wodurch abteilungübergreifende Zusammenarbeit und die Suche nach Ansprechpartnern für selten behandelte Themen deutlich vereinfacht und beschleunigt werden konnten.

Eine weitere Gruppe hatte ein Wiki zu den Kantinen, Restaurants und Imbissbuden der Umgebung aufgesetzt, mit Informationen zu Auswahl und Qualität, aber auch zu Stosszeiten, Geschwindigkeit der Bedienung und der Möglichkeit zu bargeldlosem Bezahlen. Das durch Umfragen festgestellte Ergebnis waren kürzere Mittagspausen, in denen gleichzeitig aber mehr Zeit für Essen und Unterhaltungen zur Verfügung stand als vorher.

Das (intern ) bekannteste Ergebnis erzielte aber das Nebenprojekt, in dem einige Entwickler im Firmen-eigenen Auslieferungslogistik-Leitsystem das für betriebliche Anwendungen kostenpflichtige Google Maps durch das kostenlose Open Street Maps ersetzt hatten. Besonders ein Feature erregte Aufsehen: ein Dashboard, mit dessen Hilfe man für beliebige Zeiträume überprüfen konnte, wieviel Geld durch die Ersetzung von Google Maps gespart worden war - er waren auf Dauer erhebliche Summen.

Wass all diese Side Projects gemeinsam hatten, entsprach genau den Gründen, wegen denen ihnen selbstorganisiert abrufbare Zeit eingeräumt worden war: sie wären im Rahmen des offiziellen Priorisierungsverfahren niemals auf den Roadmaps der Teams gelandet, sie lösten konkrete Probleme, mit denen die Entwickler regelmässig zu kämpfen hatten, und sie sorgten in erkennbarem Ausmass für Effektivitätssteigerungen, Kostenersparnisse und höhere Mitarbeiterzufriedenheit.

Ein Manager fasste es irgendwann passend zusammen: "Sich darauf einzulassen war am Anfang ein Wagnis, und ein bisschen unheimlich ist es mir bis heute. Aber wenn ich mir die Ergebnisse ansehe, dann kann ich gar nicht anders, als dafür sein, dass wir das weitermachen - und das selbst dann, wenn wir auch die nicht so gut verlaufenden Nebenprojekte in die Gesamtbetrachtung mit einbeziehen." Sehr viel besser kann man es vermutlich nicht formulieren.