Donnerstag, 6. August 2020

Die Agile Framework-Matrix

FS
Es gibt Ideen von denen man direkt fasziniert ist. Diese hier von Dave Snowden gehört dazu.
Wie er selbst sagt ist sie in dieser Form nicht ganz ernstzunehmen, sie bietet aber einen guten Ansatzpunkt um weiter darüber nachzudenken ob und wie man die gängigen agilen Frameworks in eine zweidimensionale Matrix einordnen könnte und was sich danach mit dieser Einordnung machen lässt. Das Ziel dieser Übung: ein Werkzeug zu entwickeln mit dem sich Verständlichkeit und Anwendbarkeit überprüfen lassen.

Als erste Achse bietet sich definitiv das an was Snowden oben links die "kultgleiche, mystische Sprache" genannt hat. Wer schon einmal in einem agil arbeitenden Umfeld tätig gewesen ist wird wissen was er meint - über die Jahrzehnte hat sich hier eine Fachsprache aus verschiedensten Elementen gebildet (Sport-Metaphern, Management-Englisch, Japanisch, IT-Begriffe, etc.), die Vieles zu Beginn unnötig unverständlich macht. Eine geringe Ausprägung dieses Werts ist demnach gut, eine hohe schlecht.

Die zweite Achse ist schwieriger, da seine Benennung hier "leicht verkopft" ist. Um sich nicht im Versuch einer Definition von "ontologisch-epistemologisch" zu verlieren versuchen wir es mit einem Befreiungsschlag: wenn ein agiles Framework Erkenntnistheorie und Metaphysik notwendig macht ist vorher offensichtlich sein Beschreibungsumfang so ausser Kontrolle geraten, so dass er nicht mehr einfach fassbar ist. Ein geringer Umfang ist demnach gut, ein hoher schlecht.

Und mit diesen Festlegungen lässt sich die Matrix tatsächlich bauen, samt der ersten Framework-Einordnungen.
Um es auf den Punkt zu bringen: unten links in diesem Bild befinden sich die minimalistisch-einfach verständlichen Frameworks, oben rechts die aufgebläht-unverständlichen. Diese Einordnung ist natürlich nicht ohne subjektiven Einschlag, dürfte aber im Grossen und Ganzen so hinkommen.

Interessant ist noch Snowdens Idee, die Frameworks nicht als Punkte sondern als Pfeile darzustellen, also nicht nur ihre Position sondern auch ihre bisherige Entwicklung zu visualisieren. Das würde zwar etwas "historische Forschung" erfordern, würde aber auch die Option eröffnen Trends festzustellen, aus denen man Wahrscheinlichkeiten ableiten kann wie die Entwicklung vermutlich weitergehen wird.

Nachtrag:
Even more Food for Thougt

Montag, 3. August 2020

Ein Bild sagt mehr als 1000 Worte (XXIX)

FS

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.

Dienstag, 30. Juni 2020

Kommentierte Links (LXIII)

FS
  • Tendayi Viki: Do Entrepreneurs Really Create More Transformative Innovations Than Intrapreneurs?

  • Es gibt Zahlen die überraschen, und die die Tendayi Viki hier aus einer älteren Studie ausgegraben hat gehören dazu: es waren keine Startups in denen die meisten bahnbrechenden Innovationen zwischen 1980 und 2010 gemacht wurden sondern Konzerne (auch für die 10 Jahre danach lässt es sich feststellen - das Meiste was unsere Welt verändert hat kommt aus den "Big Companies" der amerikanischen Westküste und asiatischen Ostküste). Was sich daraus ergibt: anders als in der öffentlichen Wahrnehmung verankert ist es nicht der Entrepreneur, also der genialisch veranlagte Erfinder/Unternehmensgründer, der unsere Art zu Leben und zu Arbeiten verändert. Wichtiger ist stattdessen der Intrapreneur, der als Teil einer grossen Organisation für deren bestehende Kunden Neues erschafft und Bestehendes verbessert. Ein Grund mehr den eigenen Mitarbeitern Raum zur Selbstorganisation und Selbstentfaltung zu geben. (siehe auch Vikis zweiten Artikel zu dem Thema: Why Intrapreneurs Are Not Just Entrepreneurs Working Inside Large Companies)

  • Yuri Malishenko: How visual thinking can make you a better agile coach

    Dass es hilfreich ist neue Informationen auch mit einfachen Bildern zu visualisieren um sie mit verschiedenen Sinnen aufnehmen zu können ist nichts was die "agile Bewegung" erfunden hätte, schon die Jahrtausende alten Höhlenmalereien beruhen auf diesem Prinzip. Mit dem Aufkommen von Flip-Charts und Post-Its auch im Büro-Kontext anwendbar geworden sind diese schnell erstellten Zeichnungen aber zu einem Erkennungszeichen agiler Teams und Coaches geworden und tragen zur Soft Power der Agilität bei. Yuri Malishenko gibt mit seinem Artikel einen interessanten Einblick in diese "Kleinkunst", sowohl in Bezug auf die verschiedenen möglichen Anwendungsgebiete als auch in Bezug auf die digitale Wieder- und Weiterverwendung. Gerade letzteres dürfte in einer Zeit zunehmender Remote-Arbeit immer wichtiger werden.

  • Ellen Merryweather: The Difference: Prototype vs MVP

    Nicht nur im Startup-Umfeld, auch in mittleren und grossen Unternehmen gibt es den zunehmenden Trend Produktentwicklungen mit einem Prototypen oder MVP zu beginnen statt von Beginn an umfangreiche "fertige" Versionen zu entwickeln von denen sich dann beim Release herausstellt, dass kein Kunde sie so will. Das ist für sich genommen erstmal gut, das zu beobachtende Problem ist aber eine Verwirrung was denn mit diesen Begriffen genau gemeint sein soll. Ellen Merryweathers Differenzierungsversuch ist hier sehr hilfreich, vor allem weil sie sich nicht darauf konzentriert zu beschreiben was Prototyp und MVP sind sondern wofür sie ihrer Meinung nach gedacht sind: das eine für interne Machbarkeits-Analysen, das andere für das Einholen von frühem Feedback potentieller Benutzer.

  • GeePaw Hill: An Intro to Spikes

    Passend zum letzten Thema: Michael Hill aka GeePaw Hill gehörte zu den ersten Extreme Programming-Coaches und dürfte daher wie kaum ein anderer geeignet sein die dazugehörigen Konzepte und Begriffe zu erklären. Der dessen er sich hier annimmt ist einer der etwas unbekannteren - der Spike. Pawhill definiert ihn hier als spezifische Anforderung eines Proof of Concept oder eines Prototypen. Ganz wichtig in seiner Definition: egal was das Ergebnis ist, es darf nicht in das Produkt eingebaut werden. Würde das doch passieren wäre das Risiko zu gross, dass das im Anschluss nötige Refactoring immer weiter nach hinten priorisiert wird und der (von Natur aus rudimentäre) PoC-Code in Live-Betrieb und Weiterentwicklung die Produktqualität, Architektur, Performance und andere wichtige Aspekte negativ beeinflusst.

  • Mike Cohn: Can a Team Vote Someone Off the Team?

    Ein schönes Bespiel für eine Frage die scheinbar mit Ja oder Nein zu beantworten ist, dann aber ein grosses "Kommt darauf an" nach sich zieht. In diesem Fall: es kommt darauf welchen Grad an Autonomie dieses Team hat. Mike Cohn übernimmt dazu die Abstufung von Richard Hackmann, bestehend aus Manager-Led (fremdbestimmt), Self-Organizing (selbstorganisiert), Self-Designing (sich selbst zusammenstellend) und Self-Governing (den eigenen Zweck bestimmend). Naheliegenderweise ist das Entfernen eines Teammitglieds durch das Team ab Stufe drei möglich. Was Cohn ausserdem zu Recht betont: in der Realität findet man solche Teams sehr selten.

Donnerstag, 25. Juni 2020

Paper Prototyping

FS
Bild: Flickr / Rosenfeld Media - CC BY 2.0
In Ansätzen wie Lean Startup und Design Thinking stehen MVPs und Prototypen im Vordergrund, also frühe, mit möglichst wenig Aufwand erzeugte Arbeitsergebnisse, die aber trotzdem schon einen so guten Eindruck vom späteren Produkt geben, dass auf dessen Basis ein erstes Benutzerfeedback eingeholt werden kann. Diese Gleichzeitigkeit von möglichst wenig Aufwand und möglichst gutem Eindruck ist natürlich eine Herausforderung, die nur mit bestimmten Techniken gemeistert werden kann. Eine der bekanntesten unter ihnen ist das Paper Prototyping.

Die grundlegende Idee ist simpel - statt mit relativ viel Arbeit irgendetwas Vorzeigbares in digitalen Design-Tools zu entwerfen, es zu programmieren und es dann auf ein Vorführgerät oder eine Vorführumgebung zu bringen wird einfach ein Entwurf mit Stiften auf ein Papier gemalt und der dann der Zielgruppe vorgelegt. Die muss dann nur noch die Frage beantworten ob er ihr gut genug gefällt um mit mehr Aufwand in eine echte Umsetzung zu gehen. Wenn nicht kann man verbessern - oder abbrechen ohne Investitionen zu verlieren.

Für jemanden der einen solchen Papier-Prototypen noch nie gesehen hat (oder nur solche die dilettantisch erzeugt wurden) wird dieser Ansatz zuerst merkwürdig klingen. Ein bemaltes Papier soll ausreichend sein um verwertbares Nutzerfeedback zu erzeugen? Die Skepsis ist berechtigt, wie so oft gilt auch hier, dass man eine gelungene Anwendung gesehen haben muss bevor man sich etwas darunter vorstellen kann. Glücklicherweise gibt es im Internet genug gute Beispiele, wie etwa dieses Video (nur eine Minute lang):



Gut sichtbar sind hier einige Erfolgsfaktoren: die hier gezeigten Prototypen sind durch Color Coding und minimalistisches Design so übersichtlich gestaltet, dass eine Konzentration auf die zentralen Funktionen stattfindet, die aufeinanderfolgenden "Screens" simulieren einen Bedienungsablauf (was dann durch den "Vorführ-Rahmen" noch besser erfahrbar wird) und durch Elemente wie die Klappmeüs und die Post It-Schnipsel ist bereits eine echte Interaktion möglich.

Anhand dieses Beispiels kann man es sich schon besser vorstellen wie ein Paper Prototype zu Vorführzwecken verwandt wird. Auch von der dadurch möglichen Geschwindigkeit bekommt man eine Vorstellung - ein geübter Zeichner wird in der Lage sein das Feedback der Testgruppe innerhalb von Minuten in einen verbesserten und direkt wieder testbaren Prototypen einzuarbeiten, ein Tempo mit dem kein noch so guter digitaler Entwurf mithalten kann.

Natürlich gibt es bei diesem Vorgehen auch Risiken, von denen als wichtigstes die Illusion einer einfachen Umsetzbarkeit zu nennen ist (ich durfte einmal miterleben wie ein Team aus UX-Designern einen vom Kunden gefeierten Prototypen einer Website erstellte, nur um nachher zu erfahren, dass die Umsetzung die halbe IT ein Jahr lang beschäftigt halten würde). Durch eine frühe Einbindung der IT in den Prototyping-Prozess lässt sich die Wahrscheinlichkeit solcher Missverständnisse aber reduzieren.

Trotz dieses Risikos ist Paper Prototyping aufgrund der genannten Vorteile vor allem in den frühen Phasen einer Produktentwicklung wärmstens zu empfehlen, das schnelle Feedback und die Möglichkeit einer extrem frühen Verbesserung des Produkts wiegt die möglichen Nachteile klar auf. Und im schlimmsten Fall muss man nichts verwerfen ausser den ersten Blättern eines Papierblocks, bevor man mit den nächsten Blättern den nächsten Prototypen baut.

Montag, 22. Juni 2020

Das Problem mit Jira, Trello, Leankit & Co

FS
Bild: Wikimedia Commons / Hunini - CC BY-SA 4.0
Wenn man Teil eines durchgängig aus dem Homeoffice arbeitenden agilen Projekts ist, ist es in den meisten Fällen nicht mehr die Frage ob man eines der zahlreichen digitalen Arbeitsmanagement-Tools benutzt, es geht nur noch darum welches - Jira, Trello, Leankit, Octane, den Teams Planner oder eines der eher unbekannten Nischen-Tools. Sie alle haben aber zwei Dinge gemeinsam: sie verändern die Art wie wir Arbeit (und Arbeits-Management) wahrnehmen und sie bringen eigene Prozessabläufe mit sich die man zwangsläufig zu den eigenen machen muss. Man sollte ihnen daher mit Vorsicht und bewusstem Herangehen begegnen, immer mit der klassischen Coaching-Frage im Hinterkopf - was macht das mit mir?.

Die offensichtlichste Folge ist, dass die Sichtbarkeit der Arbeit abnimmt. während man vorher auf einer Wand den Überblick über alle wichtigen Informationen haben konnte (Sprint-Board, Burndown, Impediments, Personas, etc.) sind diese zwar immer noch da, allerdings verstreut über verschiedene Websites. Um von einer zur anderen zu wechseln muss man sich durch Tabs klicken oder Seitenabschnitte durchscrollen. Das Big Picture geht verloren.

Was ausserdem häufig unterschätzt wird: das physische Board ist unübersehbar präsent und erinnert an To Dos und Missstände, das digitale Board wird in der Regel nur während der Meetings aufgerufen und ist sonst unsichtbar. Und selbst wenn man es auf grossen Wandbildschirmen präsentiert sind die meisten Tools so aufgebaut, dass wichtige Informationen innerhalb der Tickets gespeichert werden und erst sichtbar werden wenn man diese separat öffnet.

Ein ebenfalls erst auf den zweiten Blick sichtbarer Effekt ist der, dass digitale Tools oft zu einer starken Aufblähung des Informationsumfangs führen. Jedes Ticket enthält eine Vielzahl von potentiell nutzbaren Freitextfeldern, Labels, Attachements und Verlinkungen, die zum einen ein schlechtes Gefühl erzeugen können wenn man sie frei lässt (→ Horror Vacui), zum anderen aber auch keine Obergrenze setzen, so dass in Summe aller Tickets eine nicht mehr aktuell zu haltende Umfangsmenge entstehen kann.

Offensichtlicher als die zuvor genannten Punkte ist das Phänomen, dass die Tools ihren Nutzern Prozesse aufzwingen (bzw. bisherige Prozesse nicht abbilden können). Häufig genannt wird z.B., dass Tickets sich immer nur einer Person zuordnen lassen, was im Widerspruch zu der verbreiteten Praktik des Pairings steht. Auch die Aufteilung von Arbeit/Anforderungen in mehr als drei Hierarchie-Ebenen (Epic, Story, Subtask) ist in praktisch keinem Tool möglich, selbst wenn der eigene Planungsansatz es eigentlich erfordern würde.

Was zuletzt fast immer unterschätzt wird ist der mit digitalen Tools verbundene Administrationsaufwand. Dieser umfasst nicht nur die Einrichtung und Berechtigung der Accounts (wobei alleine das schon erstaunlich arbeitsintensiv sein kann) sondern auch das Anlegen und Verwalten von Projekten, Boards, Filtern, etc. Ein verbreitetes Phänomen ist die Wahrnehmung dieser Aufgaben durch die Scrum Master, was einerseits verständlich ist (die Teams werden entlastet) auf der anderen Seite aber dazu führt, dass für seine eigentlichen Aufgaben weniger Zeit bleibt.

Wie zu Beginn gesagt, ganz wird man im Rahmen verteilter Arbeit nicht um die Nutzung digitaler Arbeitsmanagement-Tools herumkommen. Aufgrund der genannten Phänomene sind Teams und Unternehmen aber gut beraten wenn sie sich reflektiert und regelmässig mit der Frage auseinandersetzen welche Auswirkungen das auf ihre Arbeitsweisen hat. Dadurch kann zwar nicht verhindert werden, dass diese durch die Tools beeinflusst werden, man kann aber versuchen das in Bahnen zu lenken die nicht gegenläufig zum grundlegenden Zusammenarbeitsmodell sind.

Donnerstag, 18. Juni 2020

Endspurt, Design Sprint, Sprint

FS

Bild: Flickr / A Healthier Michigan - CC BY-SA 2.0
Gerade dann wenn die Bedeutung eines Begriffs für alle Beteiligten scheinbar selbstverständlich ist lohnt sich ein näherer Blick. Das gilt natürlich auch für die Fachsprache die sich über die Jahrzehnte im Rahmen der agilen Arbeitsweisen entwickelt hat. Ein Fall an dem sich das aufzeigen lässt ist der Sprint. Je nach Kontext können sich hinter diesem Wort stark unterschiedliche Ausprägungen verbergen, derer man sich bewusst sein sollte wenn man es benutzt.

Die in der Realität am häufigsten anzutreffende Variante lässt sich am besten als "Endspurt" beschreiben. Nach längeren Anforderungserhebungs- und Planungsprozessen geht es hier nur noch darum das definierte Ergebnis in kurzen Schüben umzusetzen (häufig anzutreffen in SAFe). Sinn macht ein derartiges Vorgehen vor allem dann wenn die Anforderungen und Nutzerbedürfnisse relativ klar und stabil sind, die Umsetzung aber technisch oder organisatorisch anspruchsvoll ist. Der Inspect & Adapt-Zyklus dient dann nur noch der Überprüfung und Anpassung des Umsetzungsvorgehens. Das mit diesem Ansatz verbundene Risiko ist, dass er entgleisen kann wenn die Anforderungen sich ändern.

Auch der umgekehrte Fall existiert, es sind die so genannten "Design Sprints". In ihrer bekanntesten Variante enthalten sie nicht nur das blosse Anforderungsdesign sondern auch die Erstellung erster Prototypen oder Vorführ-Versionen und deren Validierung an einer echten Anwender-Zielgruppe. Sobald diese positiv reagiert erfolgt die Übergabe an die eigentliche Umsetzung. Sinn macht ein derartiges Vorgehen vor allem dann wenn die Anforderungen und Nutzerbedürfnisse noch unklar oder instabil sind. Der Inspect & Adapt-Zyklus dient vor allem dem Erstellen und Verwerfen von Bedarfs- oder Anwendungs-Hypothesen. Das mit diesem Ansatz verbundene Risiko ist, dass seine Ergebnisse sich als nur schwer umsetzbar herausstellen können.

Der dritte Typ entspricht den Sprints in Scrum oder den Iterationen in Extreme Programming. Der Anspruch dieses Ansatzes ist, auf der Basis einfach formulierter Anwender-Bedürfnisse sowohl das Design als auch die Umsetzung einer Funktionserweiterung in einem (!) Intervall umzusetzen. Sinn macht dieses Vorgehen wenn sowohl die Anforderungen und Nutzerbedürfnisse als auch die Bedingungen der Umsetzung sich ändern können. Der Inspect & Adapt-Zyklus sollte alle dieser Aspekte berücksichtigen. Das mit diesem Ansatz verbundene Risiko ist, dass er bei vielen Abhängigkeiten und hohem Abstimmungsbedarf unverhältnismässig viele Ressourcen für diese Themen verwendet.1

Was anhand dieser verschiedenen Ausprägungen erkennbar ist: abhängig von Verständnis und Erfordernissen kann sich jeweils etwas Unterschiedliches hinter dem scheinbar klaren Begriffs des Sprints verbergen (dazu kämen noch Antipattern wie z.B. der Konzeptions-Sprint", der "Test-Sprint" oder der "Gewaltmarsch"), es macht also grossen Sinn sich zu vergewissern welches im eigenen Fall vorliegt.


1Der übliche Lösungsansatz im agilen Vorgehen wäre die Vermeidung oder Auflösung von Abhängigkeiten, z.B. durch crossfunktionale Teams oder shared Code.

Montag, 15. Juni 2020

Ein Bild sagt mehr als 1000 Worte (XXVIII)

FS

Freitag, 12. Juni 2020

Die Grundlagen-Dokumente von Scrum

FS

Bild: Pxfuel - CC0 1.0

Scrum ist sich selbst in einer Hinsicht sehr treu: es findet ein kontinuierlicher Verbesserungsprozess statt, in dessen Rahmen seine Regeln ständig überarbeitet, ausdifferenziert aber zum Teil auch wieder verschlankt werden. Da dieser Prozess seit über 30 Jahren anhält ist es nicht immer einfach nachzuverfolgen was zu welchem Zeitpunkt hinzugefügt oder verändert wurde. Dem kann abgeholfen werden - hier sind die wichtigsten Grundlagenwerke auf denen das Scrum-Framework beruht und die es immer weiter entwickelt haben:

1986: The New New Product Development Game (Hirotaka Takeuchi, Ikujiro Nonaka)

Dieser von von den Wissenschaftlern Takeuchi und Nonaka verfasste Artikel über die Arbeit japanischer Fabrikteams ist das einzige Grundlagenwerk an dem die "Scrum-Väter" Jeff Sutherland und Ken Schwaber nicht beteiligt waren (statt Scrum wird auch noch vom "Rugby Approach" gesprochen). Aus heutiger Sicht beschreibt es noch nicht Scrum selbst sondern einige Prinzipien auf denen es beruht, u.a. crossfunktionale Teams und iterativ-incrementelles Arbeiten. Die 1990 erfolgte Übertragung des New New Product Development Game auf die IT durch DeGrace und Stahl war damit die Inspiration für die Entwicklung von Scrum in seinem heutigen Sinn, was Sutherland und Schwaber auch selbst betont haben.

Nachdem Sutherland und Schwaber Scrum in den ersten Jahren nur im Rahmen ihrer eigenen Software-Projekte einsetzten führte der Wunsch es bekannter zu machen zur Vorstellung durch die beiden auf der OOPSLA-Konferenz im Jahr 1995. Das Konferenz-Paper gilt als Initialzündung der weltweiten Verbreitung von Scrum, enthält aber vieles noch nicht was heute zentral ist. Umgekehrt sind noch Elemente vom Wasserfall-Vorgehen enthalten, etwa die Phasen "Pregame", "Game" und "Postgame". Anderes, wie der Sprint, das Sprint-Ziel, das Sprint Planning, das Sprint Review oder der Product Owner (noch als Product Manager), existieren bereits. Scrum ist in dieser (und den nächsten) Versionen explizit ein Ansatz der Software-Entwicklung.

Dieses leicht despektierlich "Scrum-Plop" abgekürzte Gemeinschaftswerk einer ganzen Reihe verschiedener Autoren erwähnt zum ersten mal die Rolle des Scrum Masters, wenn auch noch als eine spezifische Form des Teamleiters, dem auch leitende und kontrollierende Funktionen zugeschrieben werden. Besonders interessant: zusätzlich zum Scrum Master wird auch ein (nicht genauer beschriebener) Coach erwähnt, der anscheinend zu dieser Zeit noch eine eigene Rolle war. Auch das 15-minütige Daily Scrum-Meeting taucht hier erstmals auf, genau wie das Commitment des Teams das Sprint-Ziel zu erreichen.

Das erste Buch über Scrum, gleichzeitig aber auch ein Werk das im Rückblick leicht wunderlich wirkt. Statt Scrum als eigenständigen Ansatz vorzustellen stellten Schwaber und Beedle in den Vordergrund, dass ein anderer methodischer Ansatz, Extreme Programming (XP), sich mit Hilfe von Scrum besonders gut umsetzen liesse. Hintergrund ist, dass XP um das Jahr 2000 herum populärer war als Scrum und die Verbindung dieser beiden Ansätze Scrum schneller bekannt machen konnte. Zusätzlich kannten und respektierten sich die Urheber von Scrum und XP (u.a. waren sie 2001 gemeinsam an der Enstehung des agilen Manifests beteiligt). Der halboffizielle Status einiger XP-Elemente in Scrum (User Stories, Story Points, Pair Programming) erklärt sich aus dieser Zeit.

In dieser Übersicht über die Scrum-Einführung in verschiedenen Unternehmen tauchen erstmals Skalierungs-Elemente auf. Zum Einen findet sich hier die Idee, dass auch Management-Teams nach Scrum arbeiten können, zum Anderen wird hier zum ersten mal das Scrum of Scrums vorgestellt, ein wöchentliches Scrum-Meeting in dem sich Vertreter verschiedener Teams treffen um sich untereinander abzustimmen und die Arbeit an übergreifenden Themen zu koordinieren. Aus diesen Ansätzen entstand später das Skalierungsframework Scrum@Scale (siehe unten).

Im Vergleich zu den anderen Texten ein eher wenig wichtiger, es wird nicht wirklich etwas Neues hinzugefügt. Interessant ist aber, dass Ken Schwaber in ihm einen weiteren Aspekt aus dem Extreme Programming aufgreift: den Team-Raum (angelehnt an den Extreme Space, in dem alle Teammitglieder zusammensitzen). Mittlerweile aus dem offiziellen Teil von Scrum verschwunden ist er noch immer ein wichtiger Teil in vielen Umsetzungen.

Ein weiterer Artikel von Ken Schwaber, der diesesmal aber grössere Änderungen beschreibt. Das Sprint Planning wird unterteilt in Planning I (was machen wir?) und Planning II (wie machen wir es?). Im Daily werden die drei Fragen gestellt was gestern gemacht wurde, was heute gemacht werden wird und wo Hindernisse aufgetreten sind. Erstmals findet am Ende des Sprints eine Retrospektive statt, die mittlerweile der zentrale Antrieb für den kontinuierlichen Verbesserungsprozess geworden ist und als das Scrum Meeting schlechthin gilt. Auch die später zum zentralen Abnahme-Kriterium gewordene Definition of Done wird hier erstmals erwähnt, allerdings noch eher beiläufig an verschiedenen Stellen im Fliesstext. Diese zentralen Änderungen tauchen dann auch 2004 in Schwabers Buch Agile Project Management with Scrum auf.

Ein Dokument das erst rückwirkend zum ersten Scrum Guide erklärt wurde, Sutherland und Schwaber veröffentlichten es zuerst unter dem schlichten Namen "Scrum". Es ist die letzte Version von Scrum in der sich Wasserfall-Elemente finden: zusätzlich zu den Sprint Plannings können langfristige "Release Plannings" durchgeführt werden und es gibt noch die Möglichkeit Integration und Testing in separate Sprints auszulagern. Auch die kontrovers benannten Rollen "Chicken" (Teammitglied) und "Pig" (Stakeholder) tauchen ein letztes mal auf. Positiv zu benennen ist, dass der Scrum Master als helfender und coachender "Servant Leader" beschrieben wird, was seitdem unverändert gilt. Mit der Festlegung, dass mehrere Teams ein gemeinsames Backlog haben können taucht ein weiterer Skalierungs-Aspekt auf.

Die letzten Wasserfall-Elemente verschwinden aus dem Scrum Guide, ausserdem alle spezifischen Bezüge zur Softwareentwicklung, womit Scrum auch auf andere Bereiche anwendbar wird. Auch die Pig- und Chicken-Rollen verschwinden. Das Grooming wird dagegen zu einem festen Bestandteil und die Rollen werden ausführlicher beschrieben als vorher. Im Wesentlichen entspricht diese Version von Scrum der die bis heute gültig ist, die späteren Änderungen sind kleiner.

Eher redaktionelle Bearbeitungen, nennenswerte inhaltliche Veränderungen finden nicht statt.

Es werden Neuerungen und Ergänzungen in verschiedenen Bereichen eingeführt: die Teammitglieder sollen sich in den Daily Scrums nicht mehr nur fragen was gestern gemacht wurde, was heute gemacht werden wird und wo Hindernisse aufgetreten sind, sondern auch welchen Einfluss das auf das Erreichen des Sprint-Ziels haben wird. Das (in manchen Ländern anstössige) Wort Grooming wird durch Refinement ersetzt. In diesem Zusammenhang wird es auch möglich Backlog-Einträgen den Status Ready zu geben, woraus die inoffizielle Definition of Ready abgeleitet werden kann. Die Teilung des Sprint Plannings in Planning I und Planning II wird aufgehoben, das Was und das Wie können jetzt beliebig erarbeitet werden. Eine kleinere Ergänzung kommt bei den Skalierungs-Aspekten dazu: mehrere Teams können eine gemeinsame Definition of Done haben.

Das erste offizielle Skalierungsframework von Scrum. Grundlage sind die beiden Skalierungs-Aspekte des Scrum Guide, die gemeinsame Definition of Done und das gemeinsame Backlog für Teams die an einem gemeinsamen Produkt arbeiten. Da gleichzeitig vorgegeben ist dass es nur einen Product Owner für ein Backlog geben darf wird daraus abgeleitet, dass der auch für alle derartigen Teams zuständig ist. Weitere Elemente sind die Aufteilung der Scrum-Meetings in jeweils einen übergreifenden und einen teamspezifischen Teil und die Möglichkeit ein Integration Team zu etablieren, dass den anderen Teams dabei hilft sich selbst zu koordinieren. Ein sehr ähnliches, halboffizielles Framework ist Large Scale Scrum (LeSS).

Die "Scrum-Werte" Respekt, Commitment, Fokus, Offenheit und Mut werden in den Scrum Guide aufgenommen. Das ist keine vollständige Neuerung, da sie bereits 2001 im Buch Agile Software Development with Scrum von Ken Schwaber und Mike Beedle enthalten waren. Ihre Wiedereinführung ist der bisher prominenteste Fall einer Scrum-Regeländerung die auf Wünsche aus der Anwender-Community zurückgeht.

Neben verschiedenen redaktionellen Änderungen gibt es drei grössere: die berühmten drei Fragen im Daily Scrum sind jetzt optional, der Scrum Master bewegt sich mehr Richtung Coach, da er nicht mehr für die Einhaltung der Scrum-Regeln sorgt sondern deren Verständnis fördert, und zuletzt muss in jeden Sprint mindestens eine Massnahme zur Verbesserung der eigenen Arbeitsweisen aufgenommen werden.

Eine vergleichsweise kontroverse Neuerung. Anders als der oben erwähnte Nexus-Ansatz geht Scrum@Scale davon aus, dass Scrum nur für einzelne Teams gedacht ist und nicht für grössere Organisationen. Skalierung funktioniert daher in diesem Modell nicht durch die Gruppierung von Teams um Backlogs und Product Owner sondern dadurch, dass es zwar übergeordnete Hierarchie-Ebenen gibt, diese sich aber auch in Form von Scrum Teams organisieren.

---

Honorable Mentions

Natürlich gibt es noch weitere Quellen die wertvoll für das Verständnis von Scrum sind, vor allem in Buchform. Von Schwaber und Sutherland sind das vor allem die ikonisch benannten Titel Software in 30 Days und The Art of Doing Twice The Work In Half the Time, es gibt Scrum and XP from the Trenches von Henrik Kniberg, Agile Product Management with Scrum von Roman Pichler, die Bücher von Mike Cohn, die Bücher von Craig Larman und Bas Vodde und viele mehr. Sie alle haben Scrum aber nicht verändert sondern beschreiben lediglich seine Anwendungsmöglichkeiten und vermitteln bewährte Techniken und Praktiken, weshalb sie keine Grundlagen-Dokumente im eigentlichen Sinn sind (lesenswert sind sie natürlich trotzdem).

Montag, 8. Juni 2020

Story Points in Kanban

FS
Bild: Freegreatpicture / Max Pixel - CC0 1.0
Wenn es darum geht Aufwands- oder Komplexitätsschätzungen zu machen raten die meisten in agilen Vorgehensweisen erfahrenen Entwickler zu Story Points, unter anderem wegen der Vorteile relationaler Schätzungen, aber auch aus anderen Gründen. Was dabei fast alle gemeinsam haben ist aber eine Einschränkung auf nur ein oder zwei Frameworks, nämlich Scrum und Extreme Programming. Eine Anwendung im Rahmen von Kanban (des dritten grossen agilen Ansatzes) wird von den meisten nicht erwogen. Dabei wäre sie auch hier durchaus möglich.

Ähnlich wie im Fall der iterativen Ansätze Scrum und XP ist ein Story Point auch in Kanban eine neutrale (d.h. personenunabhängige) Schätzgrösse, die je nachdem wer an der Anforderung arbeitet eine etwas schnellere oder langsamere Umsetzungsdauer bedeuten kann, aber trotzdem eine gemeinsame Schätzung des Teams ermöglicht. Was im Vergleich zur klassischen Anwendung dagegen anders ist, ist die Art des Einsatzes zu Planungs-, Forecast- oder Prognosezwecken.

In Scrum und XP dienen die in der Vergangenheit gelieferten Story Points als Grundlage für die Velocity, also die durchschnittliche Menge an Arbeit die das Team bisher pro Sprint oder Iteration erledigen konnte1. Diese ist dann wiederum ein Indikator dafür was voraussichtlich in zukünftigen Sprints fertiggestellt werden kann. Da in Kanban an die Stelle der festen Lieferzyklen eine beständige Lieferung tritt ist diese Art der Prognose hier nicht möglich, es wird anders vorgegangen.

Was stattdessen passiert ist eine Einteilung der Anforderungen in Äquivalenzklassen, deren durchschnittliche Lead- oder Cycle-Time gemessen wird. Wenn z.B. in der Vergangenheit Anforderungen mit 5 Punkten im Durchschnitt 4 Tage gebraucht haben, dann kann angenommen werden, dass das in Zukunft vergleichbar sein wird. Allerdings - ist das nicht doch wieder eine Schätzung in Zeiteinheiten? Ja, schon, wenn man es dabei belässt. Aber es steckt noch mehr dahinter.

Bedingt durch verschiedene Unsicherheitsfaktoren (Erfahrung des Bearbeiters, Neuartigkeit des Themas, etc.) kommt es normalerweise bei einem Teil der umgesetzten Anforderungen zu Abweichungen nach oben und unten, meistens in Form einer Gauss-Kurve. Das kann z.B. heissen, dass etwa 20 % der Fälle früher als gedacht fertig werden, etwa 60 % ungefähr rechtzeitig2 und etwa 20 % später als gedacht. Diese Zahlen ermöglichen eine Ausdifferenzierung der Prognose.

Beim oben genannten Beispiel von 5 Punkten könnte dass etwa bedeuten3, dass man eine praktisch sichere Ablieferung nach 6 Tagen zusichern kann, eine sehr wahrscheinliche nach 4 Tagen und eine unwahrscheinliche aber theoretisch mögliche nach 2 Tagen. Für die abnehmende Einheit ergibt sich dadurch die Möglichkeit verschiedener Planungsvarianten um flexibel reagieren zu können, mit verbesserter Anpassungsfähigkeit über verschiedene Stationen der Lieferkette als Folge.

Man muss sich bewusst sein: diese Art der Business Agility erfordert Arbeit und Disziplin beim Erheben und Auswerten der Statistiken, man sollte sich also fragen welcher Mehrwert so entstehen soll und ob er in erträglicher Relation zu den Aufwänden steht. Wenn man das mit Ja beantworten kann steht dem Einsatz von Story Points in Kanban aber nichts mehr im Weg.



1Nur zur Klarstellung: man kann in Scrum und XP Story Points benutzen, muss es aber nicht
2Auch hier gibt es noch kleinere Abweichung in einigen Fällen
3Abhängig vom Umfang der Abweichungen

Freitag, 5. Juni 2020

Der "Gesellschaftsvertrag" als Grundlage der Selbstorganisation in Unternehmen

FS

Bild: Wikimedia Commons / Peter Bircks - Public Domain
Es ist mal wieder Zeit für ein bisschen Meta-Betrachtung, diesesmal mit einem Exkurs in Richtung eines soziologischen Konstruktes, das sich auch auf autonom arbeitende Teams anwenden lässt. Die Rede ist von der Vertragstheorie, hinter der sich die Vorstellung verbirgt, dass alle nicht erzwungenen Zusammenschlüsse von Menschen auf gegenseitigen Übereinkünften beruhen, entweder in Form schriftlicher Dokumente oder in Form stillschweigender Annahmen und Zustimmungen - häufig auf einer Mischform aus beidem. Am häufigsten wird die Vertragstheorie zwar in Staatsrecht und Politkwissenschaft angewandt (das bekannteste Beispiel ist der Gesellschaftsvertrag von Rousseau), eine Übertragung auf andere Bereiche ist aber möglich.

Einer bei dem sich das im Wortsinn anbietet sind wirtschaftlich tätige Unternehmen. Das G in OHGs, GmbHs, AGs und UGs steht schliesslich für Gesellschaften, und selbst wenn es für den Gesellschaftsvertrag schon eine juristische Bedeutung gibt, so ist die andere, implizite auch immer vorhanden. Gerade in einem Selbstorganisations-Kontext ist sie sogar von essentieller Bedeutung. Warum das so ist erschliesst sich bei einem Blick auf die drei wichtigsten dieser informellen Übereinkünfte, die zwar praktisch nirgendwo so festgehalten werden, aber fast überall die unausgesprochene Grundlage für eine Zusammenarbeit auf Augenhöhe bilden:

1. Wir, das Management, geben unseren Mitarbeitern das Recht sich selbst zu organisieren und wir, die Mitarbeiter, werden diese Freiheit nicht nutzen um gegen die Interessen der Firma zu arbeiten

Wer den Übergang von klassischer Unternehmensführung zu Scrum, Kanban, o.ä. schon einmal miterlebt hat kennt die Ängste des Managements. Werden selbstorganisierte Teams überhaupt noch ernsthaft arbeiten und wenn ja woran? Und was ist wenn das was die machen wollen überhaupt nicht zielführend ist? Diese Sorgen muss man ernstnehmen wenn man das Einverständnis der Managementebene zur agilen Transformation haben möchte. Dann ist aber auch viel möglich: sobald allen Beteiligten klar ist, dass es sich dabei um keinen grenzenlosen Freifahrtschein handelt sondern es auch Grenzen der Selbstorganisation geben muss sinkt die Hemmschwelle das zuzulassen deutlich. Und umgekehrt ist so auch jedem Mitarbeiter vermittelbar, dass Selbstbestimmung nicht in der Firmen-Insolvenz oder dem Bruch von Verträgen enden kann sondern schon vorher aufhört.

2. Wir, die Mitarbeiter, gewähren einen offenen Einblick in alle Arbeit die wir tun und wir, das Management, werden diese Transparenz nicht für Micro-Controlling und Micro-Management ausnutzen

Auch die Ängste von der Mitarbeiterseite gibt es. Wenn wir jeden einzelnen Tag zeigen womit wir gerade beschäftigt sind, wird dann nicht die Versuchung für "die Chefs" übermächtig, von oben auf Detailebene hineinzuregieren und "die Auslastung zu optimieren"? Endet das nicht in permanentem Rechtfertigungszwang für jeden Fehler und jeden Moment der Untätigkeit? Auch das muss ernst genommen werden, gerade vor dem Hintergrund, dass es in der Vergangenheit schon zu derartigen Kontroll- und Detailsteuerungs-Versuchen gekommen ist. Die Wahrheit ist aber auch, dass das in fast allen Fällen eher zu Selbstlähmung als zu Hochleistung geführt hat, was den meisten Managern auch bewusst ist, und weshalb sie Derartiges auch nicht anstreben. Wenn sie das glaubwürdig vermitteln können verliert die Transparenz ihren Schrecken.

3. Wir, Management und Mitarbeiter, sind uns bewusst, dass die verschiedenen Teile unseres Gesellschaftsvertrages sich gegenseitig bedingen und dass die Aufkündigung eines Teils immer auch den Rest ungültig macht

Man muss sich nichts vormachen, die Versuchung ist gross, denjenigen Teil der gegenseitigen Abmachung der einen selbst bindet zeitweise aufheben zu wollen "wenn es dringend ist" oder "wenn es ein wichtiges Thema ist". Das ist menschlich, es ist aber nicht folgenlos. Ein sich betrogen fühlendes Management wird sofort Teile der Selbstorganisation abschaffen und eine sich ausgenutzt fühlende Belegschaft wird Transparenz fortan nur noch simulieren statt sie wirklich zu bieten. Und da alle sozialen Gruppen über ein kollektives Gedächtnis verfügen darf auch niemand darauf hoffen, dass solche "Ausrutscher" in Vergessenheit geraten. Vertrauen ist sehr schnell verspielt und lässt sich dann nur sehr schwer wieder herstellen.

Wie oben gesagt, ausformuliert und aufgeschrieben findet man diesen Vertrag in praktisch keiner OHG, GmbH, AG oder UG, dort wo selbstorganisierte Teams samt der damit verbundenen Vorteile (Flexibilität, Bürokratieabbau, etc.) Zielbild der Organisation sind wird er aber immer implizit in den Köpfen der Menschen vorhanden sein. Vermutlich wäre es eine spannende Idee daraus etwas Explizites zu machen, eben durch Ausformulieren und Aufschreiben. Sichtbar auf eine Wand geschrieben dürfte es jedenfalls deutlich wirksamer sein als alle "Firmenwerte" und "-missionen" zusammen.

Dienstag, 2. Juni 2020

Eine kleine Typologie der Software-Architekten

FS

Ein guter Vortrag, und das aus mehreren Gründen: zum einen hilft er dabei "den Software-Architekten, das unbekannte Wesen" besser zu verstehen, zum anderen wegen der Parallelen zu anderen Berufen. Ggf. bietet sich irgendwann man eine kleine Typologie der Scrum Master und Agile Coaches an.

Sonntag, 31. Mai 2020

Kommentierte Links (LXII)

FS
  • Cal Newport: Why Remote Work Is So Hard - and How It Can Be Fixed

  • Ein Longread aus dem New Yorker für den man sich Zeit nehmen sollte. Basierend auf zahlreichen Quellen und verwoben mit Exkursen in die Technologie- und Wirtschaftsgeschichte breitet Cal Newport ein differenziertes Bild der Heimarbeit aus. Was ihre Vorläufer waren, wie sie entstanden ist, wie sie zurückgedrängt wurde und wie sie durch die Corona-Pandemie einen erneuten Schub erhalten hat wird hier nacherzählt, es geht aber auch um das grosse Dilemma das diese Arbeitsform schon immer umgibt: sie gibt den Angestellten (unter gewissen Voraussetzungen) eine bessere Work Life-Balance, führt aber auch zu einem spürbaren Rückgang von Effektivität, Effizienz und sozialem Zusammenhalt. Interessant ist dabei vor allem eine These: Newport ist der Überzeugung, dass der agil arbeitende Teil der Software-Industrie der einzige Sektor der Wirtschaft ist, der es geschafft hat die negativen Aspekte der Heimarbeit spürbar abzuschwächen. Dass trotzdem auch andere Branchen darüber nachdenken ihre Mitarbeiter dauerhaft zu Hause arbeiten zu lassen hat einen Grund der im New Yorker zu kurz etwas kommt, dafür aber von der New York Times und Vanity Fair aufgegriffen wird: viele Büros sind heute arbeitsfeindliche Umgebungen. Nochmal eine Geschichte für sich.

  • Matt Philip: NoEstimates, Applied

    Es kann natürlich täuschen und der individuellen Filterblase geschuldet sein, gefühlt ist es aber in den letzten Jahren um das Thema NoEstimates ruhiger geworden (vielleicht wegen des aus Marketing-Gesichtspunkten eher unglücklich gewählten Namens?). Dass die dahinterstehende Bewegung noch immer da ist zeigt dieser Beitrag von Matt Phillip, in dem er erklärt wie er sich mit diesem Ansatz an einer grösseren Ausschreibung beteiligen würde. Wer sich mit dem Thema bereits näher beschäftigt hat wird seinen Ausführungen nur zustimmen können, wer grosse Organisationen kennt wird aber auch wissen, dass er es sehr schwer haben dürfte mit diesem Vorgehen erfolgreich zu sein. Es wäre sicher hochgradig spannend einen solchen "Sales Pitch" einmal mitzuerleben.

  • Roman Pichler: Six Types of “Product” Owners

    Wer die Arbeit von Roman Pichler verfolgt wird wissen, dass er schon seit längerem versucht die Rollen im Produktmanagement auszudifferenzieren. In der Vergangenheit führte das unter anderem zur Gegenüberstellung von Product Manager und Product Owner und zur Entwicklung des Balanced Product Leaders, mit diesem Artikel kommt die Aufschlüsselung des Product Owners auf die sechs Typen Scrum Product Owner, Feature Owner, Component Owner, Platform Owner, SAFe Product Owner und Portfolio Owner dazu. Für jeden der eine PO-Rolle innehat sollte es interessant sein sein Stellenprofil mit diesen Typen abzugleichen. Was ebenfalls kurz angesprochen wird ist die Auswirkung des Scrum-Schismas auf die Product Owner-Rolle, hier besonders durch die stark voneinander abweichende Ausgestaltung im klassischen Scrum und in SAFe.

  • Willem-Jan Ageling: SAFe Scrum Master vs ‘Scrum’ Scrum Master

    Apropos Scrum-Schisma zwischen klassischen Scrum und SAFe - auch Willem-Jan Ageling nimmt sich dieses Themas an, allerdings mit Focus auf der anderen herausragenden Rolle, dem Scrum Master. Ähnlich wie Pichler arbeitet auch er heraus, dass die beiden Ausprägungen sich zwar auf den ersten Blick ähneln mögen, sich bei genauerer Betrachtung aber deutlich unterscheiden. Was den grossen Unterschied zur PO-Rolle ausmacht ist, dass der Scrum Master in viel intensiverer Weise in der namensgebenden Methodik verankert ist. Da diese aber in SAFe je nach Sichtweise abgeschwächt oder optional ist kann es zur paradoxen Situation kommen, dass ein nicht nach Scrum arbeitendes Team einen Scrum Master hat. Dass das sogar eine offiziell mögliche Variante ist zeigt, wie weitreichend die Veränderungen sind die hier vorgenommen wurden. [Nachtrag 02.06.: Es gibt eine Erwiderung von Paddy Corry]

  • Todd Lankford: If Your Scrum Is Not Fun, You Are Doing It Wrong

    Eine Wahrheit die man gar nicht oft genug aussprechen kann. (Richtig umgesetztes) Scrum liefert Entwicklungsteams Vieles was sie sich schon immer gewünscht haben: die Möglichkeit unrealistische Arbeitslasten abzuwehren, einen unmittelbaren Wertschöpfungsbeitrag, Kontakt und Austausch mit dem Anwender, die Erlaubnis systemische Dysfuntionen der Organisation anzusprechen und zu beheben, und das auch noch in einer ansprechenden Verpackung. Fast immer führt das dazu, dass die Freude an der Arbeit spürbar steigt. Der Zusammenhang ist sogar so offensichtlich, dass man Todd Lankfords Aussage wörtlich nehmen kann - wenn die Arbeit mit Scrum keinen Spass macht ist das Framework mit zimlicher Sicherheit falsch implementiert worden.

Powered by Blogger.