Donnerstag, 16. August 2018

Krisenkommunikation

FS
Bild: Flickr / Katjung - CC BY-SA 2.0
Zu den interessanteren Medienbeiträgen der letzten Zeit gehört ein Interview mit dem Psychologen Reiner Kemmler zum Thema Krisenkommunikation auf Flughäfen. Auf den ersten Blick erscheint das Thema sehr spezifisch, auf den zweiten Blick finden sich aber viele Parallelen zur Agilität: eine bereits komplexe Ausgangssituation, unerwartete Geschehnisse mit zum Teil grossen Auswirkungen, autonom und unkoordiniert vorgehende Akteure, etc. Vieles lässt sich auf andere grosse Unternehmenen und Behörden übertragen.

Der Ausgangspunkt: die Krise

Wo Komplexität zu finden ist, da gibt es auch Krisen, das ist fast schon ein Naturgesetz. Ausfallende Flüge und gestandete Passagiere sind da nur ein Beispiel, andere wären insolvent gehende Geschäftspartner, disruptive Umwälzungem am Markt oder in der Technik, offensichtlich werdende Fehlplanungen, sich ändernde gesetzliche Rahmenbedingungen, Wirtschaftskrisen und vieles mehr. Sie alle stellen die betroffenen Organisationen vor grosse Herausforderungen, von denen es hier um eine gehen soll: wie kann die Krise so kommuniziert werden, dass Märkte, Mitarbeiter und Kunden beruhigt werden statt durch Panikreaktionen alles zu verschlimmern?

Verstärkung der Krise durch fehlendes Reaktionsvermögen

Es ist ein unschöner Klassiker: über Jahre werden Abäufe so auf Effizienz getrimmt, dass jeder Mitarbeiter zu fast hundert Prozent ausgelastet ist und fast jeder Prozess auf dem kritischen Pfad verläuft. Dass eine hundertprozentige Auslastung schlecht ist zeigt sich im Krisenfall - die für eine schnelle Reaktion notwendigen Kapazitäten und Freiräume wurden wegrationalisiert, jeder Zusatzaufwand führt zu Überlastung, Rückstauungen und Stillstand. Und wenn sich die Arbeit erst aufgestaut hat kann sie nur durch Überstunden wieder abgebaut werden, mit den bekannten Folgen: Übermüdung, Frustration, dadurch überhastete und fehlerhafte Kommunikation, die dann noch mehr Aufwände verursacht.

Herrschaftswissen und Flurfunk

Irgendwann ist es offensichtlich - sensible Informationen können während und nach ihrer Bekanntgabe nicht mehr ausreichend genug kommunikativ begleitet werden um Unruhe und Fehldeutungen zu vermeiden. Häufig führt das zu der Entscheidung, dass so lange mit der Bekanntgabe gewartet wird bis man glaubt die Lösung gefunden und umgesetzt zu haben. Allerdings ist das in der Regel nicht möglich, irgendwo sickern immer Teilinformationen durch, verbreiten sich, werden schlimmstenfalls aufgebauscht und sorgen für Misstrauen gegenüber offiziellen Verlautbarungen. Selbst wenn jetzt offen kommuniziert werden würde, gäbe es den Verdacht, dass Informationen zurückgehalten werden.

Endstadium: aus der Krise wird Chaos

Letztendlich treten genau die Gruppendynamiken und Absetzbewegungen auf die man vermeiden wollte. Verunsichert von der schwerfälligen und intransparenten Kommunikationspolitik versuchen Kunden, Partner und Mitarbeiter sich vorsorglich in Sicherheit zu bringen. Aufträge werden storniert, Projekte nicht verlängert, statt für das gemeinsame Ziel wird nur noch für die eigene Absicherung gearbeitet, ganze Abteilungen beschliessen "zu überwintern" bis sich die Situation beruhigt hat. Beruhigende Verlautbarungen werden grundsätzlich nicht mehr geglaubt sondern als Vertuschungsversuche interpretiert. Schlimmstenfalls setzt sich die Situation im kollektiven Gedächtnis der Organisation fest und belastet die Zukunft.

Aber wenn nicht so - wie dann?

Im Grunde durch die Umkehrung der oben genannten Antipattern. Statt die gesamt Organisation bis ins letzte Eck durchzuoptimieren müssen freie Kapazitäten vorhanden sein die auch kurzfristig Kommunikationsaufgaben übernehmen können sobald es nötig ist. Ein passender Vergleich wäre ein Feuerwehrmann, bei dem die Brandbekämpfung auch nur einen kleinen Teil der Arbeit einnimmt. Des weiteren empfiehlt sich grösstmögliche Offenheit von Anfang an. Klar und offen zu zu kommunizieren, dass es eine Krise gibt mag zwar zu Beginn schmerzhaft sein, das dauerhafte Misstrauen das sich aus dem Zurückhalten von Informationen ergibt ist aber langfristig um ein Vielfaches verheerender. Und wenn klar ist, dass Reaktionen möglich sind und bereits stattfinden verliert die Ungewissheit viel von ihrem Schrecken. Es ist ein Allgemeinplatz aller agilen Vorgehensmodelle - wenn man in der Lage ist kurzfristig auf Veränderungen zu reagieren ist es unkritisch wenn sich die Realität anders entwickelt als geplant.

Natürlich muss dafür auch die Gesamtorganisation zu Reaktionen in der Lage sein und nicht nur die Kommunikationsabteilung. Das ist aber dann ein Thema für sich.

Montag, 13. August 2018

Planning Poker

FS
Bild: Wikimedia Commons / Rachmaninoff - CC BY-SA 4.0
Wer bereits Zeit in einem Scrum-Projekt verbracht hat wird das Bild kennen. Irgendwo stellt ein Product Owner eine Idee vor und bittet sein Entwicklungsteam um eine Aufwandsschätzung. Kurz darauf halten die Teammitglieder Karten oder Mobile Apps mit Zahlen darauf hoch und nehmen so die Schätzung vor. Da immer wieder nach dieser zunächst merkwürdig aussehenden Methode gefragt wird kommt hier eine Erläuterung dazu, zum so genannten Planning Poker.

Zunächst einige Kontextinformationen: mit Planning Poker werden normalerweise Story Points geschätzt. Story Points sind personenunabhängige Aufwandseinheiten und nicht mit Stunden und Tagen gleichzusetzen, mehr zu ihnen steht hier und hier. Und Planning Poker ist kein offizieller Teil von Scrum, man könnte es also auch weglassen. Es wird allerdings trotzdem von fast jedem Scrum Team genutzt, da es sich sich als good Practice durchgesetzt hat (mehr dazu hier).

Zur Anwendung: normalerweise werden alle Teammitglieder aufgefordert ihre Schätzung (Karte) in Ruhe auszuwählen, sie noch nicht zu nennen und zu warten bis auch die anderen damit fertig sind. Dann werden die Karten gemeinsam aufgedeckt. Dadurch wird vermieden, dass ein Meinungsführer die anderen bewusst oder unbewusst beeinflusst, die Schätzung ist dadurch repräsentativer.

Da die von den Teammitgliedern geschätzten Werte normalerweise nicht identisch sind kann im nächsten Schritt versucht werden ein einheitliches Verständnis zu erzielen. Immer wieder anzutreffen sind an dieser Stelle Mehrheitsentscheidungen oder Durchschnittswerte, wodurch aber Potential verschenkt wird. Besser ist es, wenn die oberen und unteren Grenzwerte erläutert werden, die Teammitglieder kommen dadurch oft zu Einsichten die sie selbst nicht gehabt hätten.

Neben diesen beiden sehr häufigen Vorgehensweisen gibt es auch weitere, die immer wieder anzutreffen sind. Manche Teams führen für die selbe Anforderung mehrere Schätzrunden nacheinander durch, bis alle die selbe Zahl hochhalten, andere nehmen alle Schätzungen ab einer bestimmten Punktezahl zum Anlass die jeweiligen Anforderungen kleinzuschneiden, wieder andere haben Joker-Karten, mit denen sie einen Experten konsultieren können, etc., etc.

Was all diesen Techniken geimeinsam ist: neben dem Ermitteln des (abstrahierten) Aufwandes steht beim Planning Poker auch ein zweites Ziel im Mittelpunkt - das bessere Verstehen der Anforderung. Die verschiedenen Anwendungsfälle der Karten können dafür sorgen, dass die Ideen des Product Owners gründlicher diskutiert und hinterfragt werden als es normalerweise der Fall wäre. Alleine das ist schon ein Mehrwert.

Donnerstag, 9. August 2018

Agile Roadmaps

FS

Zu den klassischen Planungsinstrumenten gehören die so genannten Roadmaps. bei ihnen handelt es sich (vereinfacht gesagt) um einen Zeitstrahl auf dem verschiedene Fertigungsschritte und -phasen nacheinander und parallel zueinander angeordnet sind. Dieses Instrument hat unverkennbare Stärken: man kann planen was wann gemacht werden soll (ggf. auf dem kritischen Pfad), kann sequentielle Abhängigkeiten darstellen und den Fortschritt überprüfen. Wie viele anderen Planungswerkzeuge ist es aber auch denkbar unflexibel.

Roadmaps gehen immer von einer einzigen Ablauf-Reihenfolge aus, der die man für die ideale hält. Dass es mehrere Varianten geben kann von denen jede ihre Vor- und Nachteile hat geht dabei unter. Auch ist es in der Regel schwierig nachträgliche Änderungen vorzunehmen, und zwar nicht nur da diese den vorgegebenen Zeitplan durcheinanderbringen würden - alleine die Rechtfertigungen und Schuldzuweisungen dafür, dass der ursprüngliche Plan eben doch nicht ideal war, rauben Zeit und Energie.

Eine flexiblere Variante könnte sich an den Streckenempfehlungen der gängigen Karten- und Navigationsdienste orientieren. Gibt man in ihnen Start- und Zielpunkt ein erhält man verschiedene Optionen zwischen denen man wählen kann. Im Fall des oben gezeigten Screenshots bietet etwa die südliche Route in der Mitte noch eine Alternativstrecke, die nördliche aber nicht. Und während die nördliche und die mittlere Route mehrere grosse stausgefährdete Stellen haben hat die südliche nur wenige, führt dafür aber an mehreren Baustellen vorbei. Die Parallelen zu einer Projekt- oder Produktplanung sind offensichtlich.

Durch die frühen oder späten Abzweigungen lassen sich frühe oder späte Architekturentscheidungen symbolisieren, Systeme oder Teams mit begrenzter Bearbeitungskapazität stellen staugefährdete Stellen dar und Systeme an denen auch andere Teams und Projekte arbeiten sind Baustellen. Und sind derartige Faktoren transparent lassen sich auch andere Informationen zu ihnen in Bezug setzen. Nocheinmal zum Screenshot oben: die Südstrecke hat zwar eine etwas kürzere voraussichtliche Fahrtzeit (Projektdauer), durch die Baustellen aber auch ein ungleich höheres Risiko, dass etwas Ungeplantes passiert. Ist der Zeitgewinn dieses Risiko wert? Eine interessante Frage.

Man sieht: die flexiblere Roadmap bietet nicht nur alternative Wege, die ggf. auch eine spätere Umplanung ermöglichen, sie bietet zu den Varianten auch Kontextinformationen, die eine wesentlich differenziertere Abwägung ermöglichen als die klassische, lineare Roadmap. Und die Visualisierung in einer Form die fast jedem Menschen aus seinem Alltag bekannt ist bietet dazu noch einen wesentlich höheren Erkennungs- und Erinnerungswert. Auch das sollte nicht unterschätzt werden.

Dass diese Form der Planung nicht häufiger verwandt wird hat übrigens einen zentralen Grund: sie lässt sich kaum in Powerpoints und Planungstools darstellen sondern praktisch nur auf einer physischen Wand. Und Planung die nicht auf Powerpoints passt ist in vielen Organisationen keine richtige Planung. Das wäre aber ein Thema für sich.

Montag, 6. August 2018

Killing the Monster Merge

FS
Eine enthusiastisch vorgetragene Einführung in das Thema Continuous Integration, und dazu noch eine die mit relativ wenig technischem Verständnis nachvollziehbar ist. Zwar mit einem kleinen Werbeblock ganz am Ende, aber den muss man sich ja nicht ansehen.

Donnerstag, 2. August 2018

Lernen, wie man nein sagt

FS
Grafik: Pixabay / Geralt - CC0 1.0
Zu den wichtigsten Dingen die man lernen muss wenn man beginnt agil zu arbeiten gehört das "Nein"-sagen. Nur wenn man nicht mehr Arbeit beginnt als man beenden kann wird sie in vertretbarer Zeit fertig, nur wenn man nicht jeden Feature-Wunsch umsetzt vermeidet man kaum noch erweiterbare Bloatware, etc., etc. Das große Problem: viele Menschen haben das nie gelernt, zumindest im beruflichen Kontext nicht.

"Ein Nein akzeptiere ich nicht als Antwort" ist eine beliebte Management-Floskel, die man vom Kleinunternehmen bis zum Grosskonzern immer wieder findet. Die Mitarbeiter solcher Firmen lernen irgendwann, dass das Nein-sagen nur zu Eskalation, Druck und Stress führt und lassen es einfach. Stattdessen wird unkritisch fast alles abgenickt und zugesagt, selbst wenn diese Zusagen völlig unrealistisch sind. Erst kurz vor Schluss gibt es dann die Rückmeldung "Ging doch nicht".

Selbst wenn in diesen Kontexten ein Kulturwandel stattfindet in dem die Ablehnung unrealistischer und nicht zielführender Anforderungen möglich und erwünscht ist, tun viele Mitarbeiter sich schwer die jahrelange berufliche Sozialisation zu überwinden und sagen doch immer wieder Dinge zu, die bei realistischer Betrachtung eigentlich abgelehnt werden müssten. Wenn man es nicht gewohnt ist kann das Nein-sagen etwas sein was man wieder lernen muss.

Eine Methode die ich vor kurzem bei einem der von mir gecoachten Teams kennengelernt habe hat mir aufgrund ihrer Einfachheit gefallen: gegen Ende einer Retrospektive verteilte der Scrum Master fünf "Nein-Karten" an jedes Teammitglied. Die damit verbundene Übung - während des Sprints in fünf relevanten Situationen Nein sagen, die Situation auf der Karte notieren und in der nächsten Retrospektive vorstellen.

Als Effekt kommt es nicht nur dazu, dass mehr nicht zielführende Anfragen abgelehnt werden, die Teammitglieder bekommen auch Übung darin es zu tun. Und dadurch, dass die jeweiligen Situationen in der Retrospektive besprochen werden können, kommt auch eine Kommunikation darüber in Gang, wie man Ablehnungen ausspricht, welche Reaktionen darauf entstehen können und wie man mit denen konstruktiv umgeht. Auch das gehört nämlich zum Nein-sagen dazu.
Powered by Blogger.