Continuous Communication

Stell dir vor, du fasst mit der Hand auf eine glühend heiße Herdplatte und fühlst den Schmerz erst 10 Minuten später. Du spürst den Schmerz also erst während du ein Gewürzglas aus dem Regal nimmst, oder während du dich hinsetzt oder beim Essen. Was bewirkt dann dieser Schmerz?

Lerne ich in einem solchen Szenario, dass ich mir am Gewürzglas die Finger verbrenne? Oder weiß ich, dass der Schmerz verzögert auftritt? Dann kann ich in meinem persönlichen Log-Buch nachsehen und da steht’s: „vor 10 Minuten hast Du kurz auf die heiße Ofenplatte gefasst“. Schön wär’s!

Umgekehrt: Wenn ich den Schmerz sofort spüre, kann ich sofort reagieren und die Hand zurückziehen. Ich lerne, dass eine Herdplatte extrem schmerzen kann und vermeide in Zukunft mir wieder die Finder zu verbrennen.

Allein das “sofort” hilft auf natürliche Art und Weise bei

• Schadensbegrenzung (Qualitätssteigerung)
• Erkennen von Ursache und Wirkung (Lernen & Adaption)
• Schlussfolgerungen für zukünftiges Verhalten (Innovation)

Was bedeutet das jetzt für unsere digitale Arbeitswelt? Die Rückmeldung (“Schmerz”) sollte immer im Zusammenhang zur Ursache (“Hand auf heißer Herdplatte”-“Haut wird geschädigt”), also ohne Unterbrechung stattfinden.

Dabei muss zum Glück nicht immer mit Schmerz quittiert werden. Die Rückmeldung kann einfach in Form einer kurzen Nachricht kommuniziert werden.

Die Idee: ohne Unterbrechung mit Continuous Communication

Hier kommt Continuous Communications ins Spiel, eine unterbrechungsfreie Rückmeldung per Kommunikation. An dieser Stelle bedeutet Continuous im doppelten Sinne “unterbrechungsfrei”: Das Continuous Communication System sollte

1. ohne Unterbrechungen funktionieren und sofort Rückmeldungen geben
2. Mitarbeiter nicht in ihrer Arbeit unterbrechen

Der erste Punkt ist einleuchtend. Aber widerspricht nicht der zweite Punkt, dass das System Mitarbeiter nicht unterbrechen soll, gerade diesem ersten Punkt? Ganz und gar nicht. Die Logik dahinter ist so einfach, wie einleuchtend: Wenn ich an etwas arbeite (Ursache) und ein Ergebnis produziere (Wirkung), dann unterbricht mich z.B. eine Fehlermeldung zu meinem gerade geschriebenen Code nicht, sondern unterstützt mich sofort in meiner Arbeit. Es sind gerade die Verzögerungen, die aus einer eigentlich nützlichen Rückmeldung (!) eine Störung im Arbeitsablauf machen. Mit ein paar Bestandteilen wird aus dieser Beobachtung ein System:

Bestandteile von Continuous Communication

Continuous Communications besteht aus

• einem zentralen Message-Hub, über den die Nachrichten zusammenlaufen. Von dort werden Nachrichten  gesteuert und verteilt.
• Kanälen, die Informationen vorsortieren und über die man nach dem “pull”-Prinzip Zugang zu Informationen hat.
• Fachlichen Subsystemen, die mit dem Messaging-Hub verbunden sind.

Beim zentralen Messaging-Hub laufen Informationen aus unterschiedlichen Quellen zusammen. Quellen können fachliche Subsysteme sein, wie z.B. ein Projektmanagement-Tool, ein Continuous Integration System, oder ein Code Repository. Im einfachsten Fall bildet man jede Quelle auf einen Kanal ab. Zusätzlich gibt es zwischen allen Mitarbeitern einen persönlichen Kanal und Chaträume als Kanal zu speziellen Themen.

Insgesamt fließt durch diese Kanäle vermutlich ein gigantischer Nachrichten-Fluss. Insbesondere, wenn man bedenkt, dass manche technischen Systeme mehrere tausend Nachrichten pro Monat generieren. Deshalb darf man einen Kanal nicht mit einem E-Mail-System vergleichen, bei dem man versucht, alle Nachrichten durchzuarbeiten. Vielmehr handelt es sich um einen Live-Ticker, in den man bei Interesse kurz abtaucht, um sich über aktuelle Veränderungen zu informieren.

Konfiguration für Fach-Domänen

Die eigentliche Kunst liegt darin, Continuous Communication so zu konfigurieren, dass jeder genau die Nachrichten bekommt, die er braucht – zum richtigen Zeitpunkt und mit nützlichem Inhalt. Das nützliche Maß Inhalt kann man durch unterschiedliche Mittel erreichen:

• Ströme werden je nach Nachrichteninhalt querverlinkt, z.B.
  • Eine Nachricht zur Aktualisierung des digitalen Projekt-Boards in einem Projekt-Kanal über enthält den Link auf dieses Projekt-Board (z.B. direkt zur bearbeiteten Aufgabe)
  • Eine Nachricht zu einen Commit im Code-Repository-Kanal löst eine Notifikation an den beteiligten Entwickler aus und enthält einen Link zum entsprechenden Commit
  • Eine Nachricht zu einem gescheiterten build-Versuch vom Continuous Integration Server enthält einen Link zu dem problematischen Commit im Code-Repository.
• Kritische Nachrichten werden als Notifikation verschickt (z.B. E-Mail oder SMS)
• Jede Nachricht enthält den “Elevator Pitch” der eigentlichen Information und Links zur Nachrichtenquelle im Subsystem, sowie Links zu korrespondierenden Nachrichten.
• Die Macht der Gewohnheit: Man schaut in den Kanal, in dem man zu seiner aktuellen Arbeit Informationen erwartet.

Browsen durch ein Netzwerk aus Nachrichten

Es entsteht ein Netzwerk aus Nachrichten. Einzelne Nachrichten innerhalb des Message-Hubs bieten Links inklusive Vorschau als Ankerpunkte zu Ereignissen (z.B. der technischen oder fachlichen Systeme), oder zu externen Quellen (z.B. Blog-Artikeln, Webseiten, oder Videos). Gleichzeitig hat jeder Knoten dieses Netzwerks eine interessante chronologische Umgebung innerhalb des Kanals – was ist kurz vorher passiert und was ist kurz nachher?

Mental Model, Alert & Positives Micro-Feedback

Ist Continuous Communication richtig konfiguriert, synchronisieren alle Beteiligten eines Systems ihr jeweiliges mentales Model über den aktuellen Zustand (siehe Abbildung 3). Das ist Voraussetzung, dass alle tatsächlich an einem Strang ziehen können. Und: Das Team ist im gleichen Bereich unterwegs, es verliert sich nicht in unterschiedlichen Räumen.

Darüber hinaus bekomme ich bei verschuldeten/verantworteten Problemen sofort Information darüber, dass etwas passiert ist und was passiert ist. Dabei muss die Konfiguration nicht nur auf “Alerts” ausgerichtet sein. Interessant im Rahmen einer agilen Vorgehensweise ist besonders, erfolgreiche Schritte in die gewünschte Richtung mit positiven Feedback zu belohnen. Etwa so: “Danke, Max, für den neuen Code, den Du committet hast. Jetzt bin ich an der Reihe und mache mich an die Arbeit. Schönen Feierabend, Jenkins”. Das Mico-Feedback entwickelt und schärft den richtigen Riecher aller Beteiligten, um auf Erfolgskurs und auf dem gemeinsamenWeg zu bleiben.

Neue Einblicke durch Data Mining im Messaging-Hub

Ganz nebenbei wird der zentralen Messaging-Hub eine ideale Datenquelle. Diese Datenquelle liefert neue Einblicke: 

• Was sind gerade aktuelle Themen
• Wo schlummern versteckte Impedements
• Wo sind bottle necks
• Welche Systeme bereiten besonders viel Probleme
• Wie verschieben sich Aktivitäten bei besonderen Ereignissen

Aber Vorsicht: diese Maßnahmen dürfen nicht zur Kontrolle und Überwachung dienen. Der Daten- und Persönlichkeitsschutz müssen gewahrt bleiben. Zugriff & Kontrolle sollte auf Team-Ebene selbst liegen, um mehr Transparenz & Fakten nur im Kontext von Retrospektiven zu schaffen.

Haben Sie weitere Ideen, wie Continous Communication wirken könnte? Ich bin auf Ihre Kommentare gespannt!

---

Über den Autor