Freitag, 31. Juli 2020

Kommentierte Links (LXIV)

FS
  • Jeff Gothelf: Working Backwards - A New Version Of Amazon’s “Press Release” Approach To Plan Customer-Centric Projects

  • Über den bei Amazon üblichen Ansatz Produkte und Anforderungen Form von Pressemitteilungen zu verfassen hatte ich letztes Jahr schon etwas geschrieben. Auch Jeff Gothelf sieht darin ein wichtiges Werkzeug, an dem er aber zwei Kritikpunkte sieht - eine zu starke Focussierung auf Output statt auf Outcomes und eine Vernachlässigung der Herausforderungen in der teamübergreifenden Zusammenarbeit. Er schlägt daher das folgende, veränderte, "Pressemitteilungs-Format" vor:
    1. What did you ship?
    2. What customer problems does it solve?
    3. How do you know the problem solved those problems?
    4. What business benefit has been achieved?
    5. Internal quote from someone involved or invested in this project and its success.
    6. Provide a customer quote sharing how this new product made them more successful or helped them achieve something.
    7. How did the team works together to achieve these results? What challenges did the team overcome to make the product successful?
    8. Provide a call to action.
    In dieser Form auf jeden Fall ein interessanter und vielversprechender Ansatz. Ob er ausserhalb von Amazon als Anforderungsbeschreibung ausreichend ist ist zwar diskutabel, aber ein Einsatz in Produktfindungs-Workshops dürfte definitiv eine Option sein.

  • Bob Emiliani: What Comes After Lean?

    Lean Management und Agile sind sich in vielem ähnlich, unter anderem auch in der häufigen Aussenwahrnehmung als vorübergehende Management-Trends (angesichts einer 70-jährigen, bzw. 30-jährigen Geschichte eine gewagte Annahme, aber das wäre ein anderes Thema). Bob Emiliani nimmt das zum Anlass für ein Gedankenspiel - was könnte wohl danach kommen (in seinem Fall nach Lean)? Vier Optionen fallen ihm ein:
    1. Es findet eine Ablösung statt durch einen neuen Ansatz, der die bisherigen Herausforderungen besser lösen kann
    2. Es werden so lange neue Ideen und Prinzipien integriert bis der aktuelle Stand nur noch eine kleine Teilmenge des grossen Ganzen bildet
    3. Die Herausforderungen ändern sich und getrieben dadurch entstehen neue Lösungsansätze (man beachte den Unterschied zu Option 1)
    4. Es folgt einfach nichts. Die ganze Idee methodischer Ansätze verschwindet
    Die spannende Frage aus "agiler Sicht": lässt sich dieses Gedankenspiel von Lean auf Agile übertragen? Ein gutes Thema für die nächste Grundsatz-Diskussion zwischen Agile Coaches (oder sogar für ein ganzes Barcamp).

  • Jason Little: Balancing the Push and Pull of Change

    Der Lean Change-Ansatz von Jason Little hat sich (zumindest im deutschsprachigen Raum) nie so ganz durchsetzen können, weshalb er trotz seiner mittlerweile mehr als zehnjährigen Geschichte noch immer das Potential hat neue Impulse zu liefern. Ganz im Sinn des Agilen Manifests sind auch hier mehrere Gegensatzpaare entwickelt worden an denen man sein Handeln ausrichten kann:
    1. Co-creation over getting buy-in
    2. Meaningful dialogue over broadcasting
    3. Cause & purpose over creating urgency
    4. Experimentation over executing tasks
    5. Response to change over resistance to change
    Genau wie im Fall des Agilen Manifests ist auch hier wichtig, dass sich nicht jeweils eine richtige und eine falsche Option gegenüberstehen, sondern dass beide ihre Berechtigung haben. Die Bevorzugung der linken Seite ist also eher als Richtlinie zu sehen und nicht als Dogma.

  • David Robson: Can you learn to navigate uncertainty?

    Zur Abwechselung mal ein Absatz ohne Aufzählungen. Was die BBC hier gemacht hat ist ein hochinteressantes Experiment. In einer gross angelegten Studie sollten über 7000 Teilnehmer versuchen mehrere Monate im voraus Voraussagen zu Ereignissen in unberechenbaren Umfeldern zu machen - zu Wahlergebnissen, Währungsschwankungen, Pandemie-Verläufen, aber auch zu Produkt-Neuheiten grosser Unternehmen. Das unerwartete Ergebnis: Laien machten bessere Voraussagen als Experten und jüngere Menschen machten bessere Voraussagen als ältere. Dem Anschein nach können Erfahrung und Expertise also schädlich sein wenn man versucht sich in einem volatil oder chaotisch verhaltenden Umfeld zurechtzufinden. Die Erklärungsansätze die sich aus der Studie ergeben sollten nachdenklich machen - Experten und Menschen mit grösserer Lebenserfahrung tendieren demnach dazu die eigene Kompetenz zu überschätzen und neigen dazu die Lösungen vergangener Probleme undifferenziert auf zukünftige zu übertragen. Im Selbstbild vieler Menschen dürfte das spürbare Kratzer hinterlassen.

  • John Cutler: Developer & Designer Collaboration (in the Real World)

    Grau ist alle Theorie, die Praxis ist bunt. Was John Cutler hier teilt ist eine der vielen Arbeitsablauf-Varianten die sich in der Realität nach und nach entwickeln, wenn Teams ihre Prozesse kontinuierlich optimieren. Scheinbar Wasserfall-artige Phasen lösen sich ab mit iterativem Arbeiten, zeitweise wird Arbeit parallelisiert, dann kommt es wieder zu teamübergreifendem Pairing. Die Moral aus dieser Geschichte: diese Abläufe sind in diesem (und nur in diesem) Kontext optimal - und ein erzwungener Einheitsprozess hätte zu suboptimalen Ergebnissen geführt.

Montag, 27. Juli 2020

Die drei Bedeutungen von (agiler) Skalierung

FS

Bild: Pikrepo - CC0 1.0

Die agile Skalierung gilt als eine der Königsdisziplinen der Agilität. Scrum oder XP mit einem Team zu machen ist heute nichts Ungewöhnliches mehr, auch zwei oder drei gehen noch - aber mit zehn Teams? oder zwanzig? Oder noch mehr? Das wird hart. Erklärungen für diese Wahrnehmung gibt es viele: steigende Komplexität, Parallelität der Ereignisse und Einbeziehung nicht-agiler Einheiten sind unter den häufigsten, hier soll es aber um einen anderen Erklärungsansatz gehen. In ihm scheitert alles bereits an der Kommunikation.

Die These - wenn verschiedene Menschen miteinander über agile Skalierung reden meinen sie damit oft völlig unterschiedliche Dinge und reden aneinander vorbei. Durch diese fehlschlagende Kommunikation entstehen Frustration, falsche Erwartungshaltungen und später dann Enttäuschungen durch die so nicht erwarteten oder anerkannten Ergebnisse. Was von aussen wie ein Organisationsproblem aussiert ist also in Wirklichkeit ein Verständnisproblem. Um dem auf den Grund zu gehen - welche Verständnisse sind das?

Verständnis Nr. I: agile Skalierung ist das Wachstum einer agil organisierten Einheit

Skalierung bedeutet in diesem Fall, dass eine agil operierende Einheit grösser wird - und dabei weiterhin agil bleiben soll. Die steigende Zahl der beteiligten Teams führt hier zu einem steigenden Koordinationsbedarf, der durch die sukzessive Einführung teamübergreifender Zusammenarbeitsformen bedient wird. Am Anfang z.B. mit einem Scrum of Scrums, später mit Release Trains, noch später mit Gilden, etc. Zum Verständnistyp I ist wichtig: solange das Wachstum anhält ändern sich auch die Zusammenarbeitsformen.

Verständnis Nr. II: agile Skalierung ist ein definiertes Zusammenarbeitsmodell

Wenn Manager zum ersten mal über agile Skalierung reden meinen sie meistens das: ein Regelwerk, das die einzelnen agil arbeitenden Teams umgibt und verbindet und in dem es wenn möglich für alles eine Rolle, ein Meeting, ein Quality Gate oder einen Prozess gibt. Häufig stecken dahinter SAFe oder ein "hauseigenes Hybrid-Modell", seltener LeSS, Nexus oder (Pseudo-)Spotify. Zum Verständnistyp II ist wichtig, dass meistens erwartet wird, dass er nach der Einführung "stabil läuft" und nicht mehr angepasst werden muss.

Verständnis Nr. III: agile Skalierung ist die ständige Anpassung eines Zusammenarbeitsmodells

Das was sich Agile Coaches unter agiler Skalierung vorstellen ist genau gegenläufig zum zuletzt genannten Typ: der Skalierungsansatz selbst soll Gegenstand agiler Vorgehensmuster sein, sich also permanent durch inspect & adapt an ändernde Rahmenbedingungen anpassen. Die Entwicklung neuer Zusammenarbeitsformen erfolgt damit explizit ergebnisoffen, einschliesslich der Möglichkeit Veränderungen wieder rückgängig zu machen. Zum Verständnistyp III ist wichtig: in ihm gilt es als Risiko wenn sich das Skalierungsmodell nicht ständig ändert.

Dass diese verschiedenen Verständnistypen zu Problemen führen können wenn sie nebeneinander existieren ist offensichtlich. Nur Typ I und Typ III sind kompatibel miteinander, Typ I und Typ III werden früher oder später in Konflikte laufen, Typ II und Typ III sind völlig inkompatibel. Selbst wenn diese unterschiedlichen Sichtweisen sich gegenseitig bekannt sind ist eine Vermittlung schwierig, wenn das nicht der Fall ist und jeder annimmt, dass sein Verständnis von den anderen geteilt wird, sind Konflikte unausweichlich.

Vor Beginn eines agilen Skalierungsvorhabens macht es also hochgradig Sinn, dass alle Beteiligten sich darüber unterhalten, was sie denn unter agiler Skalierung verstehen. Das erscheint naheliegend, findet aber leider nur selten statt.

Donnerstag, 23. Juli 2020

Value, Flow & Bottlenecks (& Visualization)

FS
Heute gibt es zwei kleine Videos (jeweils weniger als 10 Minuten) zu den Themen Value, Flow und Bottlenecks. Zum einen weil der Verfasser John Cutler darin viele sinnvolle Sachen sagt, zum anderen aber auch wegen der Visualisierungen, die in ihrem Minimalismus sicher irgendwie auf Flipcharts übertragbar sind. Ein Projekt für einen der nächsten Freitagnachmittage.



Montag, 20. Juli 2020

Stabile Teams

FS

Bild: Wikimedia Commons / Zossolino - CC BY-SA 4.0

"Ok, für das neue Projekt braucht es also ein Entwicklungsteam von fünf Personen, mal sehen. Einen könnten wir sofort zur Verfügung stellen, nur in einem Monat müssten wir ihn für einen Release drei Wochen rausziehen, in der Zeit kommt aber jemand als Vertretung. Zwei weitere könnten wir in zwei Wochen zur Verfügung stellen, aber nur bis zum Beginn des Weihnachtsgeschäfts. Dann stellen wir aber auch zwei Neue ein die sie ersetzen können. Die beiden letzten Stellen würden wir wechselnd besetzen, je nachdem welches andere Projekt gerade Leute entbehren kann."

Überlegungen wie diese kann man in vielen grossen Organisationen hören wenn neue Vorhaben geplant werden, und dass sie häufig vorkommen ist auch kein Zufall. Es sind zwei tayloristische Grundprinzipien deren Anwendung zu derartigem Ressourcen-Tetris führt: zum einen, dass eine möglichst hundertprozentige Auslastung aller Angestellten anzustreben ist und zum anderen, dass die Menschen auf der untersten Ausführungsebene ohne grosse Probleme austauschbar sind. In Frederick Taylors Stahlwerk mag das auch funktioniert haben, in der Wissensarbeit führt es aber zu Problemen.

Selbst wenn man ausser Acht lässt, dass alleine die Idee einer Vollauslastung hochproblematisch ist (mehr dazu hier) wird der Versuch der Ressourcenoptimierung in einem Wissensberuf wie IT, Marketing, etc. zu permanenten Effektivitätsverlusten führen. Der Grund: er lässt sich nur mit ständigem Neu-Zuordnen momentan untätiger Mitarbeiter zu den aktuell arbeitsintensivsten Vorhaben durchführen. Das erscheint zwar auf den ersten Blick sinnvoll, da so Untätigkeit vermieden werden soll. Auf den zweiten Blick fallen aber Probleme auf.

Am offensichtlichsten ist der Wegfall von Routinen und Erfahrungswerten. Wer sich ständig in neue Aufgabengebiete und Anwendungen hineindenken muss, die bisher von anderen bearbeitet worden sind, wird sich häufiger einlesen müssen, Fehler machen und diese korrigieren müssen. Falls die Folgen bereits gemachter Fehler mit zeitlichem Versatz auftreten kann es sogar nötig sein Reparaturen vorzunehmen ohne bei den ursächlichen Handlungen dabeigewesen zu sein, was das Ganze nochmal erschwert.

Ebenfalls naheliegend ist, dass häufige personelle Wechsel das Teambuilding deutlich erschweren. Dort wo ständig neue oder nur vorübergehend anwesende Kollegen in den gemeinsamen Runden sitzen wird sich nur schwer ein Gefühl der psychologischen Sicherheit einstellen. Und selbst wenn man diesen weichen Aspekt beiseite lässt bleibt noch das Problem, dass im Team getroffene gemeinsame Entscheidungen immer wieder verhandelt werden müssen wenn sich jeder daran gebunden fühlen soll.

Weniger offensichtlich aber in den Auswirkungen extrem weitreichend ist ein anderer Effekt: wenn sich das bedarfsgetriebene Hin- und Herschieben von Personal einmal etabliert hat wird es nicht nur dann stattfinden wenn jemand gerade nichts zu tun hat sondern auch dann wenn an einer anderen Stelle etwas zu tun ist das wichtiger ist als die aktuelle Tätigkeit. Die Folge ist ein Liegenbleiben und Aufstauen unerledigter Arbeit, mit der häufigen Folge dass nichts mehr richtig fertig wird und überall Behelfslösungen im Einsatz sind.

Um diese negativen Effekte zu vermeiden ist es sinnvoll stabile Teams einzurichten. Damit ist nicht gemeint, dass sich deren Zusammensetzung nie ändern darf, es bedeutet aber, dass nicht jede Unter- oder Überlastung sofort ein Grund für eine organisatorische Veränderung sein sollte. Dass dadurch keine hundertprozentige Optimierung der jeweiligen Arbeitszeiten mehr möglich ist sollte bewusst hingenommen werden, zum einen weil diese durch die Effektivitätsverluste mehr als ausgeglichen würde, zum anderen weil so Zeit zur Abarbeitung der liegengebliebenen Arbeit entsteht.

So naheliegend das auch erschent, für grosse Organisationen sind stabile Teams etwas hochgradig Ungewohntes, das sich nur schwer umsetzen lässt. Dort wo das Hin- und Herschieben zwischen Projekten, Taskforces, Stabilisierungsphasen und Sondereinsätzen Normalität ist sorgen stabile Teams nämlich zunächst für Störungen in den Abläufen - wer daran gewohnt ist in Stressphasen mehr personelle Unterstützung anfordern zu können wird es als Behinderung seiner Arbeit empfinden wenn das nicht mehr geht.

Um zu verhindern dass diese Stabilisierung direkt im ersten Belastungsfall weg-eskaliert wird ist eine Rückendeckung der höheren Entscheidungseben hilfreich. Und wenn diese zuerst überzeugt werden müssen - um so besser. Denn wer stabile Teams will sollte erklären können warum.

Freitag, 17. Juli 2020

Die Thukydides-Falle

FS

Bild: Wikimedia Commons / Bibi Saint-Pol - Public Domain
Vor langer Zeit entwickelte ein griechisches Tal namens Lakonia eine einzigartige Kriegerkultur. Von der Kindheit an wurde jeder Einwohner in den Kampfkünsten ausgebildet, was zur Herausbildung einer Armee führte die so stark war, dass sie als die mächtigste in ganz Griechenland galt. Erst Jahrhunderte später entstand auf den weiter östlich gelegenen Inseln und Halbinseln ein Militärbündnis vergleichbarer Stärke, der attische Seebund. Es kam wie es kommen musste - schon nach wenigen Jahrzehnten führten die beiden Krieg gegeneinander.

Dass wir diesen Krieg (auch bekannt als Krieg zwischen Sparta und Athen oder Peleponnesischer Krieg) heute als zwangsläufig ansehen verdanken wir dem grichischen General und Historiker Thukydides, der in seiner Geschichte des Peleponnesischen Krieges davon ausging, dass die Umstände nichts anderes zugelassen hätten - Sparta hätte seine hart erkämpfte dominante Position nicht aufgeben wollen, Athen hätte aber auf den eigenen Aufstieg nicht verzichten wollen, so dass alles auf einen Konflikt zusteuerte.
The real cause [of the war] I consider to be the one which was formally most kept out of sight. The growth of the power of Athens, and the alarm which this inspired in Lacedaemon, made war inevitable.

Diese Analyse von Thukydides wurde mehr als 2000 Jahre später vom amerikanischen Politik-Professor Graham Allison in eine generelle Regel überführt, die er die "Thukydides-Falle" nannte. Ihr zufolge führt eine Situation in der sich eine bestehende Kraft durch eine neue Kraft bedroht fühlt fast immer zu einer feindseligen Auseinandersetzung. Der Grund dafür ist, dass dieses Gefühl des Bedroht Werdens alles andere überlagert, wodurch auch eigentlich beherrschbare Meinungsverschiedenheiten dramatisiert werden und zu einer Eskalationsspirale sich ständig steigernder Reaktionen und Gegenreaktionen führen.
A risk associated with Thucydides’s Trap is that business as usual - not just an unexpected, extraordinary event - can trigger large-scale conflict. When a rising power is threatening to displace a ruling power, standard crises that would otherwise be contained [...] can initiate a cascade of reactions that, in turn, produce outcomes none of the parties would otherwise have chosen.
Angelehnt an Allison können die genannten Phänomene nicht nur in der Politik beobachtet werden sondern auch in Organisationen die gerade Veränderungen durchlaufen. Es gibt die Inhaber bestehender Machtpositionen, die bisher das Recht hatten Prozesse zu gestalten, Budgets zu verplanen, Ziele zu setzen oder den Zugang zu Kunden und Top-Management zu gewähren oder zu verweigern, und es gibt auf der anderen Seite die Anhänger und Vertreter von neuen Ansätzen, von New Work, Lean, Agile oder Beyond Budgeting, die mit diesen Themen anders umgehen und zunehmend mit ihren alternativen Ansätzen Gehör finden.

Da diese neuen Ansätze sehr häufig die bestehenden Machtstrukturen und Karrierepfade in Frage stellen kann sich für die Vertreter des Status Quo auch hier ein Bedrohungsgefühl einstellen. An dieser Stelle besteht dann das Risiko, dass die Thukydides-Falle zuschnappt. Normale Meinungsverschiedenheiten über Produktentwicklung, Beförderungen, Umorganisationen, Budgetierungen, etc. können dann als Teil einer sich ständig verschärfenden Auseinandersetzung zwischen "alt" und "neu" wahrgenommen werden und diese auch weiter befeuern.

Sich dieser Mechanismen bewusst zu sein ist bereits ein erster Schritt in Richtung zu ihrer Überwindung, was folgen muss ist das in Veränderungsvorhaben übliche Konfliktmanagement. Ist den Beteiligten klar, dass hier ein Richtungs-, bzw. Machtkonflikt auf andere Bereiche übergreift? Sind sie bereit dieses Übergreifen zu verhindern? Sind sie überhaupt gewillt diesen (möglicherweise unterschwelligen) Konflikt zu thematisieren?

Im Zweifel braucht es in diesen Momenten auch eine klare Positionierung der oberen Hierarchieebenen: klar zu kommunizieren was das zukünftige Zielbild der Organisation sein soll kann den Konflikt und seine Entscheidung vorwegnehmen. Das wird natürlich nicht jedem Beteiligten gefallen, es kann aber verhindern, dass "in den Krieg gezogen wird".

Montag, 13. Juli 2020

(Mittleres) Management

FS
Bild: Pxfuel - CC0 1.0
Irgendwann in den 2000er Jahren hat sich in der "agilen Bewegung" die Erkenntnis durchgesetzt, dass eine Umstellung auf (wie auch immer geartete) agile Arbeitsweisen weitgehend wirkungslos bleiben wird wenn die umgebende Organisation sich nicht ebenfalls ändert, zumindest bis zu einem gewissen Grad. Auch die dafür scheinbar entscheidende Gruppe wurde in dieser Zeit identifiziert und wird seitdem wahlweise als Erfolgs-Schlüssel oder Haupthindernis eines jeden Grossunternehmens-Transformationsvorhabens intensiv diskutiert: das mittlere Management. Das Problem an dieser Stelle - es gibt weit auseinandergehende Meinungen darüber wer sich hinter diesem Begriff verbirgt.

Das auf den ersten Blick Paradoxe an dieser Unklarheit ist allerdings, dass die meisten Scrum Master und Agile Coaches spontan in der Lage zu sein scheinen dieses mittlere Management zu beschreiben: es ist (naheliegenderweise) die mittlere Verwaltungsschicht zwischen der strategisch operierenden Vorstandsebene und den operativ tätigen Umsetzungsteams. Und auch eine Problemanalyse kann im Regelfall direkt mitgeliefert werden - diese mittlere Ebene ist demnach die sprichwörtliche Lehmschicht oder Lähmschicht, die Angst vor Macht- und Statusverlust hat und darum durch Bürokratie und Politik dafür sorgt, dass alle Veränderungen verlangsamt und verkompliziert werden. Ein häufiger Reflex ist es daher, diese Gruppe ersatzlos abschaffen zu wollen um dadurch die Organisation schlanker und beweglicher zu machen.

Wie so oft bei stark vereinfachenden Erklärungen hält auch diese einer näheren Betrachtung nicht lange stand, am offensichtlichsten deshalb weil sich schnell zeigt, dass das mittlere Management gar nicht alles zwischen Vorstand und Umsetzungsteams umfassen kann. Alleine der Begriff impliziert schliesslich, dass es neben dem mittleren auch ein unteres und ein oberes Management geben muss. Und dass diese verschiedenen Gruppen nochmals in Untergruppen zerfallen die verschiedene Verhaltensweisen haben und von verschiedenen Motivationen getrieben werden lässt sich ebenfalls schnell erkennen. Hinter der generalisierenden Vorstellung des Mittelmanagements stecken also durchaus grosse Unterschiede.

Beginnen wir am unteren Ende. Unmittelbar oberhalb der Umsetzungsebene befindet sich eine erste Management-Schicht. Zum Einen sind das die permanent vorhandenen Linienmanager, also die Gruppenleiter, Teamleiter oder Referatsleiter. Sie sind die unmittelbaren disziplinarisch Vorgesetzten der untersten Ebene. Neben ihnen stehen häufig weitere, eher operativ koordinierende Mitglieder des unteren Managements, die Einsatzleiter, Teilprojektleiter oder Projektmanager. Die Haupttätigkeit dieser verschiedenen Rollen besteht normalerweise in der Anleitung und Überwachung ihrer Untergebenen im Rahmen von deren täglicher Arbeit.

Das eigentliche mittlere Management zerfällt ebenfalls in verschiedene Teilgruppen. Zum einen die jeweiligen Vorgesetzten der unteren Linienmanager, in der Regel die Abteilungsleiter. Zum anderen die Vorgesetzten der operativen unteren Manager, in der Regel Projektleiter. Beiden Rollen ist eine Zwischenposition gemeinsam: sowohl an grossen strategischen Entscheidungen als auch an der Umsetzung sind sie nicht beteiligt, stattdessen verbinden sie diese beiden Ebenen, meistens durch die Ausdetaillierung weiterzugebender Ziele und die Konsolidierung zu sammelnder Fortschrittsberichte. Als dritter Typ kommen Rollen dazu die für die Überwachung von Regeln zuständig sind: Test-Manager, Realease-Manager, Prozess-Manager, etc.

Eine dritte Gruppe befindet sich im Grenzbereich zwischen "oberem Mittelmanagement" und Top-Management, übliche Titel sind im hierarchischen Bereich der Direktor oder Bereichsleiter und bei Grossvorhaben der Programmleiter. Diese Gruppe tritt vor allem dann auf wenn Organisationen so gross sind, dass das eigentliche Topmanagement (Geschäftsführung, Vorstand, Chief Irgendwas-Officer) nicht mehr in der Lage wäre sich direkt mit dem eigentlichen Mittelmanagement zu koordinieren. Je nach Unternehmen kann es sich bei ihr um eine weitere Zwischenschicht handeln oder um eine Ebene die bereits an der strategischen Entscheidungsgestaltung beteiligt ist.

Was bei einer derartig differenzierten Betrachtung des (mittleren) Managements klar wird ist, dass übergreifende Zuschreibungen von Problem-Dimensionen und Lösungskompetenzen kaum möglich sind. Das Untergraben der Selbstorganisation von Teams aus Angst vor Bedeutungs- und Statusverlust findet vor allem im unteren Management statt, wenn es im mittleren Management stattfindet dann bei den regelüberwachenden Managern, denen aber im Rahmen ihrer Aufgabenbeschreibung oft keine andere Wahl bleibt als das zu tun. Das sonstige Mittel- und obere Management ist dagegen oft froh wenn ihm selbstorganisierte Teams die Beschäftigung mit den zeitraubenden operativen Abläufen ersparen.

Im Rahmen von organisatorischen Veränderungen in Richtung von mehr Agilität ergeben sich daraus unterschiedliche Lösungsansätze. Bei der Rolle des Teilprojektleiters kann man z.B. fragen ob man die wirklich noch braucht, der Test-Manager könnte durch eine Anpassung der Rollenbeschreibung vom Kontrolleur zum Coach werden und der Bereichs- oder Abteilungsleiter kann weiter dafür sorgen, dass Strategie oder Produktvision des Unternehmens so heruntergebrochen werden, dass Teams damit arbeiten können. Diese unterschiedlichen Optionen zu kennen und vermitteln zu können ist in Umbruchssituationen entscheidend. Und dass es zielführende ist als pauschalisierende Problem-Zuschreibungen braucht wohl nicht erklärt zu werden.

Donnerstag, 9. Juli 2020

Sprint Backlogs

FS
Bild: Pexels / Bruno Bueno - CC0 1.0
Das Sprint Backlog ist ein kleines Mysterium. Eigentlich ist es ein so zentraler Teil von Scrum (und ähnlichen Ansätzen), dass jeder der schon einmal mit diesem Framework gearbeitet hat es kennen sollte, andererseits dürfte man aber bei den meisten Teams eher Ratlosigkeit verursachen wenn man danach fragt. Bestenfalls kommt irgendwann die Erkenntnis, dass das die Arbeit ist "die man in den Sprint zieht". Das ist auch nicht falsch, aber auch nicht ganz richtig. Es ist mehr als nur das.

Um mit dem Offensichtlichsten zu beginnen: genau wie im Fall des Product Backlog hat auch das Sprint Backlog im Englischen eine Bedeutung die sich problemlos ins Deutsche übersetzen lässt. Es ist das Backlog des Sprints, also der Rückstau (→ Backlog) unerledigter Arbeit, der während des nächsten Umsetzung-Zeitraums (→ Sprint) abgearbeitet werden muss. Das klingt zunächst banal, hat bei näherer Betrachtung aber Folgen, und zwar sowohl in Bezug auf die Größe als auch in Bezug auf die Darstellung.

Beginnen wir mit der Grösse. Um im nächsten Sprint abgearbeitet werden zu können darf der Rückstau nicht grösser sein als die Arbeitskapazität des Team in dieser Zeit. Auch das klingt banal, hat aber weitreichende Implikationen. Es verhindert, dass Wunschlisten undefinierbarer oder ausufernder Grösse in die Umsetzung gegeben werden und erzwingt eine Reduzierung auf das Wesentliche, da ja am Sprintende ein benutzbares Ergebnis stehen soll. Das gilt zwar theoretisch auch im klassischen Projektmanagement, in dessen grossen Releaseplanungen fällt "die eine zusätzliche Anforderung" aber oft nicht auf. Die maximal vierwöchigen Sprints erzwingen eine wesentlich grössere Disziplin.

Nun zur Darstellung. Selbst wenn Teams den Begriff des Sprint Backlogs kennen verwechseln sie ihn häufig mit der Summe aller Arbeit die im Sprint ist. Auch hier hilft eine Erinnerung an die Übersetzung: der Rückstau (→ Backlog) ist eben nicht "alles auf dem Board" sondern lediglich das was noch unberührt auf seine Erledigung wartet. Vereinfacht gesagt könnte man demnach alles was noch im To Do-Bereich ist als das Backlog bezeichnen, oder noch stärker vereinfacht - das Sprint Backlog ist der linke Teil des Boards.


Zusammengenommen ergibt sich aus diesen beiden Aspekten noch ein dritter, nämlich der der Planbarkeit, bzw. Prognostizierbarkeit. Da von einem Sprint mit fortschreitender Zeit immer weniger Tage übrigbleiben muss zwangsläufig auch das Backlog immer weiter schrumpfen wenn es noch umsetzbar bleiben soll. Das kann entweder dadurch passieren, dass nach und nach immer mehr Arbeit erledigt (und damit aus dem Rückstau/Backlog entfernt) wird, es kann aber auch heissen, dass Aufgaben wieder aus dem Sprint herausgenommen werden müssen1 um ihn wieder erfolgreich abschliessbar zu machen.

Wer schon einmal in komplexen Entwicklungsprojekten gearbeitet hat dürfte mittlerweile ahnen, dass ein Sprint Backlog durchaus anspruchsvoll zu erstellen ist. Es soll in wenigen Wochen umsetzbar sein, ein brauchbares Ergebnis erzeugen, schrittweise abzuarbeiten sein und eine im Zweifel modifizierbare Grösse haben? Wie soll das gehen? Die kurze Antwort: durch schlankes, flexibles, ergebnisorientiertes und in Kommunikation eingebettetes Formulieren von Anforderungen. Mögliche lange Antworten stehen hier, hier, hier und hier.


1Bei einer korrekten Umsetzung von Scrum nur so, dass das Sprintziel erreichbar bleibt. Geht das nicht sollte der Sprint abgebrochen werden.

Montag, 6. Juli 2020

Fewer things, more done

FS
Dass auch Konferenzen jetzt remote stattfinden scheint den Nebeneffekt zu haben, dass die Vorträge kürzer werden. Statt der vorher meistens üblichen Stunde redet Randy Shoup hier nur knapp zwanzig Minuten zum Thema Agile at Scale - und das ohne dass es gehetzt und unvollständig wirkt.



Angesichts der Länge und des Themas ein guter Kandidat um es dem eigenen Management zu empfehlen, denn so selbstverständlich die Inhalte (Crossfunktionale Teams, kurze Lieferzyklen, psychologische Sicherheit) einem Agile Coach auch erscheinen mögen - für die meisten Firmen sind sie noch immer revolutionär,

Freitag, 3. Juli 2020

Die vier Varianten der agilen Hardware-Produktentwicklung

FS

Bild: Wikimedia Commons / Jonathan Juursema - CC BY-SA 3.0

Das Thema der Agilität im Hardware-Bereich hat leicht mythische Züge. Obwohl es sich um die älteste Variante der agilen Produktentwicklung handelt (dazu gleich mehr) gibt es in der von Softwareentwicklung und Organisationsentwicklung geprägten Community kaum jemanden der schon einmal daran beteiligt gewesen wäre. Die Folge ist die erwähnte Mythologisierung: irgendwie geht es, irgendwo findet es bereits statt, irgendwie ist es aber unklar wie es gehen soll. Die Wahrheit ist dabei viel profaner - ganz im Sinn der alten Erkenntnis, dass Agilität einfach zu verstehen aber schwer umzusetzen ist, sind die wesentlichen Erscheinungsformen der agilen Hardware-Herstellung einfach zu beschreiben - und schon oft beschrieben worden.

Prototyping

Die gerade erwähnte älteste Erscheinungsform agiler Produktentwicklung überhaupt. Bereits 1986 beschrieben Hirotaka Takeuchi und Ikujiro Nonaka in ihrem bahnbrechenden Artikel The New New Product Development Game wie crossfunktionale, selbstorganisierte, End to End-verantwortliche Teams bei Canon, NEC, Xerox und Honda in kurzen Zyklen neue Produkte entwickelten - Foto-Apparate, Computer, Kopierer und Autos. Wichtig ist in diesem Fall, dass es sich noch nicht um Serienfertigung handelte sondern um die Erstellung von Prototypen oder Vorserien-Modellen, deren Neuartigkeit und geringe Stückzahl den relativ hohen Handarbeits- und Abstimmungsaufwand nötig (und vertretbar) machte. Vergleichbare Vorgehensweisen gibt es in frühen Produktentwicklungsphasen bis heute.

Computer-aided Design

Ein anderer Ansatz um möglichst früh zu benutzbaren Ergebnissen zu kommen. Basierend auf den Erfahrungen der Vergangenheit werden neue Ideen durch eine IT-gestützte Machbarkeitsanalyse geschickt. Das ersetzt natürlich nicht die menschliche Kreativität (und das soll es auch nicht), es ermöglicht aber ein "fail fast, learn fast, try again" in sehr kurzen Zyklen. Wenn die Berechnungen z.B. zeigen, dass das Material eines Bauteils einer angedachten Belastung nicht standhalten würde, dann kann man direkt mit der Entwicklung einer verbesserten zweiten Version beginnen ohne von der ersten auch nur einen Prototypen erstellt zu haben. Beeindruckend ist auch die Spannbreite der möglichen Einsätze, sie reicht vom Hausbau bis zum Turnschuh.

3D-Druck

Ein erster Ansatz um auch die serielle Fertigung flexibler und anpassungsfähiger zu machen. Obwohl der 3D-Druck zunächst wie eine blosse Fertigungs-Art wirkt (z.B. im Bild oben) ist das wesentliche Element auch hier die Verbindung mit der IT. Moderne 3D-Drucker können mit einer einzigen Fertigungsanlage praktisch jede statisch mögliche Form erstellen ohne dafür umgebaut werden zu müssen, nötig ist dafür nur noch das Einspielen einer neuen Bauvorlage. Auf diese Art können in kurzer Zeit alle nötigen Einzelteile selbst für komplizierte Maschinen gebaut werden, zum Beispiel für Flugzeuge. Und auch von denen kann dann jedes Einzelne nochmal individuell angepasst werden.

Modulare Montage

Ein anderer Ansatz für die serielle Fertigung, diesesmal einer der darauf aufbaut, dass die zusammenzubauenden Einzelteile zwar immer gleich sind, es aber möglich ist sie in unterschiedlichen zusammensetzungen zu kombinieren. Konkret geschieht das dadurch, dass die lineare Fertigungsstrasse abgelöst wird durch verschiedene automatisierte "Montage-Inseln", die von einem (das Fliessband ersetzenden) Montage-Roboter in unterschiedlicher Reihenfolge angefahren werden können. Auch hier ermöglicht eine IT-Steuerung schnelle individuelle Ergebnisse, ohne dass die Fertigungsanlage dafür umgebaut werden müsste.

Rocket Science

Wie oben gesagt, Hardware-Agilität ist einfach zu verstehen aber schwer umzusetzen, tatsächlich so schwer, dass man immer wieder hört, dass das Ganze nur in der Theorie möglich wäre. Das es sehr wohl geht zeigt ausgerechnet eine Firma deren Tätigkeit (die Raumfahrt) im Englischen sprichwörtlich für extrem schwierige Herausforderungen steht. SpaceX ist nicht das einzige, vermutlich aber das prominenteste Beispiel dafür, dass sogar alle vier Varianten der agilen Hardware-Produktentwicklung gleichzeitig einsetzbar sind. Und eine Schlusspointe wird auch möglich - wer Hardware-Agilität meistert kann nach den Sternen greifen.
Powered by Blogger.