Agile Problemlösung: das fehlende Puzzleteil deines Reaktionsplans im Falle von Vorfällen

Agile-Methoden werden zunehmend auch außerhalb ihres angestammten Bereichs, der Softwareentwicklung, genutzt – selbst im Marketing! Dies hat uns veranlasst, darüber nachzudenken, wie Agile in der Welt des Vorfallmanagements aussehen könnte. Bei Atlassian definieren wir Agile als einen strukturierten und iterativen Ansatz bei Projektmanagement und Produktentwicklung. Agile versetzt dein Team in die Lage, auf Änderungen zu reagieren, ohne dabei vom Weg abzukommen.

Da Bugs in der Produktion sowie Vorfälle und Ausfälle eindeutig als "Entgleisungen" betrachtet werden können, ist für uns die logische Schlussfolgerung, im Vorfallmanagement oder genauer gesagt in der Kommunikation von Vorfällen eine Methode wie Agile anzuwenden. Denn diese ist schließlich dazu konzipiert, Teams in der Spur zu halten.

An Tools zur Erkennung, Warnung, Versammlung zu und Behebung von Vorfällen mangelt es sicher nicht. Aber Tools alleine können eine klare Kommunikation mit den Stakeholdern nicht ersetzen. Und seien wir ehrlich: Oft steht sehr viel auf dem Spiel. Der Ruf des Unternehmens, eine Kundenfluktuation oder der Zeitaufwand für die Schadensbegrenzung sind nur einige wenige Punkte. Agile-Methoden können diese Risiken so gering wie möglich halten.

Viele von euch kennen wahrscheinlich die vier Wertesäulen des Agile Manifesto bereits: 1) Einzelpersonen und Interaktionen haben Vorrang vor Tools, 2) funktionierende Software hat Vorrang vor umfassender Dokumentation, 3) die Zusammenarbeit mit den Kunden hat Vorrang vor Vertragsverhandlungen und 4) die Reaktion auf Veränderungen hat Vorrang vor der Befolgung des Plans. Betrachten wir die einzelnen Säulen ein wenig näher und sehen uns an, wie sie für eine agilere Kommunikation zu Vorfällen genutzt werden können.

Dieses Prinzip basiert auf dem Agile-Grundsatz "Individuen und Interaktionen haben Vorrang vor Prozessen und Tools". Prozesse und Tools sind in jedem Vorfallmanagementprozess von großer Bedeutung, aber nutzlos, wenn man sie nicht in Verbindung mit den Personen, von denen sie angewendet werden, und der Kultur, von der sie umgeben sind, betrachtet. Was ist das verbindende Element zwischen Personen, Prozessen und Tools? Natürlich Kommunikation!

Kommunikation ist entscheidend, wenn ein Problem besteht, egal ob es sich um einen kleinen Bug in der Produktion oder einen ausgewachsenen Systemausfall handelt. Selbst bei einem quasi lückenlosen Plan für Vorfälle ist regelmäßige Kommunikation erforderlich, um zu einer Lösung zu gelangen und das Vertrauen aufrechtzuerhalten.

Während eines Vorfalls begegnen die betroffenen Benutzer höchstwahrscheinlich frustrierenden Fehlern, die möglicherweise sogar alles lahmlegen. Deshalb müssen sie so schnell wie möglich informiert werden, was gerade geschieht. Viele werden bereits E-Mails, Tweets und/oder Tickets zum Problem versenden. Es ist also im Interesse aller, die Situation proaktiv anzugehen und die Benutzer zu benachrichtigen, dass die Verantwortlichen sich des Fehlers bewusst sind und nach einer Lösung suchen. Bei Atlassian verwenden wir Statuspage zur Kommunikation mit internen und externen Stakeholdern während Ausfällen. Dies wäre sicherlich auch für dich ein sinnvolles Tool zur schnellen, skalierbaren Mitteilung von Vorfallsinformationen an deine Benutzer. Tatsächlich hat Statuspage die Geschwindigkeit der Kommunikation seiner Benutzer zu Vorfällen um sagenhafte 50 % erhöht.

Aber ganz gleich, mit welchem Tool du deine Kunden informierst, der Wert menschlicher Kommunikation ist nicht zu unterschätzen. Die vom Problem betroffenen Benutzer sind echte Menschen, die sich auf deinen Service verlassen und von dir erwarten, dass du sie auf dem Laufenden hältst, wenn etwas nicht funktioniert. Vorlagen sind in einer perfekten Welt natürlich toll, aber menschliche Mitarbeiter, die knappe, klare, verständnisvolle und relevante Nachrichten verfassen können, sind unverzichtbar, um auch in den schwierigsten Zeiten das Vertrauen des Kunden aufzubauen. Sehen wir uns als Beispiel Dyn an. Das Unternehmen hatte bei einem der größten DDoS-Angriffe der Geschichte mit einem gewaltigen Ausfall zu kämpfen und trotzdem haben die Benutzer sich beim Unternehmen für die Offenheit während des Serviceausfalls bedankt:

Wie Werner Vogels, der Chief Technology Officer von AWS, sagte, als er über den großen AWS S3-Ausfall im Februar 2017 sprach:

"Kunden möchten keine Ratschläge nach dem Motto 'Abwarten und Tee trinken' hören. Stattdessen erwarten sie aussagekräftige Informationen, damit sie das Geschehen nachvollziehen können. Nach Möglichkeit solltest du ihnen auch mitteilen, wann sie mit der Wiederherstellung des Service rechnen können."

Dieser Grundsatz beruht auf dem Agile-Grundsatz "funktionierende Software hat Vorrang vor umfassender Dokumentation". Die Dokumentation zu deinem Produkt sollte klar und benutzerfreundlich sein – das Gleiche gilt unserer Meinung nach für Vorfall-Updates. Deine Benutzer sollten nicht zwischen den Zeilen lesen (oder lange Textabschnitte überfliegen) müssen, um zu erfahren, was nicht funktioniert und wann sie die Behebung des Fehlers erwarten können. Auch wenn du dir Gedanken über deine Vorfall-Updates machen und sicherstellen solltest, dass die Kommunikation verständnisvoll und menschlich ist, dürfen Genehmigungsprozesse oder mehrfache Überarbeitungen keine häufigen, ehrlichen Updates behindern.

Wenn wir uns noch einmal den Vorfall bei Dyn ansehen, wird deutlich, dass das Team Updates seinen Benutzern umgehend mitgeteilt hat. Im Laufe des über 11 Stunden andauernden Vorfalls wurde die Statusseite 11-mal aktualisiert (im Durchschnitt lagen 61 Minuten zwischen den Updates). Die Statusseite wurde als zentrale Anlaufstelle zur Kommunikation rund um den Vorfall genutzt, statt Zeit mit der Suche nach Mailinglisten für E-Mail-Benachrichtigungen oder mit der Bastelei an 140 Zeichen langen Twitter-Updates zu verschwenden. Mit anderen Worten: Das Unternehmen hat seine Benutzer gut informiert, sich aber trotzdem in erster Linie um die Wiederherstellung des Service gekümmert.

Das Schöne an einem sofort einsatzbereiten Statuskommunikationstool ist, dass du in kürzester Zeit über eine solide, funktionsfähige Seite verfügst. Die Erstellung einer Statusseite dauert keine halbe Stunde und wie bei Agile kann und sollte deine Statusseite iterativ sein. Du kannst zunächst eine funktionierende Seite für deine Kunden online stellen und sie dann mit der Zeit optimieren. Nach den ersten paar Vorfällen, bei denen die Statusseite Teil deines Prozesses war, kannst du kleine Änderungen vornehmen, damit sie fortlaufend besser wird.

Bist du bereit für deine eigene Statusseite? Registriere dich, oder logge dich bei Statuspage ein. >>

Warte mit der Erstellung einer Statusseite nicht erst bis zu deinem nächsten Vorfall. Investiere lieber vorab ein paar Minuten, damit du dich in der bestmöglichen Ausgangsposition befindest, wenn es zu einem Ausfall kommt. Denke daran, es wird nicht lange dauern, bis du eine funktionsfähige Seite erstellt hast:

• So passt du deine Statusseite individuell an.
• Lass dich von Beispielen für herausragendes Design und optimale Anpassung einer Statusseite inspirieren.

Beim agilen Grundsatz "die Zusammenarbeit mit den Kunden hat Vorrang vor Vertragsverhandlungen" ist die Zusammenarbeit mit deinen Kunden zentral, um das Produkt und die Erfahrung damit bestmöglich zu gestalten. Für uns heißt dies, dass wir geeignete Feedbackkanäle einrichten müssen, damit die Kunden uns ihre Anliegen mitteilen und uns über jegliche Probleme informieren können (mit Tools wie Jira Service Management, Twitter usw.). Unternehmen von Weltrang wissen, dass die Kunden eine Reaktion auf ihr Feedback erwarten und in die Verbesserung der Produkte sowie den Vorfallsprozess eingebunden werden möchten. Ein wenig Verständnis und ein paar Erklärungen bewirken hier viel – und die Kunden scheuen sich nicht, dies zu fordern – wie sich in diesen Tweets zeigt.

Das bedeutet auch, hinsichtlich der Verfügbarkeit deines Service transparent zu bleiben, damit die Benutzer bei ihrer Registrierung genau wissen, was sie erwarten können. Wenn du dich für einen Cloud-Service registrierst, erwartest du, dass dieser Service zuverlässig ist. Du schließt nicht in allen Fällen einen physischen Vertrag ab, sondern eher einen inhärenten Vertrag zwischen Kunde und Serviceanbieter, dass, wenn etwas schiefgeht, die beiden Parteien zusammenarbeiten, um das Problem schnell zu lösen. Dabei werden alle von der Untersuchungsphase bis zur Problemlösung auf dem Laufenden gehalten. Dies führt uns auch schon zu unserem letzten Grundsatz zur Reaktion auf Veränderungen …

Selbst die besten Pläne … nun, du weißt schon. In Anlehnung an den agilen Grundsatz "die Reaktion auf Veränderungen hat Vorrang vor der Befolgung des Plans" wissen wir, dass die ausgefeiltesten Pläne während und nach einem Vorfall unweigerlich geändert werden müssen. Im Zentrum von Agile steht die Fähigkeit, jederzeit umzuschwenken und schnell fortlaufendes Feedback einzuholen, das dein Produkt und deine Kultur verbessert.

Wistia, ein Internetvideo-Hosting- und -Analyseunternehmen, musste 2013 während eines unerwarteten Vorfalls, bei dem die Statistikinfrastruktur zum völligen Stillstand kam, lernen, wie wichtig die Aufrechterhaltung der Agilität ist. Das Unternehmen war darauf nicht vorbereitet und ging in der Flut an Supporttickets von verärgerten Kunden regelrecht unter. Die erste Änderung war die Erstellung einer eigenen Statusseite, um den Teams in solchen Situationen das Leben zu erleichtern.Ein selbst erstelltes Statuskommunikationstool muss jedoch auch zusätzlich zu den Kernprodukten unterstützt werden. Schnell wurde klar, dass sich das 20-köpfige Team die Kosten hierfür zur damaligen Zeit nicht leisten konnte. Also wurde von der hauseigenen Lösung zu Statuspage gewechselt.

Jordan Munson, Support Enginner bei Wistia beschrieb diesen Wechsel: "Nachdem wir einige Monate lang von unserer zwar hilfreichen, aber Feature-armen hauseigenen Lösung leicht frustriert waren, beschlossen wir, dass wir etwas mehr benötigten und uns gleichzeitig weniger Wartungsaufwand wünschten. Hier kam Statuspage ins Spiel. Seit dem Wechsel zu Statuspage konnten wir endlich schnell und einfach unsere Kunden zum Status unserer Anwendung auf dem Laufenden halten – was ja eigentlich von Anfang an unser Ziel war. Allerdings brauchte es einen massiven Ausfall und die Erstellung eines neuen Produkts, bis wir unser Ziel erreicht hatten. Ein paar Jahre später sieht unser Prozess deutlich reibungsloser aus. Die Benutzer erhalten bei Ausfällen direkt von uns Updates. Sie wissen, wo sie diese finden und Updates an unserer Statuspage erscheinen automatisch auch an bestimmten anderen Orten."

Munsons Team hat aus dem Ausfall 2013 wahrlich das Beste herausgeholt (einen neuen und verbesserten – und skalierbaren – Prozess zur Kommunikation rund um Vorfälle). So sieht eine optimale agile Reaktion auf Veränderungen aus.

Retrospektiven leisten einen wichtigen Beitrag zu diesem Agile-Grundsatz. Eine Retrospektive gibt deinem Team die Möglichkeit, mit etwas Abstand zu diskutieren, was bei der Kommunikation während des Vorfalls gut funktioniert hat, was nicht und vor allem was ihr zur Vorbeugung vor ähnlichen Problemen tun könnt. Lass dich nicht dazu verleiten, auf die Retrospektive zu verzichten, nachdem ein Vorfall als "gelöst" gekennzeichnet wurde oder wenn du findest, dass dein Team hervorragende Arbeit geleistet hat. Es gibt in der Kommunikation zu Vorfällen immer etwas zu verbessern, was immer auch eine Chance ist, die Beziehungen zu den Benutzern zu stärken und ihr Vertrauen in euch zu erhöhen.

Kommen wir auf den ersten Wert aus dem Agilen Manifest zurück: Retrospektiven erfordern unbedingt menschliche Kommunikation, um erfolgreich zu sein und langfristige Ergebnisse zu liefern. Unten siehst du ein paar Beispiele für die Begriffe, die bei der Besprechung der Vorfallbehebung in einem Retrospektiv-Meeting berücksichtigt werden sollten. Einige dieser Begriffe sollten auch Teil des Post-Mortem-Berichts bzw. des Reviews nach Vorfällen (PIR) sein, den du den Benutzern nach der Servicewiederherstellung zukommen lässt. Agile bedeutet, kontinuierlich an Verbesserungen zu arbeiten – nicht nur bei der Vorfallbearbeitung, sondern auch bei den Beziehungen zu deinen Teamkollegen und der Ausübung deiner Rolle in Stresssituationen.

Wir sprechen im Zusammenhang mit Agile sehr viel über Vertrauen, und auch dieses Anwendungsbeispiel hierbei keine Ausnahme. Eine effektive Kommunikation rund um Vorfälle ist nur mit Vertrauen und den nötigen Berechtigungen möglich. Alle Teams im Unternehmen sollten über die Berechtigung und das Wissen verfügen, um den Benutzern Informationen zu Vorfällen mitzuteilen. Darüber hinaus sollten die einzelnen Mitarbeiter darauf vertrauen können, dass jeder seine zugewiesene Aufgabe während einer Incident Response erledigt – und bei unerwarteten Vorkommnissen ohne zu zögern einspringt, auch wenn dadurch vom Prozess abgewichen wird. Wenn du deinen Teams die effektive Kommunikation rund um Vorfälle anvertraust, werden die Kunden schneller informiert, wodurch wiederum das Vertrauen und die Treue der Kunden steigt (67 % der Kunden von Statuspage berichten, dass Statuspage das Vertrauen ihrer Benutzer gestärkt hat!). Ein Gewinn für alle Beteiligten.