Slack-Time & Open Space – Nächstes Mal mit noch mehr Kuchen!
Open Friday bei sipgate – Jeden zweiten Freitag können bei sipgate alle Mitarbeiter machen, was sie für die Firma für am wertvollsten halten. Seit wir an diesem Tag jedes Mal einen Open Space – eine ad-hoc Konferenz – veranstalten, nutzen wir den Tag optimal: Wir verteilen Wissen, lösen Probleme, sammeln Ideen und haben eine Menge Meetings abgelöst. Technologien entwickeln sich immer schneller und schneller. Vorgestern war DVD, gestern brauchte man BluRay, heute streamt man nur noch. Um mit diesem Tempo mitzuhalten, muss eine IT-Firma, bzw. ihre Mitarbeiter, schnell lernen können.
Lernen erfordert (Slack-)Zeit
Träumen wir mal ein bisschen: Was wäre, wenn alle Leute in der Firma ihr Wissen teilen würden? Was, wenn Du ganz einfach alle nötigen Leute versammeln könntest, um ein bestimmtes Problem zu besprechen und zu lösen? Was, wenn Du neue Technologien unkompliziert ausprobieren könntest? Was wäre, wenn Du langweilige Meetings durch energiegeladene Sessions ersetzen könntest?
Klingt spannend? Was bist Du bereit, dafür zu investieren?
Bei sipgate investieren wir 10 Prozent unserer Arbeitszeit dafür. Jeden zweiten Freitag ermutigen wir alle Kollegen dazu, an dem zu arbeiten, was sie für die Firma am wichtigsten finden. Zusätzlich veranstalten wir jedes Mal einen Open Space, um Leute zu verschiedenen Themen zusammenzubringen. Wir machen das seit drei Jahren und sind noch immer von den Ergebnissen begeistert!
Komm mit auf eine Reise durch vier Jahre – von anfänglichen Problemen bis hin zum heutigen Stand – und erfahre, wie sich die Vorteile jeden Tag bei uns bemerkbar machen.
Kontext, bitte
sipgate ist eine Telefongesellschaft in Düsseldorf. Etwa 120 Kollegen arbeiten in wunderschönen Büroräumen in Rheinnähe. Wir sind gefühlt ziemlich weit auf dem Weg in Richtung Lean und Agil. Da es dafür keine richtige Messlatte gibt, führe ich ins Feld, dass wir pro Nase zwei Quadratmeter Whiteboard-Fläche haben, die wir auch komplett beschreiben. Jeder Mitarbeiter kann einsehen, wie viel Geld wir mit welchem Produkt verdienen. Wir lernen Team-übergreifend neue Technologien und Methoden in beeindruckendem Tempo. Wir gehen mehrmals am Tag mit Änderungen live. Aber das war nicht immer so…
Setz Dich zu mir ans imaginäre Kaminfeuer und ich verrate Dir einen der Grundpfeiler dieser erfreulichen Entwicklung: Open Friday.
Vor gar nicht allzu langer Zeit, im April 2010, hatte das sipgate-Management beschlossen, Scrum einzuführen. Damals waren wir 65 Kollegen. Die Hälfte von uns baute das tatsächliche Produkt (Web-Oberflächen, Anruf-Routing, Anbindung an externe APIs, ...). Wir reorganisierten uns also von den üblichen Wasserfall-Silos in cross-funktionale Scrum-Teams um. Die Scrum-Master hatten Doppelrollen. Ich z. B. wurde Scrum-Master zusätzlich zu meiner Rolle als User-Experience-Designer.
Mit Scrum konnten wir unsere Entwicklungszyklen massiv verkürzen. Unser CEO Tim Mois drückte es 2011 so aus: "Vor Scrum hatten wir all diese Ideen für Features, zu denen wir dann nie gekommen sind. Wir dachten, wir bräuchten doppelt so viele Entwickler. Heute, mit Scrum, können wir uns kaum genug Sachen ausdenken, damit alle Teams genug zu tun haben."
Klingt doch super, oder? Wir arbeiteten tatsächlich viel effizienter, als im Vor-Scrum-Chaos. Doch nach etwa einem Jahr, im Sommer 2011, zeigten sich die ersten Risse: Die "Verscrummten" hielten sich dabei zurück, Leuten aus anderen Teams zu helfen. Sie hatten ja ein Commitment gegenüber ihrem eigenen Team, das sie nicht gefährden wollten, selbst wenn Firmen-übergreifende Ziele darunter litten. Es gab keine Zeit, um Team-übergreifende Angelegenheiten auszudiskutieren und Entscheidungen zu treffen, die alle mittragen. Und das, obwohl wir alle an der gleichen Codebasis arbeiteten. Wissenstransfer zwischen Teams fand selten statt. Technische Innovation, neue Technologien ausprobieren, neue Ideen kurz umsetzen? Dito. Früher geschah das in den Wartezeiten. Wenn die Java-Kollegin auf den Web-Entwickler wartete, war Zeit genug für Experimente.
Sprint folgte auf Sprint und Erschöpfung machte sich breit. Wir produzierten schnell, aber das Tempo war langfristig nicht haltbar. Eine Reihe Aufgaben war in den Augen der Product Owner nie wichtig genug, um sie hoch zu priorisieren und es tatsächlich in einen Sprint zu schaffen. Darunter fielen unter anderem manuelle Systempflege, kommende Epics vorbereiten und unser internes Helpdesk pflegen.
Die Entwickler baten uns Scrum-Master um Hilfe. Wir dachten, dass Slack Time, d. h. absichtlich unverplante Zeit, die Probleme beheben müsste. Doch ist ein Zeitpuffer in Scrum nicht falsch?
Macht ein Zeitpuffer Scrum kaputt?
Ein klares Jein. Eines der Probleme waren z. B. Systeme, deren Speicher mit der Zeit voll lief und in denen man regelmäßig von Hand Daten löschen musste. In der reinen Lehre hätten wir diese Probleme alle wegautomatisieren müssen.
Da wir ziemlich viele solcher und ähnlicher Stellen hatten, hätte es sehr lange gedauert, alle zu fixen. Wir waren nicht bereit, die Entwicklung neuer Features so lange auf Eis zu legen und haben uns bewusst für Slack-Time entschieden. Im Laufe der Jahre haben wir die unschönen Stellen eine nach der anderen gefixt. Jetzt gerade fällt mir nur ein System ein, in dem wir immer noch alle paar Wochen händisch löschen.
5 Wege, Slack-Time zu schaffen
Als erstes haben wir recherchiert, wie andere Firmen Slack realisieren:
- Pause zwischen Sprints
Je nach dem, wie lange der Sprint dauert, beginnt der nächste Sprint erst vier Stunden bis zwei Tage nachdem der alte endete. - 6x2+1
Mike Cohn schlägt eine Woche Pause nach je sechs Zwei-Wochen-Sprints vor. - Entwickler-Freitag
Der Legende nach haben Entwickler bei Google jeden Freitag Zeit für Nebenprojekte. - Gold Cards
In jeder Iteration bekommt jeder Entwickler einen Gutschein, den er gegen einen "freien" Tag einlösen kann. - FedEx-Day
Einmal pro Quartal kommen alle Entwickler für anderthalb Tage zusammen um coole neue Sachen zu bauen. Heute würde man das wohl Hackathon nennen.
Nachdem wir uns alle Ansätze angeschaut hatten, war uns klar, dass wir Slack lieber öfter und kürzer wollten, statt länger und seltener. Damit waren FedEx-Day und 6x2+1 raus. Außerdem wollten wir unsere Sprints beschützen, was gegen Gold Cards sprach. Und mit am wichtigsten: Wir wollten, dass alle gleichzeitig Slack haben. Wir brauchten oft mehrere Leute aus verschiedenen Teams, um knifflige Probleme zu lösen. Das war unserem Erbe aus der Vor-Scrum-Zeit geschuldet, als noch jeder Entwickler exakt ein System betreut hatte. Schlussendlich entschieden wir uns für einen Tag Slack zwischen unseren 2-Wochen-Sprints.
Den Segen der Geschäftsführung zu bekommen war sowohl leicht als auch schwer. Es war leicht, weil sie schon länger Fans von Googles Entwickler-Freitag gewesen waren. Sie fanden nur den Druck auf die Entwickler unschön, sich ein besonders tolles Nebenprojekt zu suchen. Da bei uns Nebenprojekte nicht im Fokus standen, war das für uns kein Problem. Es war schwer, weil die Geschäftsleitung nicht überzeugt war, dass alle den Tag weise und im besten Sinne für die Firma nutzen würden. So kam es, dass sich Scrum-Master und Geschäftsführung ein kleines Regelwerk für den Slack-Tag überlegten. Dass wir die betroffenen Scrum-Teams nicht um Input baten, sollte sich als großer Fehler herausstellen. Heute finde ich es offensichtlich, dass unser geheimniskrämerischer Ansatz scheitern musste, aber damals waren wir überrascht von der Ablehnung die uns entgegenschlug.
1. Versuch: Hallo NDS!
Im Juli 2011 präsentierten wir Scrum-Master frohen Mutes die Regeln für einen zweimonatigen Probelauf für den Slack-Tag: Der erste Tag eines jeden Sprints wurde ein Entwickler-Tag. Sprints endeten am Mittwoch, der Slack-Tag war also jeder zweite Donnerstag. Wir nannten den Tag "NDS" ("Nach dem Sprint"), ein Zufallsname, damit der Tag nicht zu eng interpretiert werden würde. Entwickler konnten tun, was auch immer sie machen wollten, solange es einen Bezug zur Arbeit hatte: Research, manuelle Systempflege, Nebenprojekte, Impediments beseitigen, …
An den NDS-Tagen trafen wir uns morgens in einem großen Kreis. Reihum berichteten alle, woran sie arbeiten würden, damit andere sich einbringen konnten. Leute, die weder Ideen hatten, noch bei anderen helfen wollten, konnten als Fallback an Stories arbeiten. Nachmittags wiederholten wir den Kreis, diesmal, um Ergebnisse auszutauschen. Zur Feier des Tages gab es Kuchen. Außerdem baten wir die Entwickler, ihre Themen und Ergebnisse in einem Spreadsheet einzutragen, als Erinnerung für sich selbst und andere.
Der Slack-Tag wurde nicht so begeistert angenommen wie gehofft. Obwohl der Wunsch ja mal von den Entwicklern gekommen war, fühlten sie sich vom Anfangs- und Abschlusskreis, sowie dem Spreadsheet gegängelt. Sie hatten sehr feine Antennen für den Mangel an Vertrauen, der da mitschwang. Der Anfangskreis war meist noch recht gut besucht. Der Abschlusskreis war dagegen eher bröselig. Und nach ein bisschen Anfangs-Enthusiasmus, kehrte die alte Sprint-Müdigkeit schon bald zurück.
2. Versuch: NDS 2.0 oder: Schlimmer geht immer
Alle agilen Prinzipien, denen wir normalerweise folgten, brachen beim NDS in sich zusammen. Woran wir arbeiteten war absolut intransparent. Die Ideen für den Tag waren überwiegend spontan und unausgegoren. Wir fingen viel an und schlossen wenig ab. Viele arbeiteten allein und manchmal war plötzlich etwas live, was nie mit irgendwem – z. B. einem Product Owner – besprochen worden war.
Diese Probleme wollten wir mit noch mehr Regeln beheben. Ab sofort mussten alle ihre Pläne für den NDS als User-Story formulieren und am Tag vorher "einreichen", um die Ideen durchdachter zu machen. Außerdem musste man paarweise arbeiten, damit klar war, dass mindestens zwei Leute eine Idee wichtig fanden.
Die zusätzlichen Regeln halfen natürlich wenig. Der NDS blieb intransparent und die Beteiligten fühlten sich noch gegängelter. Es war klar, dass wir das Potenzial des Tages nicht ausschöpften. Die Geschäftsführung erwog mehrere Male, den NDS einzustampfen, aber insgesamt brachte der Tag mehr als er kostete. Es löste ein paar unserer Probleme, wie manuelles Aufräumen und Ausloten neuer Technologien. Zu diesem Zeitpunkt waren wir ein bisschen Scrum- und Veränderungsmüde. Mangels besserer Ideen behielten wir den NDS bei. Als die Teams aufhörten, alle synchron zu sprinten, schoben wir den NDS auf den Freitag, aber das war es auch schon.
3. Versuch: Lang lebe der Open Friday!
Es sollte ein Jahr dauern, bis Stefan – einer der Web-Entwickler – etwas besseres entdeckte. Im August 2012 besuchte er ein BarCamp und verliebte sich in das Open Space-Format. Mit Open Spaces kann man sehr spontan ein Programm für mehrere Räume und Zeitslots aufstellen. Das Programm sieht dann ähnlich aus, wie bei einer Konferenz, aber "offener". Die Anwesenden schlagen während der Eröffnung Sessions vor. Dazu schreiben sie ihr Thema auf ein großes Post-It, stellen es kurz vor und suchen sich für ihre Session einen Raum/Zeit-Slot auf dem Programm-Board aus.
Beispiel: Sessions vom 8. Mai 2015
- Fraud verhindern
- Pattern Library Retro
- Lohnabrechnung
- lunch@sipgate.de
- simquadrat - Kommunikation mit Kunden
- IPv6 @ sipgate
- Git
- Rufnummern-Migration
- Teamphasen / Teamuhr
- sipgate(.io) @ Konferenzen
Wenn der Zeitslot gekommen ist, versammeln sich alle am Thema Interessierten im entsprechenden Raum, um das Thema zu besprechen. Wer die Session vorgeschlagen hat, muss hinterher eine Zusammenfassung der Ergebnisse veröffentlichen. Stefan schlug vor, am NDS einen Open Space zu veranstalten. So kam es, dass der erste "Open NDS" im Oktober 2012 stattfand. Er dauerte einen halben Tag und etwa 20 Leute (die Hälfte aller Verscrummten) waren dabei. Sie veranstalteten wegweisende Sessions und Open NDS war ein großer Erfolg. In Stefans Nachlese-Email stand das so:
"tl;dr: NDS mit Open Space war großartig – machen wir nochmal. Jeder soll kommen! Nächstes Mal mit noch mehr Kuchen!"
Historische Worte! Wir haben seitdem an jedem Slack-Freitag einen Open Space veranstaltet. Ein Product Owner hat den Tag versehentlich in "Open Friday" umbenannt und dabei sind wir geblieben. Der Open Space geht immer von 10 bis 16 Uhr. Obwohl er von Anfang an für alle Mitarbeiter war, zögerten Leute von außerhalb der Scrum-Teams anfangs teilzunehmen. Heute nehmen an jedem Open Friday etwa 2/3 aller Kollegen teil. Am schwierigsten ist es für unsere Kundenbetreuung, die eine Hotline zu besetzen hat. Dafür haben wir bisher keine Lösung. Daher rotieren die Kundenbetreuer und jeder einzelne kann nur jeden 2. oder 3. Open Friday mitmachen.
Warum war Open Friday erfolgreich und NDS nicht?
Das Session-Board spielt eine große Rolle, weil es erlaubt, mehrmals am Tag Themen und Gruppen zu tauschen, anstatt sich wie beim NDS morgens einmal für den ganzen Tag festzulegen.
Der Open Friday ist auch Nutznießer des stark gewachsenen Vertrauens zwischen allen Gruppen in der Firma. Das Session-Board fördert das Vertrauen weiter, durch hohe Sichtbarkeit und Transparenz. Das gleiche gilt für die Dokumentation: Open Space ist ein externes Format. Darin sind die Session-Zusammenfassungen festgelegt. Also schreiben wir die Zusammenfassungen und haben ein durchsuchbares Archiv aller Sessions, um nochmal etwas nachzuschauen. Im Gegensatz zum ungeliebten und ignorierten NDS-Spreadsheet funktioniert es hier gut.
Zu guter Letzt hilft es enorm, dass Kollegen aus der ganzen Firma teilnehmen – Marketing, Buchhaltung, Kundenbetreuung, User Experience, Entwickler, Admins, Geschäftsführung. Ich dachte schon vor dem Open Friday, dass bei uns alle eng zusammenarbeiten. Open Friday hat das nochmal auf ein ganz anderes Level angehoben. Das hätten wir weder vorhersehen noch planen können.
Teilnahme ist 100 Prozent freiwillig.
Was uns der Open Friday bringt
Open Friday hat unsere Probleme von 2011 in höherem Maße als der NDS gelöst. Darüberhinaus organisieren wir so gegenseitige Hilfe über Teams und Abteilungen hinweg. Wir haben kaum noch normale Meetings. Die meisten Sachen werden Open Friday-Sessions, weil sie so einfach zu organisieren sind. Am Open Friday hat jeder Zeit! Man braucht auch nicht mehr aufwändig herauszubekommen, wer an einem Meeting Interesse hat. Wer da ist, ist da. Wer nicht, der nicht. Anwesenheit ist 100% freiwillig. Dadurch sind Open Friday-Sessions sehr viel engagierter und energiegeladener als Meetings mit unwilligen Pflichtanwesenden.
Der Open Friday ist unser bevorzugter Weg, Wissen weiterzugeben und Neues auszuprobieren. Bei uns zeigen alle überdurchschnittlich viel Initiative, weil uns der Open Friday erlaubt, die Sachen zu ändern, die wir doof finden. Wir können klären, ob noch andere das Problem teilen, uns Hilfe suchen und Entscheidungen treffen. Weil alle am Open Friday teilnehmen, fließen Infos frei zwischen den Abteilungen und Empathie entsteht. Wenn wir ein Problem haben, ist die Lösung tendenziell nur einen Open Friday weit weg.
Vielleicht auch noch interessant: Eine Session vorzustellen und zu moderieren gibt vielen die Gelegenheit, Leadership-Fähigkeiten zu üben.
Oh, und habe ich Spaß erwähnt? Nein? Nun, Spaß! Wir haben ihn. Viel davon!
Was wir gelernt haben
Es zahlt sich aus, einen regelmäßigen Tag zu haben, an dem alle – nicht nur Scrum-Teams – Zeit haben. Open Space hilft uns dabei, diese Zeit so zu strukturieren, dass Themen und Interessierte zueinander finden. Open Friday gibt jedem die Gelegenheit, seine Ideen umzusetzen und voranzubringen. Ein tolles Gefühl!
Und das könnt ihr auch in klein ausprobieren. Es muss ja nicht direkt regelmäßig ein ganzer Tag sein. Alles was Ihr braucht, ist ein Nachmittag, ein Whiteboard, Post-Its und Marker und Leute die Lust haben, mitzumachen. Viel Spaß!
