Donnerstag, 29. März 2018

Kommentierte Links (XXXV)

Bild: Pixabay / Bru-nO - Lizenz

  • Peter Lee: My Ideal Agile Delivery Report

    Die Frage nach regelmässigen Status Reports ist fast unabwendbar wenn agile Teams in einer nicht- oder teil-agilen Unternehmensumwelt arbeiten. Wenn das zur Folge hat, dass das Team beginnt die "traditionellen" Reportingpflichten zu erfüllen, führt das häufig zurück in die alten Management-Verhaltensweisen von Detailkontrolle und Micromanagement. Dahinter steckt keineswegs immer eine böse Absicht - häufig ist es der Wunsch der jeweiligen Manager "Dinge anschieben zu können". Wenn aber die "klassischen" Metriken die einzige verfügbare Einsicht sind, dann erfolgt die "Optimierung" eben darüber. Die von Peter Lee zusammengetragenen agil-relevanten Metriken können in solchen Konstellationen einen anderen Blickwinkel bieten und den Management-Tatendrang in konstruktivere Richtungen lenken.


  • Peter Cappelli/Anna Tavis: HR Goes Agile

    Beim Thema Agile HR würde ich differenzieren. Es gibt auf der einen Seite die Prinzipien und Verhaltensweisen die eine HR-Abteilung braucht um selbst agil zu arbeiten. Dazu hatte ich bereits etwas geschrieben. Und es gibt auf der anderen Seite Massnahmen die HR-Abteilungen ergreifen können um Agilität im restlichen Unternehmen zu befördern. Darum geht es im hier verlinkten Artikel. An den Beispielen Leistungsbeurteilung, Coaching, Teamfokussierung, Gehaltsanpassung, Personalgewinnung und Weiterbildung gehen Peter Capelli und Anna Tavis Herausforderungen und Möglichkeiten durch und schliessen mit einem bemerkenswerten Fazit: nachdem HR-Abteilungen jahrzehntelang darauf fokussiert waren andere zu ändern sind es jetzt sie selbst die sich ändern müssen, wenn sie dazu noch in der Lage sein wollen.

  • Wolf Steinbrecher: Agiles Projektmanagement in der Öffentlichen Verwaltung - Wie muss Scrum angepasst werden?

    Sollte jemand ein Beispiel für Cargo Cult suchen - hier ist es. Hier wird Scrum so verbogen, dass es nicht mehr richtig funktionieren kann. Und das nicht etwa weil hier an Länge und Frequenz der Meetings herumgedoktort wird, sondern weil bewusst darauf verzichtet wird, die durch die Methode offensichtlich werdenden Root Causes ineffektiven Arbeitens anzugehen und zu beheben. Strukturelle Überplanung der eigenen Mitarbeiter, permanentes Multitasking und fehlende Meetingdisziplin sind keineswegs gottgegebene Schicksale denen man nicht entkommen kann, als solche werden sie hier aber behandelt. Gerade als jemand der seine Berufslaufbahn in einer Behörde begonnen hat weiss ich, dass hier Verbesserungen möglich sind. Wer darauf verzichtet und stattdessen Symptome behandelt hebelt das Inspect & Adapt aus, so dass aus Scrum Cargo Cult wird.

  • Jonas Zeh: Warum aus Einzelkämpfern selten gute Manager werden

    Spoiler: weil sie nicht teamfähig sind. Die hier erläuterte wissenschaftliche Studie ist angeblich die erste, die das Peter-Prinzip (Menschen werden so lange befördert bis sie eine Position erreichen die sie überfordert) validiert. Der interessante Aspekt ist, dass zu Beginn der Karriere besonders die erfolgreichen Einzelkämpfer befördert werden, weil sich deren Leistungssteigerungen am einfachsten messen lassen. Da in Führungspositionen aber Teamfähigkeit gefordert ist gelangen so häufig die falschen Menschen in diese Jobs.

Montag, 26. März 2018

Mother Tongue

Bild: Flickr / Nicolas Raymond (1, 2, 3, 4) - CC BY 2.0
Dass verschiedene Personen sich mit dem Erlernen agiler Frameworks unterschiedlich schwer tun dürfte keine besondere Überraschung sein. Wer Jahrzehnte in einem stark hierarchischen Umfeld verbracht hat, wird sich mit Selbstorganisation schwerer tun als jemand der es von Anfang an gewohnt ist. Wer beruflich in einer offenen Feedbackkultur sozialisiert wurde wird Verbesserungspotentiale offener ansprechen als einer der im Job nur Konfliktvermeidungskulturen kennt. Etc. All das ist erwartbar und nachvollziehbar. Auf den ersten Blick überraschend ist aber ein weiterer Faktor: die Muttersprache.

Über die Jahre habe ich mit Menschen aus verschiedenen englischsprachigen Ländern zusammenarbeiten dürfen - aus England, Irland, den USA, Kanada und Neuseeland. Auch hier gab es Ausreisser nach oben und unten, im Großen und Ganzen taten sich diese Damen und Herren aber deutlich leichter mit dem Verständnis von Kanban, Scrum & Co als die aus anderen Herkunftsländern. Während bei den deutschen Kollegen häufig recht abenteuerliche Missverständnisse über den Sinn und Zweck von Meetings und Rollen bestanden, war das bei den englischen Muttersprachlern deutlich seltener der Fall.

Der banale Hintergrund: viele Begrifflichkeiten der agilen Frameworks sind normale Begriffe der englischen Berufs- und Alltagssprache und ergeben für den der sie kennt ganz intuitiv den richtigen Sinn. Replenishment und Refinement, Product Owner und Retrospektive, Servant Leader und Backlog sind gute Beispiele dafür. Für jeden der Englisch nur als Fremdsprache spricht sind diese Begriffe dagegen unklar oder vielleicht sogar unbekannt. Bedingt dadurch können sie versehentlich oder absichtlich mit neuen (z.T. falschen) Bedeutungen aufgeladen werden, selbst wenn diese dem eigentlichen Wortsinn widersprechen.

Was häufig gefordert wird um derartige Fehldeutungen zu vermeiden ist eine Übersetzung ins Deutsche, was im Anwendungsfall aber schwierig ist. Zum einen würde vieles künstlich klingen (der Produkt-Eigner, die Rückstau-Verfeinerung), zum anderen bestünde die Gefahr, dass die Begriffe in den unterschiedlichen Sprachen beginnen sich auseinanderzuentwickeln (wie im Fall des im Lean/Kanban-Umfeld häufig verwandten Wortes "Verschwendung", das im Deutschen einen anderen Bedeutungsinhalt hat als das japanische Ursprungswort "Muda").

Eine bessere Lösung kann sein, im Rahmen der Coaching- und Reflektionsprozesse immer wieder darauf hinzuweisen was hinter diesen Worten steht, eine andere wären gut sichtbar angebrachte Erläuterungen zentraler Begriffe in den Teamräumen (z.B. Replenishment 🡒 Aufnehmen neuer Anforderungen). Fehldeutungen lassen sich dadurch zwar nicht verhindern, dafür aber erkennen und korrigieren.

Donnerstag, 22. März 2018

Die Klagemauer

Bild: Wikimedia Commons / Israel Tourism - CC BY-SA 2.0
Gerade in grossen Organisationen oder im Rahmen agiler Transitionen können häufig Situationen auftreten die für Teams frustrierend sind. Schwierig ist das vor allem dann wenn die Ursachen dieser Frustration in einem Bereich liegen, der vom Team selbst nicht beeinflusst werden kann. Selbst wenn der Scrum Master und das Management an Verbesserungen arbeiten kann es in Konzernen mitunter Monate dauern bis spürbare Verbesserungen eintreten. In solchen Zeiträumen besteht die Gefahr, dass die Retrospektiven so stark von diesen Situationen überlagert werden, dass sie zu reinen "Jammer-Meetings" werden. Ein kontinuierlicher Verbesserungsprozess ist dann nur schwierig am Leben zu halten.

Die naheliegende Lösung ist es, derartige Themen wegzumoderieren und den Focus der Meetings auf Themen zu legen in denen das Team bereits die Ressourcen und Kompetenzen hat um selbst für Verbesserungen zu sorgen. Das Risiko bei diesem Vorgehen ist, dass bei den Teammitgliedern der Eindruck entstehen kann, dass für sie wichtige Themen nicht zugelassen würden. Letztendlich eine Zwickmühle: entweder die Retrospektive wird von fruchtlosem Jammern geprägt oder das Team ist unglücklich weil ihm ein Ventil zum Ablassen der aufgestauten Frustration fehlt.

Ein Lösungsansatz den ich in einem meiner Teams umgesetzt habe war eine so genannte Klagemauer. Zu Beginn der Retrospektive versammelte sich das Team vor einer der Wände des Meetingraums, über der auch ein Banner mit eben diesem Namen hing. Ähnlich wie im Fall der echten Klagemauer konnte hier den eigenen Gefühlen freier Lauf gelassen werden. Aus Praktikabilitätsgründen wurde zu diesem Zweck allerdings nicht wie in Jerusalem üblich die eigene Kleidung zerrissen, stattdessen wurden die (im Moment noch) nicht zu verändernden Ärgernisse bekanntgegeben und auf Zetteln an die Wand gehangen. Nachdem jeder auf diese Weise Druck ablassen konnte ging es weiter mit dem eigentlichen Meeting.

Was bei einem solchen Ansatz zu beachten ist: er sollte nicht zu einem Dauerzustand werden. Wenn sich über einen längeren Zeitraum nichts ändert wird die immer weiter anwachsende Menge an "Klage-Zetteln" irgendwann eine deprimierende Wirkung ausüben. Wenn es hingegen irgendwann gelingt größere Impediments zu beseitigen kann das gemeinsame Abnehmen der über die Zeit gesammelten Post Its zu einem Gemeinschaftsereignis werden bei dem das Team symbolisch von einer Last befreit wird. Es kann sprichwörtlich zusehen wie die gesammelten Impediments verschwinden. Für die Moral im Team und den Glauben daran, dass Verbesserungen möglich sind ein nicht zu unterschätzender Faktor.

Montag, 19. März 2018

Marxismus und Leninismus

Bild: Flickr / Kent Wang - CC BY-SA 2.0
Da agilen Vorgehensweisen nachgesagt wird, sie würden die Arbeitswelt revolutionieren - was läge näher als Revolutionstheorien auf sie anzuwenden? Und mit wem wenn nicht mit anderen Scrum Mastern und Agile Coaches sollte man das diskutieren? Folgerichtig fand vor Kurzem ein Gespräch mit zweien von ihnen statt, das Gesprächsthema waren Marxismus und Leninismus. Das Ganze natürlich nicht dahingehend, dass Agilität gleich Kommunismus wäre, sondern darauf abzielend, die Gesetzmässigkeiten revolutionärer Bewegungen (unabhängig von der dahinterstehenden Ideologie) auf agile Transitionen anzuwenden.

Zunächst zum Marxismus. Marx ging davon aus, dass die Revolution aufgrund von Sachzwängen unvermeidbar sein würde. Sein berühmter Satz aus dem Werk "Kritik der Politischen Ökonomie" wird häufig zitiert: "Es ist nicht das Bewußtsein der Menschen, das ihr Sein, sondern umgekehrt ihr gesellschaftliches Sein, das ihr Bewußtsein bestimmt." Er bedeutet, dass eine Umwälzung unabwendbar stattfinden muss, sobald die wirtschaftlichen Rahmenbedingungen eine bestimmte Entwicklungsstufe erreicht haben. An dieser Stelle gibt es Parallelen zu den agilen Vordenkern: diese gehen davon aus, dass volatile und sich rapide ändernde Märkte und Technologien gar keine andere Lösung zulassen als eben die Agilität.

Das Problem an dieser Stelle: bis die Veränderung stattfindet kann es dauern. Vielleicht ist die notwendige Ausgangslage noch nicht zur Gänze erreicht, vielleicht ist das Beharrungsvermögen der bisherigen Ordnung (noch) zu groß, vielleicht findet eine Gegenbewegung statt. Was immer es auch im Einzelfall ist, das Ergebnis ist, dass der Umschwung nicht richtig vorankommt, im schlimmsten Fall sogar stagniert. Sowohl in Revolutionen als auch in agilen Transitionen ein bekannten Phänomen. Marx' Lösung: abwarten. Die Revolution lässt sich nicht aufhalten, sie kommt ggf. nur etwas später.

Nun hat nicht jeder diese Geduld, wie in praktisch jedem anderen Bereich gab und gibt es auch hier Menschen die gerne alles beschleunigen würden. Unter ihnen ist vor allem Lenin zu nennen, der sich in seinem Werk "Was tun?" zuerst über die geringen Erfolge der Vergangenheit beklagte um dann das Konzept der "revolutionären Avantgarde" zu entwickeln, einer Gruppe die in ihrer geistigen Entwicklung schon weiter ist als der Rest der Bevölkerung und diese durch Organisation und Agitation dazu bringt weiter zu gehen als sie es von sich aus tun würde. Aus diesem Blickwinkel betrachtet kann man in vielen agilen Transitionsprogrammen "Leninisten" finden, und zwar sowohl im Management als auch unter den Agile Coaches.

Ohne historische Parallelen zu sehr strapazieren zu wollen - der Ansatz der revolutionären Avantgarde war kein Erfolg. Gefangen in der Idee, dass Unverständnis und Widerspruch nur Symptome geistiger Rückständigkeit sein können begannen die selbst ernannten Vorreiter der Revolution die anderen Menschen zu bevormunden und zu entmündigen, was dazu führte, dass diese sich abwandten und in die innere oder äussere Emigration gingen. Die angestrebte neue Welt bestand nur als Fassade und kollabierte schließlich.

Ein ähnliches Schicksal haben viele agile Transitionen vor oder hinter sich. Sobald das Gefühl um sich greift für dumm gehalten und bevormundet zu werden wird die Veränderung (egal wie gut sie gemeint ist) zu einem nur noch durch Befehl und Gehorsam am Leben gehaltenen Fremdkörper, der bei der nächsten Gelegenheit abgestossen wird. Bis dahin greifen Konzern-Anarchismus und brauchbare Illegalität um sich. Aus diesem Grund sollte "Leninismus" sobald er erkannt wird angesprochen und mitsamt des dahinterliegenden Menschenbildes aufgearbeitet werden. Geschieht das nicht besteht das hohe Risiko, dass das ganze Transitionsvorhaben scheitert.

Donnerstag, 15. März 2018

Kreislauf, Thromben und Embolien

Bild: Pixabay / Quimono - Lizenz
Ein schönes Beispiel für Systeme in denen sich alles im permanenten Fluss befindet ist der menschliche Körper, bzw. dessen Blutkreislauf. Ähnlich wie in einem idealen Produktionssystem befindet er sich in einem Zustand der permanenten Bewegung und sorgt dafür, dass sich bestimmte Stoffe in einem immerwährenden Strom von einem Teilsystem zum anderen bewegen. Umgekehrt betrachtet kann man auch den Arbeitsfluss eines Unternehmens als dessen Blutkreislauf betrachten, der es versorgt und am Leben hält.

Um die Parallelen weiterzutreiben: sowohl für den Körper als auch für ein Unternehmen ist es von existentieller Bedeutung, dass der Fluss nicht ins Stocken gerät. Sobald das der Fall ist besteht die Gefahr, dass sich Verklumpungen bilden, im Körper in Form von geronnenem Blut (Thrombose), im Unternehmen in Form von Bürokratie. Beides sorgt dort wo es sich bildet dafür, dass Verengungen und Flaschenhälse entstehen, vor denen der Fluss sich aufstaut.

Allein das wäre bereits bedenklich, die wirkliche Gefahr steht aber erst noch bevor. Dann nämlich wenn sich aus den Engstellen Thrombosen lösen und sich im Blutstrom auf die Wanderung durch das System begeben. Im Kontext der Organisation: wenn ein Bürokrat in einen anderen Bereich versetzt wird, z.B. weil er im Rahmen der Versetzung eines Vorgesetzten "mitgetrieben wird". Sobald das passiert besteht das unmittelbare Risiko von Embolien.

Eine Verklumpung die in einem größeren Durchlass noch unbedenklich ist kann nämlich einen kleineren vollständig verschliessen. Die Folge: die dahinter liegenden Teilsysteme werden vom Versorgungskreislauf abgeschlossen und sterben ab. Im Fall des Körpers durch Infarkte, in Organisationen durch ausbleibende Aufträge oder Vorprodukte, wodurch das Produktionsvermögen der betroffenen Abteilung verkümmert, bis hin zur dauerhaften Dysfunktion.

Um derartige schwere Schäden zu vermeiden sollte es sowohl im Körper als auch in Unternehmen oberste Priorität sein den Fluss an keiner Stelle ins Stocken geraten zu lassen, selbst dort nicht wo eine kleine Verklumpung auf den ersten Blick unproblematisch erscheint. Denn wenn eine Thrombose sich erst auf dem Weg durch das System befindet sollte man sich auf unkalkulierbare Auswirkungen gefasst machen. Für Gegenmassnahmen ist es dann meistens zu spät.

Montag, 12. März 2018

Agile Product Ownership kurz zusammengefasst

Hätte ich das früher gewusst. Jahrelang habe ich auf die Frage ob es das Video Agile Product Ownership in a Nutshell auf deutsch gibt mit leider nein geantwortet. Dabei gibt es die Übersetzung schon seit 2013. Und jetzt auch hier.

Donnerstag, 8. März 2018

Die richtigen Helden belohnen

Bild: Flickr/W_Minshull - CC BY 2.0
Eines der Teams bei einem meiner Kunden hatte den Ruf, dass es am Rand des Scheiterns stehende Projekte auf den letzten Metern "herumreissen" konnte. Wenn die Deadline bedrohlich nah gerückt war und den Managern bereits der Schweiss auf der Stirn stand beschlossen die Teammitglieder, dass es mal wieder an der Zeit wäre "ein paar Nächte durchzumachen". Das Team schloss sich irgendwo ein, arbeitete praktisch rund um die Uhr und schaffte es tatsächlich auch jedesmal irgendetwas abzuliefern was dem ursprünglich geplanten Ergebnis zumindest nahe kam. Regelmässig bekam es dafür vom Management öffentliches Lob und gewisse Privilegien, sei es in Form flexiblerer Arbeitszeiten oder durch größere Freiheiten bei Coding Standards und Methodentreue.

"Von solchen Leuten brauchen wir mehr", meinte das Management, und Teil meines ursprünglichen Auftrages war es, einen derartigen Geist auch in anderen Teams zu fördern. Die Überraschung war groß als ich nach kurzer Zeit einen genau gegenteiligen Ratschlag gab - diesem Team sollten seine Privilegien genommen werden, Hauruck-Aktionen sollten nach Möglichkeit vermieden werden und vor allem sollte nach dem "Herumreissen" öffentliches Lob nur noch sehr sparsam verteilt werden.

Der Hintergrund war, dass die so heldenhaft bewältigten Krisensituationen grösstenteils selbst verursacht waren, und zwar zum einen eben durch die Befreiung von Coding Standards (Qualitätssicherung) und Methodentreue (Verbesserungsprozessen), zum anderen aber auch durch Schlampigkeit und Prokrastination. Im Bewusstsein gegen Ende finale Rettungsaktionen durchführen zu können war die Arbeitsmoral in den Vorwochen auf niedrigem Niveau, "flexible Arbeitszeiten" bedeutete in dieser Zeit spät zu erscheinen, lange Pausen zu machen und früh zu gehen.

Besonders verheerend wirkte in diesem Zusammenhang, dass andere Teams zwar deutlich professioneller arbeiteten, dafür aber kein Wort der Anerkennung bekamen. Im Gegenteil, wer realistisch plante, kontinuierlich lieferte und sicherheitshalber ein kleines Zeitpolster am Ende vorsah musste sich öffentlich fragen lassen warum er nicht sein konnte wie der Haufen Helden Chaoten, dessen hektische nächtliche Rettungsaktionen Büro und Code in einem Zustand wilder Unordnung hinterliessen. Entsprechend schlecht war es in den professionell arbeitenden Teams um die Motivation bestellt.

In den folgenden Team- und Review-Meetings wurden Belohnungen anders verteilt als bisher. Die kontinuierlich liefernden Teams wurden gelobt und erhielten mehr Zeit für Innovation und Verbesserung, dem Hauruck-Team wurde zwar gedankt, es wurde aber auch gebeten auf mehr Struktur zu achten und regelmässige Lessons Learned-Sessions abzuhalten um die eigenen Prozesse so zu verbessern, dass nicht erst gegen Ende alles fertig wurde. Zudem erhielt es eher unkritische, dafür aber auch weniger spannende Aufgaben, bei denen es nicht auf die Fertigstellung zu bestimmten Zeitpunkten ankam.

Die Folgen dieses geänderten Vorgehens waren deutliche Verbesserungen in verschiedenen Bereichen: die Moral in den Teams (mit der einen Ausnahme) ging hoch, die Lieferung neuer Features erfolgte gleichmässiger und weniger schubweise, der für Bugfixing und Refactoring notwendige Zeitaufwand ging zurück. Und nicht zuletzt entstand im Management eine klare Vorstellung davon welches Verhalten man besser fördern sollte und welches besser nicht.

Konstellationen wie diese finden sich in vielen großen Organisationen, und es lohnt sich sie anzusprechen sobald sie entdeckt werden. Die richtigen Helden zu finden, zu loben und zu belohnen kann eines der wirkungsvollsten Management-Werkzeuge sein um positive Veränderungen herbeizuführen. Man sollte es nutzen.

Montag, 5. März 2018

Ein Bild sagt mehr als 1000 Worte (XXI)