Blog

(die #coronalearnings von z/da, eine blogpostserie)

Dieser Teil sollte schon vor einer Woche erscheinen, aber es war einfach so viel zu tun, dass für das Aufschreiben zu wenig Zeit war. Auf verschwoerhaus.de wurde es schon kurz angeteasert und auf netzpolitik.org konnten wir das Projekt auch vorstellen: Gemeinsam mit der Abteilung Bildung und Sport der Stadt Ulm rollen wir derzeit als Lückenfüller einen BigBlueButton-Pool für diejenigen Schulen in Ulm aus, die nicht über andere Werkzeuge wie z.B. den derzeit landesweit ausgerollten Pool abgedeckt werden.

Der Aufschlag dazu fand Anfang der Osterferien statt, und der Leiter der Abteilung war recht pragmatisch in seinem Auftrag. Ein neuer Kollege bei Bildung und Sport, der am 1. April mit der Arbeit anfing, fand folgenden Auftrag für das kleine, gemeinsame Team:

Es wurde […] die Apollo 13 Metapher bemüht. Wir sollen jetzt in einem kleinen Team den „CO2 Filter“ bauen und […] eine Einkaufsliste geben was wir brauchen

Die Einkaufsliste war schnell gestrickt, und so fingen wir an, den Rollout umzusetzen. Auf dem Weg durften wir uns intensiv mit den Leuten austauschen, die den doch recht mächtigen Rollout des Baden-Württemberg-weiten BBB-Systems praktisch umsetzen, und auch von Seiten des OMI und des kiz der Uni Ulm gab es wertvollen Input, wie deren unieigenes BBB-Pool ausgerollt und verwaltet wird.

(Einschub: An der Stelle möchte ich noch einmal den riesigen Vorteil von Freier Software und Open Infrastructure hervorheben: Hier arbeiten sehr viele helle Köpfe auf hohem Niveau an ihren jeweiligen Infrastrukturen, und durch den gemeinsamen Austausch und das gegenseitige voneinander-lernen wird sehr viel mehr daraus als die Summe der einzelnen Teile!)

Schon seitdem wir unser „kleines“ BBB im März aufgebaut hatten, haben wir Anfragen auf verschiedensten Kanälen bekommen, wie andere ein BBB-Setup nachbauen können und wo die Grenzen liegen. Wir haben uns gedacht, dass wir an dieser Stelle sowohl einmal zeigen, wie wir unser Einzel-Server-Setup gebaut haben, und wie skalierende Varianten mit Pools aussehen können. Danach folgen eine kleine FAQ und die Probleme, denen wir begegnet sind.

Zwei Dinge sind vorneweg jedoch wichtig: Wir betreuen und betrachten mit unserer Brille vorwiegend die technische Seite. Zu guter Lehre gehört viel viel mehr als eine Online-Lernumgebung – so wie allein ein Klassenzimmer auch keinen guten Unterricht garantiert. Online-Lehre ist ein ganz eigenes Format, das separater Vorbereitung bedarf. Den Unterricht 1:1 ins Netz zu übertragen, wird in der Praxis nur mäßig zufriedenstellende Ergebnisse erzielen. Das wiederum ist aber kein spezifisches BBB-Problem, sondern es trifft auf quasi alle vergleichbaren Systeme zu.
Zweitens, wir waren in der letzten Woche vom großen Andrang auf das BBB-Schulsystem sehr überwältigt. Wir dachten anfangs, hier vor allem eine Stopgap-Lösung zu bauen. Ich bin sehr auf die kommenden Tage gespannt, in denen wir Stück für Stück die Anmeldungen onboarden werden – und dann sehen, wie die Lastverteilung im Tagesgang wirklich aussieht. Das ist der Part, der sich nicht vorab testen lässt. Mal schauen, wie gut ich heute abend schlafen kann.

Nun aber zur kleinen, quick-and-dirty-Lösung.

Ein Server, ein BBB, viele Leute.

Das erste Setup war recht schnell installiert. Es handelt sich um eine kleine Proxmox-virtualisierte Maschine im Verschwörhauskeller, mit sehr überschaubaren Ressourcen (4 CPUs, 8 GB RAM). Die zugrundeliegende Maschine, auf der die VM läuft, ist ein Dell R610 mit 8× Intel Xeon X5570 bei 2.93 GHz. Insgesamt hat die Host-Maschine 48 GB RAM.

Max sagt scherzhaft, dass die VM im Vergleich zu anderen Hostsystemen auf Raspberry-Pi-Niveau ist (wenngleich wir nicht empfehlen würden, solch eine Umgebung auf einem RasPi umzusetzen). In der Spitze waren auf dieser Maschine 58 NutzerInnen größtenteils mit aktiver eigener Webcam aktiv, und das war auch das einzige Mal, dass die CPU an ihre Grenzen kam. Der Traffic lag in der Spitze bei 45 Mbit/s ausgehend und 9,6 Mbit/s eingehend. Wenn alle Teilnehmenden mit Video in der Konferenz sind, sind sowohl der Datenratenbedarf als auch die CPU-Auslastung relativ hoch; wir hatten auch schon Sessions mit 23 Leuten bei 10 Mbit/s outbound und 2.25 Mbit/s inbound. Your mileage may vary.

Installiert wurde die Maschine mit dem bbb-install-Script auf Ubuntu 16.04 LTS – ja, BBB funktioniert derzeit offiziell exakt nur auf dieser veralteten Version, was Folgeprobleme z.B. mit Python-Versionen nach sich zieht. Dazu später mehr.

Wichtig beim Rollout ist auch, die Möglichkeit zur Aufzeichnung von Sessions von vorneherein zu deaktivieren. Tatsächlich finden nämlich standardmäßig Aufzeichnungen aller Sessions statt, und der Recording-Knopf setzt hier nur Schnittmarken und startet nach Ende der Session eine Nachbearbeitungspipeline. Das von vorneherein zu deaktivieren schafft bessere DSGVO-Compliance und schützt auch vor vollaufenden Platten.

TURN und STUN zur Firewalldurchbohrung

Da nicht nur „unsere“ Verwaltung in Ulm, sondern auch andere Behörden und Projektpartner mittlerweile diese Instanz nutzen, ist es sehr wichtig, durch Firewalls durchzukommen, die noch auf Sicherkeitskonzepten von vor 30+ Jahren stammen (alles ist aus Prinzip erstmal zugenagelt). Nach einigem Herumprobieren läuft daher gerade auf einer seperaten VM ein coturn, das STUN und TURN auf Port 443 abwickelt. Damit ließen sich zum Erstaunen mancher Gegenstelle sogar bundesministerielle Firewalls durchbohren, bei denen selbst Jitsi bislang nicht funktionierte. Das ist natürlich andererseits wieder der Vorteil einer so eindimensionalen behördlichen IT-Sicherheit ;)

(Mehr zu dieser Besonderheit im skalierenden Ansatz weiter unten, hier gibt es ggf. Fallstricke).

Dialin via SIP

Da im Hintergrund von BBB ein FreeSWITCH läuft, lassen sich relativ einfach Einwahlnummern für diejenigen Menschen anbinden, die nicht so einfach ein Headset an ihren Rechner anschließen oder aus anderen Gründen Probleme mit dem Rechner-Audio haben. Hier gibt es eine große Auswahl an SIP-Telefonie-Anbietern mit lokalen Einwahlnummern. Letztlich ist aber die Zahl der eingehenden, gleichzeitig nutzbaren Kanäle begrenzt, weswegen sich hier nur einwählen sollte, wer nicht anders kann. An den Server wird eine Rufnummer gebunden; die Auswahl des Konferenzraums erfolgt dann über eine PIN.

Einfach flott rein

Im Gegensatz zu verschlossenen Konferenzlösungen für bestimmte Nutzergruppen, die meist bei der Person, die das Meeting erstellt einen Account erzwingt, haben wir bei der kleinen Lösung versucht, es so einfach wie möglich zu gestalten. Der Flow, der auch z.B. so bei Jitsi Meet funktioniert, besteht aus der Eingabe eines Raumnamens, der dann angelegt wird, falls er noch nicht existiert. Danach folgt die Eingabe des eigenen Namens. Das Meeting bekommt einen URL, den die Teilnehmenden besuchen können und nur noch ihren Namen eingeben müssen. Ein Vorteil dieser Lösung im Gegensatz beispielsweise zu greenlight liegt auch darin, dass man sich mit dieser Schmalspurlösung nicht sofort Docker und Datenbanken und E-Mail-Versand und sonstige weitere Abhängigkeiten eintritt.

Das BBB-Frontend dafür ist im Wesentlichen wenig anderes als eine angepasste Variante der HTML5-Demo von BBB. Wir haben es als bbb-easy-join veröffentlicht.

Monitoring, ein Auge drauf haben

Monitoring mit hübschen Graphen ist immer toll! Deswegen haben wir auch in der kleinen Lösung Prometheus und Grafana laufen, die ihre Daten über bbb-exporter bekommen. Dort gab es vor Kurzem auch einen Pull Request eines ~alten~ jungen Bekannten aus dem Jugend-hackt-Kosmos, um zu sehen, wie viele Menschen per SIP eingewählt sind.

Viele Server, viele BBBs, noch mehr Leute

Irgendwann ist aber auch auf „handelsüblichen“ Servern die Kapazität zu Ende. Das lässt sich auch nur begrenzt durch mehr CPU-Power beheben. Aufgrund der Systemarchitektur mit node.js – einer Kernkomponente, die sich um den Chat, das Whiteboard, aber auch das Signaling der Status der Teilnehmenden kümmert – laufen hier wesentliche Teile des Setups weiterhin single-threaded. Es gibt ein Issue zum Aufteilen und ein weiteres Issue, um die veraltete nodejs-version hochzuziehen, was das Gesamtsetup hoffentlich etwas performanter macht.

Egal wie sie aber nun beschaffen sind: Irgendwann braucht es mehr als einen BBB-Server. Aus der BBB-Welt gibt es dafür scalelite für die Lastverteilung. Wie das in etwa aussieht, zeigt das folgende Bild:

Skizze von Andreas Grupp auf Wikimedia Commons / CC BY-SA

Im Hintergrund steht ein Pool an Servern, die sich jeweils am scalelite anmelden. Der Einstieg der Teilnehmenden erfolgt dann über das Frontend der Wahl – das kann z.B. das erwähnte greenlight sein, aber auch Moodle oder andere passende Plattformen. Scalelite weist dann im Hintergrund der angefragten Session einen Poolserver mit Kapazität zu und dann kann es losgehen.

Automatisieren, automatisieren, automatisieren (und vielleicht virtualisieren)

Um diesen Pool hochzuziehen, haben wir uns diverse Ansible-Playbooks zum Vorbild genommen. Neben den Playbooks der Uni Ulm und der Landeslösung haben wir vor allem das Skript von n0emis integriert – noch so ein junger Bekannter aus dem Jugend-hackt-Kosmos :) Das letzliche Playbook ermöglicht es uns, innerhalb von rund 20 Minuten aus einer blanken Maschine einen zusätzlichen Poolserver zu bauen. Für weitergehende Ansätze mit Virtualisierung und Orchestrierung fehlte bislang leider die Zeit.

Auch hier gibt es ein Monitoring, um einen Überblick über den Status und die Auslastung der Pool-Server zu haben. Wir werden uns hier Schritt für Schritt mit den praktischen Daten herantasten müssen – wir wissen grob, wie viel Last ein einzelner Server abkann (die Doku spricht von rund 150 Teilnehmenden, die Uni Ulm meldete Erfahrungen mit bis zu 300 TN), die tatsächliche Last ist aber eine Funktion aus zeitlicher Verteilung, tatsächlicher Benutzung der Räume und wie viele Menschen dabei ihr Video laufen haben. Das wird sich nur in der Praxis ermitteln lassen.

Grenzen, nichttechnisch

Zunächst das Offensichtliche: Alles, was wir hier machen, ist ein Notbehelf. Wir können nicht binnen einer Woche Onlinelehre aus dem Nichts schaffen – und das ist keine Werkzeug- sondern eine Strukturfrage. Ich bin mir sicher, dass in den kommenden Wochen Kiebitzereien von der Seitenlinie kommen werden, warum nicht $XYZ genutzt wurde, weil das ja viel besser gehe.

Kern des Problems ist und bleibt aber: Eine Klassenzimmersituation kann nicht 1:1 ins Netz übertragen werden, und Onlinedidaktik erfordert ganz andere Vorgehensweisen als Klassenzimmerunterricht. Diese Erfahrung wird nicht viel anders sein als die in der Geschäftswelt, wo in den vergangenen Wochen versucht wurde, klassische Präsenzarbeit mit den Werkzeugen verteilten Arbeitens 1:1 umzusetzen – das geht nur mäßig gut, und effizientes verteiltes Arbeiten erfordert ganz andere Paradigmen.

Ich habe aber viel Begeisterung und Umsetzungswillen von den ersten alphatestenden LehrerInnen gesehen, und hoffe, dass die Kollegien der teilnehmenden Schulen sich intern und untereinander weiterhelfen und gegenseitig fortbilden. Dass das leichter gesagt als getan ist, ist mir schmerzhaft bewusst. Bei der LehrerInnenfortbildung BW entsteht derzeit ein Katalog an Handreichungen, den ich sehr empfehlen kann. Der Fokus auf gezielt eingesetzte Webinare und Gruppenarbeiten sowie Flipped Classrooms, ergänzt durch Sprechstunden, erscheint mir ein guter Ansatz – denn jetzt kommen wir ins technische.

Grenzen, technisch, allgemein

Die Annahme, dass Online-Unterricht analog zum Klassenzimmer funktionieren kann, kommt sehr schnell schon technisch an Grenzen. Ich zitiere hier verkürzt aus einer Überschlagsrechnung, die mir zur Verfügung gestellt wurde: In ganz Baden-Württemberg finden pro Woche rund 2,2 Millionen Unterrichtsstunden statt. Selbst bei gleichmäßiger Verteilung auf 8 Stunden am Tag über 5 Tage die Woche entspräche dies 55.000 gleichzeitiger Videokonferenz-Sessions. Die oben in der simplen Lösung beobachteten Werte decken sich mit dem, was mir vorliegt: Selbst wenn nur die Lehrkraft an 25 SchülerInnen streamt, liegen wir bei 5–10 Mbit/s outbound. Selbst wenn nun alle Unterrichtsstunden wirklich gleichverteilt über den Tag stattfinden und nur gelegentlich SchülerInnen ebenfalls ihr Video zuschalten, kommen wir so schnell in den Terabit-Bereich, um Lastspitzen abzufangen.

Und da reden wir noch gar nicht von den Peering-Problematiken zu Access-Netzen oder der Situation, wenn mehrere SchülerInnen sich einen Anschluss teilen – und schon gar nicht von Fragen sozialer Ungleichheit und wer überhaupt genügend passende Endgeräte hat.

Ich denke, dass diese Fragen auch keine der anderen Webconferencing-Lösungen beantworten kann.

Nach diesem kleinen ~Downer~ Realitätscheck nun noch ein paar andere Limitationen.

Grenzen, technisch, BBB

Der Bauprozess für BBB ist… problematisch. Die Plattform an sich finde ich für Onlinelehre enorm stark. Man merkt der Developer-Community aber an, dass sie lange Jahre ein Nischendasein fristete, und die größere Free-Software-Welt erst jetzt – notgedrungen – so richtig auf sie aufmerksam geworden war. Wie oben beschrieben baut BBB auf Ubuntu 16.04 LTS ab, derweil seit dieser Woche schon die übernächste LTS-Version veröffentlicht wurde. Die Voraussetzungen für den Bau und die Paketierung des Systems sind nur spärlich dokumentiert, was mittlerweile durch die neugewonnene Aufmerksamkeit auch umfangreich diskutiert wird

Daraus folgende Effekte sind auch zu sehen. Das Projekt BBB macht gerade durch die vorher nie dagewesene Aufmerksamkeit rapide Entwicklungsschritte. Alle paar Tage erscheinen neue Package-Releases, und nicht immer ist im Changelog oder durch Release-Notes erkennbar, dass für das Ausrollen der neuen Pakete Änderungen auf die URLs der passenden Repositories nötig sind.
Ich halte es auch für wichtig, hier offen mit bereits erkannten und möglicherweise künftig noch auftretenden CVEs umzugehen. Wir arbeiten weiter daran, eine technisch möglichst umfassende Absicherung unseres BBB-Pools gewährleisten zu können. Es kann aber seriöserweise ebensowenig wie bei anderen – auch proprietären – Werkzeugen versprochen werden, dass BBB grundsätzlich „sicher“ ist. Das ist mit ein Grund, warum wir so darauf pochen, dass Webconferencing-Werkzeuge kein 1:1-Transfer von Präsenzklassenräumen sein können.

Wir hoffen alle darauf, dass BBB in der nahen Zukunft schrittweise einen Security-Audit bekommt und die vermutlich unerwartete und ungewollte Rolle als kritische Infrastruktur aktuell noch viel mehr Augen und Aufmerksamkeit auf das Projekt lenkt – damit am Ende wir alle mehr davon haben. Die Liste an Pull Requests und Verbesserungsvorschlägen ist in der Tat gleichermaßen vielfältig wie Anlass zur Freude.

Eine Baustelle, die nicht nur uns betrifft, sind Audioprobleme bei iOS-Geräten. Die großartigen Datenzauberer und -hexen in unserem Team arbeiten gerade an einer besseren STUN/TURN-Konfiguration, um auch dieses Problem zu lösen und danach auch zu dokumentieren. Auch hier sind aber nicht nur wir am Ball, glücklicherweise. Wenn ich nach Twitter gehe, sieht sich gerade gefühlt ein Drittel der Tech-Welt BBB näher an.

Mehr

Gerade diese gesammelte Aufmerksamkeit ist im deutschsprachigen Raum gerade erfreulich gebündelt. Holger, der schon eine tragende Rolle bei der Weiterentwicklung von digitransit im verteilten Transportkollektiv einnimmt, hatte vergangenen Montag schon zu einem Austausch im Rahmen des digital verteilten Onlinechaos eingeladen. Morgen abend soll es eine nächste Runde des Austauschs geben, und es existiert auch ein Matrix/Riot-Channel, der auch in den Slack der Open Knowledge Foundation gespiegelt wird. Ich kann nur alle Interessierten einladen, sich einzubringen – gemeinsam können wir noch viel mehr aus diesem Projekt machen :)

Das nun als sonntagabendlicher sehr später Aufschrieb des Status Quo. Morgen wissen wir mehr, ob uns das Ding um die Ohren fliegt. Stay tuned.

Wir hatten im Januar schon einmal beschrieben, dass wir auch selbst entwickelte Wifi-Tracker zur Positionsbstimmung benutzen. Das Hardwaredesign und die Firmware, welche wir dafür entwickelt haben ist natürlich als OpenSource bzw. OpenHardware auf GitHub verfügbar.

Allerdings ist es sicher auch interessant, wie genau wir die Tracker momentan einsetzen. Theoretisch funktioniert die Platine ja einfach, wenn man sie zusammen baut, aber irgendwie muss sie ja auch ans Fahrrad und mit Strom versorgt werden. Wie wir das aktuell umsetzen, beschreiben wir hier.

Flashen

In dem Hardwaredesign sind Kontakte für Datentransfer und Buttons für Flash und Reset vorgesehen, um die Firmware auf dem fertig gelötetem Board aufzuspielen. Allerdings flashen wir die Firmware schon vor dem Auflöten mit einem testboard programmer auf das ESP12-Modul. Zum einen vermeidet man dadurch, bei vielen Platinen immer wieder Kontaktkabel an und wieder abzulöten, andererseits kann man auch so die Buttons weg lassen, was im Zweifel zusätzlich nochmal Platz spart.

Zusammenlöten

Beim Zusammenlöten starten wir mit dem ESP12-Modul. Es empfiehlt sich dieses zum Löten mit einer dritten Hand oder einer Klemme an der Platine in der richtigen Kontaktposition zu fixieren. Danach das Gleiche noch mal mit dem RFM-96 LoRa-Modul.

Sind diese beiden Bauteile angelötet, kommen die Kleinteile auf der Rückseite dran. Dabei sind eigentlich nur die fünf 10k-Widerstände und der 100uF-Kondensator relevant. Die 1k-Widerstände sind nur nötig, wenn die serielle Schnittstelle zum Flashen oder Debuggen benutzt werden soll. Die 100k- und 680k-Widerstände waren ursprünglich zum Messen der Spannung gedacht, verbrauchen ohne weitere Hardwaremodifikation aber zusätzlich Strom im Schlafzustand und werden deswegen momentan auch von der Firmware nicht unterstützt. Dieses Problem wollen wir in zukünftigen Hardwareversionen aber lösen, da die Information zum Batteriezustand im Betrieb durchaus wichtig ist. Den Spannungsregler AMS111733 können wir in unserem Fall auch komplett weg lassen, da wir den Tracker mit zwei AA Batterien betreiben, welche die gewünschte Spannung schon von Haus aus liefern.

An dem Antennen-Pin vom RFM sollte noch ein Kabel als Antenne angelötet werden. Dieses kann dann später nach dem Einbau gekürzt werden. Billige Spiralantennen haben sich bei uns als schwer zu löten und nicht sehr effektiv herausgestellt. Das kann aber bei anderen Antennen durchaus anders sein.

Gehäuse

Nach langem Experimentieren und langer Suche nach einem günstigen Gehäuse, welches den Tracker und die Batterien platzsparend fassen kann, haben wir uns für ein modifiziertes 3×AA Batteriegehäuse entschieden. Die Verkabelung im Gehäuse wird so modifiziert, dass nur zwei Batterien genutzt werden. Im dritten Fach findet dann der Tracker seinen Platz.

Von diesen Gehäusen gibt es leicht abweichende Ausführungen, die Verkabelung ist aber in der Regel immer gleich. Preislich liegen die Gehäuse bei AliExpress je nach Menge und Umrechnungskurs bei etwa 40-70 Cent.

Als erster Schritt wird die Abdeckung über dem Schalter gelöst (manchmal geschraubt, manchmal gesteckt). Dadurch kann der Schalter zusammen mit dem schwarzen Kabel und der Spirale nach oben raus gezogen werden.

Im nächsten Schritt kann das rote Kabel bis zum Metallplättchen heraus gezogen, und das Kabel nach oben gebogen werden.

Als Nächstes muss der Doppelkontakt nach oben aus der Halterung gezogen werden. An die Seite ohne Feder kann nun ein Kabel angelötet werden. (Ich verwende da immer ein Stück des vorher gezogenen schwarzen Kabels.)

Danach müssen die beiden Kabel nur noch so eingekürzt werden, dass sie bequem an die Platine gelötet werden können. Zum Abschätzen des Abstandes empfiehlt es sich, die Platine schon mal in die endgültige Stelle einzulegen. Das rote Kabel wird nun an den 3V Kontakt gelötet und das schwarze auf GND.

Außerdem beschriften wir die Platinen noch mit einer Kurzform der TTN-Device-ID, welche wir vorher in der Firmware konfiguriert haben, damit es später keine Verwechslungen gibt. Nun können die Batterien rein und der Deckel drauf. Falls die Platine beim Schütteln klappert, kann noch ein bisschen Füllmaterial ins Gehäuse geklemmt werden.

Verkleben

Jetzt kommen wir zum unausgereiftesten Teil des ganzen: Das Gehäuse ist alles andere als wasserdicht. Deswegen haben wir es einfach mit ordentlich Gaffa verklebt. Dabei unbedingt auf die Ecken achten. Das ganze ist dann leider beim Batterien tauschen etwas unbequem, da das alles wieder aufgeschnitten werden muss. Bei uns halten die Batterien aber so etwa 3 bis 4 Monate.

Bis jetzt hatten wir noch keine Fälle in denen nennenswert Wasser rein geflossen wäre, wie wir das bei den Abzweigdosen für die GPS-Tracker schon erlebt haben. Allerdings hatten wir jetzt schon Fälle, in denen sich Korrosion gebildet hat und sich Kondenswasser abgesetzt hat. Hier könnte vielleicht ein kleiner Beutel Silica-Gel nicht schaden. Über Vorschläge und Ideen zur besseren Abdichtung freuen wir uns immer.

Klett

Nach dem Verkleben werden auf einer Seite noch zwei Streifen Hakenklett angeklebt. Auf der Innenseite der Beschriftungsplatten unserer Fahrräder befinden sich auch zwei Flauschklettstreifen - und da wird der Tracker dann einfach angeklettet. Das hält! Außerdem sollte auch außen auf den Tracker noch einmal die Tracker-ID drauf geschrieben werden.

Mitentwickeln

Für alle, die Interesse haben sich auch einen Wifi-only Geolocation-Tracker zu bauen, hätten wir auch noch ein paar unbestückte Platinen, die wir gern verschicken können. Schickt uns dafür einfach eine Mail an openbike@ulm.dev

(die #coronalearnings von z/da, eine blogpostserie)

Vier Wochen arbeiten wir nun schon verteilt, und das ging bislang besser als ich dachte. Der Austausch mit Slack, BigBlueButton, Mailscan und E-Mail funktioniert recht flüssig – wenngleich es doch nicht dasselbe ist, wenn man die KollegInnen so gar nicht regelmäßig an einem Ort sieht. Einige Dinge haben es aber nicht mehr oder zu beiläufig in den letzten sehr langen Blogpost geschafft, weswegen ich sie hier noch einmal hervorheben möchte.

It is not about the tools

Jetzt verteilt zu arbeiten ist etwas grundlegend anderes als würde man einfach die bisherige Arbeitspraxis mit ein paar Werkzeugen umorganisieren. Wir haben im Team eine recht große Bandbreite: Einige von uns sind schon sehr vertraut damit gewesen, über die nun gemeinsam genutzten Werkzeuge mit einem verteilten Team zu arbeiten. Für andere war das eine spannende und ungewohnte neue Sache. Das hieß nun auch: Tipps und Tricks weitergeben, wie man sich gut in dieser Situation organisiert.

Was das heißt, haben dankenswerterweise aktuell die Verwaltungsrebellen in einem eigenen Blogpost aufgeschrieben.. Vieles davon kann ich so unterschreiben. Auf einige Besonderheiten möchte ich aber noch einmal gesondert eingehen.

Es gibt keine aufgeschnappte Wissensweitergabe mehr → Kill the DMs

Im Büro bekommt man auch unter der Woche und ohne große Austauschrunden zumindest in Teilen mit, was die anderen Teams machen. Ausgleich können Präsenz-Jour-Fixes schaffen – wie im exzellenten Aufschrieb von Basecamp umrissen gilt jedoch: “Meetings are the last resort, not the first option.”

Den Basecamp-Post kann ich nicht zu wenig empfehlen. Was dort aber nicht explizit ausgedrückt wird: Für verteiltes Arbeiten ist es unglaublich wichtig, Ideen in nachvollziehbaren öffentlichen Räumen auszutauschen, nicht in 1:1- oder Gruppen-DM-Konversationen. Das ist nicht unbedingt intuitiv, wenn man neu in diese Arbeitsform einsteigt: Vielfach steht der Wunsch im Vordergrund, den Noise-Level in den gemeinsamen Gruppenkanälen niedrig zu halten und andere nicht mit scheinbar unnötigen Nachrichten „zu überlasten“.

Für ein Team, das auch verteilt mitbekommen soll, was wo ausgetauscht wird, ist es jedoch kritisch, auch nebenher aufzuschnappen, welche sie ggf. betreffenden Informationen in anderen Teilgruppen besprochen werden. Zu oft passiert es sonst den nicht-öffentlich in Kleingruppen Diskutierenden, dass sie den Eindruck bekommen, ihre (meist intensive) Kommunikation ist auch den anderen bekannt – obwohl das nicht der Fall ist. Am Ende passieren dann Informationsverluste, so dass der Rest nicht von stattgefunden habendem Austausch erfährt.

Dauernde Gruppen-Meetings sind dazu dennoch keine sinnvolle Alternative. Wie @dhh auf Twitter schreibt:

The best Zoom alternative is fewer virtual meetings and more considered, long-form write-ups. It won’t replace them all, but if your remote day is nothing but a long series of Zoom meetings with small breaks in between, you’re probably doing it wrong.

Das bringt uns auch gleich zum nächsten Punkt:

Größere Ideen bedürfen längerer Texte → Writing solidifies, chat dissolves

Der Informationsüberfluss oder zu hoher Noise-Level in den gemeinsamen Kanälen ist nämlich durchaus ein Ding. Die Konsequenz ist aber, dass das, was dort besprochen wird, idealerweise immer nur der Anfang separat nachgehaltener, verschriftlichter Ergebnisse ist.

In einem weiteren Basecamp-Post sind die Vor- und Nachteile von Teamchats hervorragend zusammengefasst. Der für mich herausstechende Teil, den ich hier meine:

Tell people to “write it up” instead. Stuck in a chat that’s going on way too long? Talking a lot but not making progress? Stop the conversation and ask someone to “write it up” — take it to long-form, make it asynchronous. Let someone make a complete point all at once and then give people time to absorb it and respond in kind, over time.

Diese Erkenntnisaufschriebe können dann nachgehalten werden – egal ob per Mail, in einem abgelegten Dokument oder als zu Protokoll gegebenes und dann falls nötig in einem Jour Fixe diskutiertes FYI-Topic.

Das gilt insbesondere dann, wenn der Teamchat auf einem der diversen Free Plans läuft, die nur die letzten 10.000 Nachrichten durchsuchbar vorhalten – alles was davor war, kann später nicht mehr nachvollzogen werden. Selbst wenn nicht, gehört dieser Grundsatz aber unbedingt eingehalten.

Und sonst noch so

Einige Links

• Eine Handreichung für Jitsi vom Chaostreff Osnabrück
• Tipps für Work-from-Home beim Spiegel
• Ein Interview mit Claus Arndt bei den Verwaltungsrebellen
• Eine Tool-Liste für verteiltes Arbeiten von der DRK-Wohlfahrt

Und nicht zuletzt, The Ultimate Remote Work Policy (in 3 Words): We trust you.