Schneller fertig werden, nicht schneller arbeiten

Bild: Pexels / Burst - CC0 1.0

Es gibt einen Satz, der ist gleichzeitig eine der grössten Verheissungen, einer der bekanntesten Werbeslogans und eines der am weitesten verbreiteten Missverständnisse im Bereich der Agilität. Um ihn zu finden muss man nicht lange suchen, er steht gross auf dem Titel eines Buches, das von Scrum-Begründer Jeff Sutherland verfasst wurde. Er lautet Doing Twice the Work in Half the Time. Wenn er im Rahmen einer agilen Transition fällt sollte man dringend über ihn reden.

Wenn klassische Manager hören, dass man in der Hälfte der Zeit die doppelte Arbeit erledigen könne kommt bei vielen sofort der Fehlschluss zu Stande, dass das durch schnellere Arbeit passieren würde. Aus ihrer Sicht nachvollziehbar: in vielen Unternehmen herrscht noch immer die Ansicht vor, dass sich Arbeit an komplexen Aufgaben detailliert bis weit in die Zukunft planen liesse. Der Umkehrschluss - wenn das so ist, dann lässt sich mehr Geschwindigkeit nur durch schnellere Arbeit erreichen.

Dass das ein gefährlicher Trugschluss ist habe ich bereits beschrieben. Im besten Fall gelingt es und man gerät in die Build Trap, baut also in hoher Frequenz an den sich ändernden Marktbedürfnissen vorbei, in den schlechteren Konstellationen entsteht die (scheinbare) Geschwindigkeitssteigerung dadurch, dass dort Arbeit eingespart wird wo das Management es nicht sehen und nicht überprüfen kann, bei Organisation, Tests, Architektur, etc. In beiden Fällen treten die Auswirkungen verspätet aber unvermeidbar ein und aus der anfänglichen Beschleunigung wird ihr Gegenteil.

Unabhängig davon ist es aber tatsächlich so, dass agile Vorgehensweisen die Produktion erstaunlich schneller machen können. Die Ursachen dafür sind bekannt und lassen sich benennen.

Ein Grund ist, dass durch das ständige Inspect & Adapt und das permanente Kundenfeedback verhindert (oder zumindest eingedämmt) werden kann, dass am Markt vorbei entwickelt wird. Da in kleinen Arbeitspaketen sofort benutzbare Funktionen geliefert werden kann die Entwicklung jederzeit beendet und an einer anderen Stelle fortgesetzt werden. Anders als in Ansätzen mit langen Planungszyklen lässt sich dadurch Arbeit in grossem Ausmass vermeiden, und das nicht nur dadurch, dass man sie unterlässt - auch Folgearbeiten wie z.B. Ausbau oder Wartung der unnötig erstellten Features entfallen.

Ein weiterer Aspekt ist die Verkürzung von Wartezeiten. In den meisten nicht agilen Teams die ich kenne besteht die Fertigstellungszeit eines Produkts zu mehr als der Hälfte daraus, dass auf die Zulieferung eines anderen Teams gewartet wird. In einer agilen Umgebung ist das anders: Scrum Teams sind per Definition crossfunktional und haben wenige Abhängigkeiten, Kanban Teams arbeiten permanent an der Beseitigung von Flaschenhälsen und der Verbesserung von Übergabeprozessen. In beiden Fällen ist eine deutliche Verkürzung der Wartezeiten die Folge, und damit eine beschleunigte Fertigstellung.¹

Zuletzt tritt noch ein Effekt auf, der gewissermassen die Umkehrung des weiter oben genannten "Sparen wo es das Management nicht sieht" ist. Wenn Teams nach dem Pull-Prinzip arbeiten (einem der zentralen Bausteine aller agilen Vorgehen), dann nehmen sie neue Arbeit erst an wenn sie mit der alten wirklich fertig sind. Und zu diesem "wirklich fertig" gehört, dass getestet wurde, dass kein toter oder unverständlicher Code zurückgelassen wurde, dass alle durch Seitenauswirkungen erzeugten Bugs gefixt wurden, etc. Das macht die Arbeit zwar im Einzelfall etwas langsamer, langfristig sorgt es aber für deutlich mehr Geschwindigkeit.

Zusammengefasst: eine deutliche Geschwindigkeitssteigerung der Produktion ist durch Agilität möglich. Das bedeutet aber nicht schnelleres Arbeiten sondern intelligenteres Arbeiten. Diesen Unterschied sollten alle Beteiligten verstanden haben.


¹Ein häufiger Einwand an dieser Stelle ist, dass "in unserem Fall" Crossfunktionalität und Arbeit am Prozess nicht möglich sind. Das ist in den meisten Fällen eine Ausrede, aber selbst dort wo es stimmt ist es kein Argument. Solche Teams können strukturell kaum agil arbeiten, also sollte man sie nicht agil nennen und dort auch nicht die Vorteile von Agilität erwarten.

Kanarienvögel

Bild: Pixabay / jrperes - CC0 1.0

In der englischen Sprache gibt es die Redewendung des "Canary in a coal mine", also des Kanarienvogels im Kohlebergwerk. Hintergrund ist das bis in das 20. Jahrhundert übliche Vorgehen, solche Vögel mit unter Tage zu nehmen. Wenn in den Stollen Gase austraten oder die Luft zu kohlensäurehaltig wurde, starb zuerst der auf viel Sauerstoff angewiesene Vogel, den Menschen blieb meistens noch genug Zeit um zu flüchten. Abgeleitet davon wird der Begriff des Canary in a coal mine auf alle Regeln und Praktiken angewandt, deren Verschwinden ein starker Indikator dafür ist, dass deutliche Verschlechterungen unmittelbar bevorstehen.

Auch im Kontext agiler Transitionen gibt es Kanarienvögel, deren Verschwinden ein deutliches Signal eines kommenden oder bereits stattfindenden Rollbacks sein kann. Wenn festzustellen ist, dass sie schwächer werden oder sogar ihr Leben aushauchen ist es Zeit das Weite zu suchen oder (um die Analogie weiterzutreiben) für einen neuen Zufluss frischer Luft zu sorgen, mit dem die Transition wiederbelebt wird. Zu den agilen Kanarienvögeln gehören:

Die Ausgestaltung des Scrum Masters als Vollzeitstelle

Jedem der diesen Job (oder den eines Kanban-Delivery Managers) einmal ausgeübt hat ist es klar, dass er anders als in Vollzeit gar nicht auszuüben ist. Eher noch ist es so, dass die zahlreichen Tätigkeiten im Dienst des Teams, des Product Owners und der Organisation in Überstunden ausarten oder in das Privatleben hineinwuchern können. Das zu beschneiden kann nur Dysfunktionen zur Folge haben, mit dem häufigen ersten Ergebnis, dass der ständige Anpassungs- und Verbesserungsprozess zum Erliegen kommt, da seine Stimulierung im engen Zeitplan wegpriorisiert wird. Und oft beginnen die Probleme damit erst, zum Beispiel dann wenn ein Teilzeit-Scrum Master mit einem Teilzeit-Product Owner kombiniert wird.

Das Recht der Teams, Akzeptanzkriterien und Definition of Done frei zu definieren

Ein massiver Eingriff in die Selbstorganisation der Teams liegt vor wenn versucht wird, übergreifende "Qualitätsstandards" einzuführen. Zum einen weil diese, "um auf Nummer sicher zu gehen", die Tendenz haben unnötig detailliert-bevormundend zu sein und damit fast zwangsläufig zur Entstehung einer übergreifenden, regulierenden und kontrollierenden Bürokratieschicht führen, zum anderen weil sie aufgrund der Vielzahl der Betroffenen und Verantwortlichen nur noch sehr langsam zu ändern sind, selbst wenn die Rahmenbedingungen sich schon längst geändert haben.

Die von Team zu Team unterschiedliche Bedeutung von Story Points

Einer der großen Klassiker fehlgeleiteter Management-Bemühungen. So nachvollziehbar es ist, teamübergreifende Planzahlen haben zu wollen, so schädlich ist es auf der anderen Seite sie zu erzwingen. Das führt nämlich nicht nur zu einer festen Umrechnung in Stunden oder Personentage (alleine das wäre bereits schlimm genug), es erzeugt für viele Manager auch die große Versuchung, diesen Wert "optimieren" zu wollen, mit all dem unrealistischen Erwartungs-, Kontroll- und Erzwingungs-Overhead der damit verbunden ist.

Die direkten Feedbacks von Benutzern und Stakeholdern an das Entwicklungsteam

Ohne direkte Rückmeldung von den Anwendern und Auftraggebern wird jedes Team permanent mit dem erheblichen Risiko leben müssen, am Markt vorbei zu produzieren. Wird dieses Feedback in Management-Runden, Kommittees oder vorgelagerte Fachabteilungen verlagert, sind "Stille Post-Effekte" die Folge, durch die die Rückmeldungen nur noch verzerrt, verfälscht oder reduziert bei dem Entwicklungsteam ankommen. Auch Rückfragen und Austausch sind dann nur noch verlangsamt möglich, wodurch neben der Bedarfsgerechtheit auch die Reaktionsgeschwindigkeit abnimmt.

Der Framework-Charakter von Scrum, Kanban & Co.

Dass Scrum viele Bereiche der Umsetzung wenig bis gar nicht reguliert ist volle Absicht und soll verhindern, dass zu detaillierte Vorgaben im Einzelfall nicht mehr anwendbar sind. Auch auf XP und Lean Startup trifft das zu, und Kanban hat als "open Source Methode" überhaupt kein offizielles Regelwerk. Wird um diese Ansätze herum eines der üblichen, verpflichtend zu befolgenden Prozesshandbücher verfasst, treten verschiedene Folgen auf: zum einen kann eine zu umfangreiche Stoffmenge nicht mehr in das kollektive Gedächtnis der Organisation übergehen und gerät dadurch schnell in Vergessenheit, zum anderen regt das Vorhandensein optionaler Regeln zu permanenten Sinnfragen an und damit auch Anpassungsfähigkeit und -bereitschaft. Umgekehrt geht diese zurück wenn Regeln zu einengend und detailliert sind.

---

Was allen diesen Punkten (und einigen weiteren) gemeinsam ist: sie wirken auf den ersten Blick wie nachrangige Faktoren, an denen man relativ risikolos herumhantieren kann. Wie gesagt, auf den ersten Blick. Auf den zweiten zeigt sich, dass sie alle mit der Fähigkeit eines Teams und einer Organisation in Verbindung stehen flexibel und reaktionsschnell (also agil) zu sein. Werden an ihnen trotzdem Verschlimmbesserungen durchgeführt zeigt das, dass einige für die agile Transition bedeutsame Zusammenhänge nicht erkannt (oder bewusst ignoriert) werden. Vor diesem Hintergrund sind sie als Canary in a coal mine besonders geeignet.

Lokale Optimierung

Bild: Miso Robotics

 Zuerst klingt die Geschichte aus der USA Today reichlich skurril: Cali Burger (eine amerikanische Fast Food-Kette) hatte in einer Filiale einen Roboter namens "Flippy" installiert, der in der Lage sein sollte die unglaubliche Menge von 2000 Stück Burgerfleisch pro Tag zu grillen. Nach gerade zwei Tagen war das Experiment aber bereits vorbei und Flippy wurde wieder durch Menschen ersetzt. Was war passiert?

Anders als man denken könnte war nicht der Roboter selbst das Problem, zumindest nicht direkt. Er tat genau das was er sollte, nämlich im Akkord Fleisch grillen. Das Problem war seine Zusammenarbeit mit den menschlichen Kollegen: zum einen konnten die mit der Arbeitsgeschwindigkeit nicht mithalten, zum anderen funktionierten die Übergaben nicht richtig - es gelang häufig nicht, das Fleisch dort bereitzuhalten oder abzuholen wo Flippy es benötigt hätte. Um wieder funktionierende Abläufe zu haben mussten erneut Menschen an die Bratfläche.

Was hier geschehen ist, ist das perfekte Beispiel für die Probleme lokaler Optimierungen. In dem kleinen Abschnitt des Bratens und Wendens war die Automatisierung eine klare Verbesserung von Geschwindigkeit und Qualität, ausserdem waren anstrengende und stressige Jobs betroffen, die nur wenige Mitarbeiter machen wollten. Aus dieser Perspektive war die Umstellung ein voller Erfolg. Dass ein Fehlschlag daraus wurde lag an der fehlenden Gesamtsicht, durch die zwei Risikofaktoren nicht auffiehlen.

Zum einen sorgte die sprunghafte Erhöhung der Arbeitsleistung dafür, dass die vor- und nachgelagerten Arbeitsstationen zu Flaschenhälsen wurden: im Bereich vor dem Roboter sorgte die langsamere Geschwindigkeit dafür, dass er Leerlauf hatte, im Bereich nach ihm staute sich die Arbeit. Zum anderen sorgten die schlecht orchestrierten Übergaben für Effizienz- und Effektivitätsverluste - da die Schnittstellen zwischen Mensch und Roboter nicht abgestimmt und standardisiert wurden, arbeiteten sie aneinander vorbei.

Diese Faktoren (unterschiedliche Verarbeitungskapazitäten und ineffektive Übergaben) treten sehr häufig auf wenn in längeren Prozessketten nur lokale Optimierungen umgesetzt werden. Manchmal, wie im Fall von Flippy, führt das dazu, dass diese Veränderungen zurückgenommen werden müssen, manchmal sind sogar dauerhafte Verschlechterungen die Folge.

Um das zu vermeiden sollten in Digitalisierungs- und Automatisierungsprojekten Systeme immer ganzheitlich betrachtet werden, denn sonst kommt es so wie bei jetzt bei Cali-Burger: dort steht ein teurer Roboter in der Ecke, kostet Geld und erbringt keinen Mehrwert. Ein Denkmal einer fehlgeschlagenen lokalen Optimierung.

Stop where you are

Bild: Pxhere - CC0 1.0

Fortschritt ist wichtig und Stillstand ist Rückschritt, so weit, so gut. Klar ist aber auch, dass Veränderung kein Selbstzweck ist, schon gar nicht dann wenn es darum geht bestimmte Methoden und Frameworks einzuführen. Wenn hinterfragt wird. welchen Mehrwert eine Veränderung bringen soll, kann es vorkommen, dass sich der aktuelle Zustand als völlig ausreichend herausstellt. Wie im folgenden Beispiel.

Ein Team bei einem Kunden hatte die Aufgabe bestimmte Services für die internen Benutzer einer Software zu erbringen - Accounts anlegen, Berechtigungen vergeben, Passwörter zurücksetzen, etc. Um das effizienter zu gestalten war versucht worden Lean Six Sigma einzuführen, was am aktiven und passiven Widerstand der Teammitglieder gescheitert war, die in der Methode einen bürokratischen Prozess-Overhead gesehen hatten¹. Um das Team nicht "unmethodisch" vor sich hin arbeiten zu lassen sollte als nächstes eine Umstellung auf Kanban stattfinden. Ganz im Sinn von Start where you are stand dabei am Beginn eine Bestandsaufnahme des Ist-Standes, die das folgende Ergebnis hatte:

Die Organisation des Teams erfolgte durch eine Mischung aus Lean Six Sigma-Versatzstücken, Improvisation und "war schon immer so"-Elementen und war um eine jeden Morgen stattfindende Statusrunde organisiert. Vor dieser stellte jedes Teammitglied seine persönliche Belastungs-Ampel auf einem gemeinsamen Board auf Grün, Gelb oder Rot, je nach Arbeitslast. Ein wechselnder Moderator fragte alle deren Ampel auf Rot stand nach den Gründen und vermittelte Hilfe von weniger überlasteten Teammitgliedern. Strukturelle Probleme wurden dem Teamleiter übergeben, der dann in den nächsten Meetings berichtete wie er mit der Behebung vorankam.

Bei den Befragungen waren alle Beteiligten der Meinung, der aktuelle Prozess wäre der beste seit langem. Die Arbeit würde gerecht verteilt und schnell erledigt, Leerlauf und Überlastung kämen kaum vor, Schieflagen würden innerhalb eines Tages erkannt und behoben, die Problemlösung wäre unkompliziert und transparent. Es war zwar allen bewusst, dass die offiziellen Arbeitsanweisungen nicht eingehalten würden, aber es würde doch alles gut funktionieren. Wäre das nicht völlig ausreichend?

Das Ergebnis war dann tatsächlich ein Ratschlag an das Management, auf neue Methoden-Einführungen zu verzichten und alles so zu lassen wie es in diesem Moment war. Auf seine eigene Art hatte das Team bereits das Ziel der Firma erreicht: effektives Arbeiten mit schlanken Prozessen und schneller Reaktionsfähigkeit bei unerwarteten Entwicklungen. Jetzt noch Kanban oder irgendeinen anderen Ansatz einzuführen wäre nichts anderes gewesen als Methodismus. Viel besser war es, die Leute einfach in Ruhe arbeiten zu lassen.


¹Eine feine Ironie der Geschichte.

Start where you are

Bild: Flickr / Chris Hunkeler - CC BY-SA 2.0

Es ist eine der Grundregeln von Kanban: anders als bei Scrum werden zu Beginn keine neuen Rollen und Regeln eingeführt (zumindest meistens nicht), stattdessen wird lediglich der bisherige Arbeitsablauf visualisiert. Sobald das passiert ist wird er auf Engstellen, Überkapazitäten und Probleme untersucht und dann erst nach und nach angepasst. Das scheint ein einfacher Einstieg zu sein, in Wahrheit ist er es oft aber nicht. Viele Organisationen haben grösste Probleme damit, ihren Ist-Zustand festzuhalten.

Ein Grund dafür ist, dass an vielen Stellen der offizielle Arbeitsprozess und der tatsächliche Arbeitsprozess voneinander abweichen. Im Fall eines Managers den ich vor kurzem kennenlernen durfte war der offizielle Prozess To Do 🡒 Analysis 🡒 In Progress 🡒 Done, in der Realität fand aber To Do 🡒 Analysis 🡒 In Progress 🡒 Nachträgliche Änderung der Anforderungen 🡒 Überarbeitung 🡒 Done statt. In dem Ministerium in dem ich vor langer Zeit gearbeitet habe war der offizielle Weg Entscheidungsbedarf 🡒 Entscheidungsvorlage 🡒 Entscheidung, was tatsächlich immer wieder stattfand war allerdings Entscheidungsbedarf 🡒 Entscheidungsvorlage 🡒 Verschleppen der Entscheidung 🡒 Veraltung der Vorlage 🡒 Überarbeitung der Vorlage 🡒 Entscheidung. Das Abbilden des tatsächlichen Prozesses deckt in solchen Fällen Ineffizienz und Dysfunktionalität auf und wird daher häufig aus politischen oder persönlichen Gründen bekämpft.

Was immerhin noch der Vorteil in solchen Konstellationen ist, ist die Tatsache, dass der tatsächliche Prozess zwar nicht angesprochen wird, aber jedem bekannt ist. Noch schwieriger wird es wenn Teile der Organisation glauben, dass der offizielle Prozess funktionieren würde und der tatsächliche Prozess weitgehend unbekannt ist. Ein regelmässig in diesem Zusammenhang anzutreffendes Phänomen ist die brauchbare Illegalität: Der vorgegebene Ablauf ist in sich widerspüchlich oder unrealistisch, was die Mitarbeiter dem Management aber (aus welchem Grund auch immer) nicht sagen, bzw. sagen dürfen. Um trotzdem arbeitsfähig zu sein werden unter der Hand informelle Prozesse angelegt, während die offiziellen nur noch als "Theaterstück" aufgeführt werden um gegenüber den oberen Ebenen den Schein zu wahren. Auch das ist natürlich bei einer Offenlegung hochproblematisch.

Warum auch immer sich Anspruch und Realität auseinanderentwickelt haben - das Aufdecken dieser Parallelität ist für die Beteiligten ernüchternd und schmerzvoll. Zu Beginn einer Kanban-Einführung besteht daher die Gefahr, dass es in solchen Fällen zu Auseinandersetzungen oder Verdrängungen kommt. Das zu verhindern und in konstruktive Bahnen zu lenken ist die eigentliche Herausforderung dieser Phase, die auf den ersten Blick so unproblematisch wirkt.

"Was wollen wir schlecht machen?" als Thema für Retrospektiven

Bild: Wikimedia Commons / Lewis Clarke - CC BY-SA 2.0

Vor kurzem war ich wieder bei einem der Teams zu Gast die ich von Zeit zu Zeit coachen darf und habe voller Freude festgestellt, dass es seit meinem letzten Besuch angefangen hat seine Retrospektiven zu modifizieren um sie abwechselungsreicher zu gestalten. Als letztes hatte es sich eine angepasste Version der Timeline-Retro ausgedacht: statt nur die Ereignisse des letzten Sprints rückblickend auf einer Zeitleiste anzuordnen hatte es diese auch in die Zukunft führend abgebildet. Und da es ausserdem die klassischen Dimensionen gut und verbesserungswürdig gab entstanden die folgenden vier Quadranten:

Die erste Überlegung angesichts dieser Felder war, dass in der Retrospektive nur die Themenfelder links oben, links unten und rechts oben besprochen werden sollten. Das Feld rechts unten (Was wollen wir schlechter machen?) wäre widersinnig und müsste leer bleiben, schließlich würde ja niemand bewusst etwas schlechter machen wollen als in der Vergangenheit. Bei näherer Betrachtung schien das allerdings doch nicht ganz so abwegig wie zu Beginn.

Auch die besten Teams können in Situationen geraten in denen Antipattern praktisch unvermeidbar sind. In seltenen Fällen gibt es zum Beispiel eben doch Anforderungen die sich beim besten Willen nicht so klein schneiden lassen, dass sie in einem Sprint fertig werden können. Ganz bewusst wird dann in Kauf genommen, dass von Beginn an kein erreichbares Sprintziel formuliert werden kann. In anderen Konstellationen kann es sein, dass die Teammitglieder zeitweise nicht alle nötigen Skills haben die sie eigentlich bräuchten, etwa weil der Experte für das Thema Penetrationstests oder Verbraucherschutz in Elternzeit geht. In solchen Fällen die Produktion anzuhalten wäre keine realistische Option, der einzige Weg besteht dann mitunter darin, dass bestimmte Antipattern nicht nur toleriert sondern mangels Alternativen sogar eingeplant werden. Das eigentlich Widersinnige tritt ein: bewusst wird etwas schlechter gemacht als in der Vergangenheit.

Im Fall der oben erwähnten Retrospektiven-Variante sind genau das die Themen die in das Feld rechts unten eingetragen werden würden. Und sobald sie dort stehen kann man sich proaktiv Gedanken machen wie man die unausweichlichen negativen Folgen und Begleiterscheinungen frühzeitig entdecken und in Grenzen halten kann. Letztendlich ist das auch eine Möglichkeit wieder mehr Kontrolle über die Situation zu erhalten - man kann Verschlechterungen nicht verhindern, man kann sie aber dafür sorgen, dass sie sich nicht dorthin ausdehnen wo das vermeidbar ist. So gesehen ist es also sehr anzuraten, im Werkzeugkasten ein Retro-Format zu haben das explizit die Frage stellt was man zukünftig schlechter machen will.

Das agile Altersheim

Ich bin nicht sicher ob dieses Video hier ein Aprilscherz oder ein Rant ist. Vermutlich beides. Aber es ist sehr witzig. Und sehr wahr.

Kommentierte Links (XXXV)

• 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.

• Jordan Job: One Shocking Thing Many Agile Coaches Are Getting Wrong

Okay, die Überschrift ist Clickbait. Dahinter verbergen sich aber einige durchaus lesenswerte Überlegungen zum Taylorismus und zu Scientific Management, sowie dazu wie deren (unbewusst angewandte) Prinzipien dazu führen können, dass agile Implementierungen falsch und dysfunktional umgesetzt werden. Ich bin nicht sicher ob ich alles aus diesem zweiten Teil genau so formulieren würde, es sind aber auf jeden Fall interessante Gedankengänge.
Siehe auch: Marcus Blankenship: How Henry Ford is Destroying Software.

• Harvard Business Review: 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.
  

• Agile Verwaltung: 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.

• FAZ: 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.