Samstag, 31. Juli 2021

Kommentierte Links (LXXVII)

Grafik: Pixabay / The Digital Artist - CC0 1.0
Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Shishir Mehrotra: Rituals for hypergrowth - An inside look at how Youtube scaled

Dass viele grosse Firmen mit der Zeit ihre eigenen agilen Frameworks entwickeln (und mit der Zeit weiterentwickeln oder verwerfen) ist eine verhältnismässig unbekannte Tatsache, lediglich das (oft missverstandene) Spotify Model hat eine gewisse Berühmtheit erlangt, die anderen sind wenig bekannt. Um so interessanter ist das was Shishir Mehrotra hier vorstellt: es ist das Vorgehensmodell das bei Youtube nach der Übernahme durch Google entwickelt wurde. Erkennbar sind hier andere Frameworks integriert worden, wie z.B. OKRs und Teile von Scrum, vieles ist aber offensichtlich selbst entworfen worden und dürfte in dieser Form sicher einzigartig sein. Wie in anderen derartigen Fällen kann man auch hier nur davon abraten dieses Modell kopieren zu wollen, einige Elemente (wie z.B. das Verbot kurzfristig einberufener Meetings) sind so kontextspezifisch, dass sie an anderen Stellen eher Schaden als Nutzen anrichten würden. Eine faszinierende Fallstudie ist es aber auf jeden Fall.

Tom Rusell: Planning & estimating large-scale software projects

Den wichtigsten Satz über die Aufwandsschätzungen nicht nur in grossen sondern in allen komplexen Projekten hat Tom Rusell fast versteckt in den Untertitel einer Absatz-Überschrift geschrieben: "You must always involve those who will actually do the work". Alleine damit würde er einem Grossteil der derartigen Vorhaben schon weiterhelfen, er geht aber noch darüber hinaus und liefert eine ganze Reihe sinnvoller Anleitungen und Ideen. Das meiste davon erscheint wenn man es liest eher naheliegend als revolutionär, man muss sich allerdings bewusst machen, dass dieser Schein trügt - in vielen grossen Organisationen werden diese Praktiken eher simuliert als angewandt.
Übrigens - um zu zeigen, dass dieser Ansatz zwar funktionieren kann, er aber auch er keineswegs der einzige oder beste ist, ist hier eine völlig andersartige Fallstudie: No Estimates at Scale in the US Federal Government.

Jason Yip: Concepts I use every day - BAPO

Hinter der Abkürzung BAPO stehen die Begriffe Business, Architecture, Process und Organisation, sinngemäss übersetzbar mit Geschäftszielen, IT-Architektur, Arbeitsabläufen und Organisationsstruktur. Dass Jason Yip geht davon aus, dass diese Teilsysteme in dieser Reihenfolge geändert werden müssen wenn die Umstrukturierung einer Organisation wirklichen Erfolg haben soll. Den häufiger anzutreffenden Ansatz direkt von den Geschäftszielen zur Änderung der Organisationsstruktur überzugehen hält er für weniger sinnvoll, da dieses Vorgehen dazu führt, dass die neue Ablauforganisation nicht mehr mit den IT-Systemen kompatibel ist, da diese ja auf die alte Struktur optimiert wurden (Conway's Law). Als jemand der sowohl gelungene als auch misslungene Transformationsversuche miterlebt hat kann ich dem nur aus voller Überzeugung zustimmen.

Jeff Patton: The Mindset That Kills Product Thinking

Wieder mal ein bisschen Meta-Content. Jeff Patton reagiert mit diesem Artikel auf zwei weitere Artikel (hier und hier) die etwas früher von Marty Cagan geschrieben worden. Die Synthese in die er die beiden Inhalte mit seinem seit einiger Zeit vorgetragenen Zweifel an der agilen Produktentwicklung (des Jahres 2001) zusammenführt ergibt eine umfassende Kritik daran, dass die Software-Industrie im speziellen, aber auch der Markt und die Menschheit im Allgemeinen zu stark auf Output focussiert sind und zu wenig auf Outcome. Das ist zwar weder neu noch unstrittig, es ist aber anschaulich beschrieben und pointiert präsentiert, so dass es einen guten Anstoss für Diskussionen bietet. Denn selbst wenn man nicht in jedem Aspekt mit ihm übereinstimmt - er weist hier definitiv auf ein Thema hin über das man nachdenken sollte.

Daniel Lebrero: Lucky Lotto, chaos engineering but for teams

Für alle Fans resilienter Organisationen und für Anhänger des Chaos Engineering hat Danieö Lebrero eine Idee die man sofort bei sich selbst ausprobieren kann: Jeden Montag wird ein Mitarbeiter ausgelost das seinem Team in der nächsten Woche nur in absoluten Ausnahmefällen zur Verfügung steht und sonst ausschliesslich an einem kleinen Sonderprojekt arbeitet. Der angestebte Effekt ist eine höhere Ausfallsicherheit und Crossfunktionalität, entweder dadurch dass die Teams sich auf mögliche Ausfälle vorbereiten oder dadurch, dass der Ausfall eintritt und die verbleibenden Kollegen jetzt auch die Tätigkeiten übernehmen müssen die bisher immer der jetzt abwesende Spezialist übernommen hat. Die Spannung bei der Verlosung gibt es gratis dazu.

Dienstag, 27. Juli 2021

Denn sie wissen nicht, wen sie rekrutieren (V)

Bild: Jeshoots / Jan Vašek - CC0 1.0

Eines vorweg: die meisten Menschen in den Einkaufs-, HR- und PMO-Abteilungen machen einen guten Job, sind intelligent, fleissig und produzieren gute Ergebnisse. Wer häufiger Stellenangebote oder Projektanfragen bekommt kennt allerdings auch die andere Seite - regelmässig kommen Ausschreibungen herein aus denen sehr offensichtlich hervorgeht, dass der Verfasser wenig bis gar nicht mit dem Thema vertraut ist. Und in den Anrufen die diesen Mails häufig folgen wird dieser Eindruck meistens bestätigt.


Erst vor kurzem ist eine weitere dieser Anfragen bei mir eingegangen, die in einem derartigen Ausmass beispielhaft für diese Missstände ist, dass ich sie hier etwas genauer betrachten möchte. Einsatzort, Einsatzdauer und andere Informationen die darauf hindeuten könnten wer dahintersteckt sind weggelassen, abgesehen davon ist sie in genau dieser Form über einen der üblichen Dienstleister versendet worden. Hier ist sie:


Coach Tribe Lead (m/w/d) | Freiberuflich für ein Projekt


Meine Aufgaben

Sparring zur inhaltlichen Ausrichtung des Tribes 

Sparring zum Führungsverständnis und zur Ausrichtung der Führung 

Vorbereitung von Tribe-internen Formaten

Durchführung Tribe-interner Formate 

Begleitung des Tribe-Agile Coaches 


Meine Qualifikationen

Projekterfahrung im Coaching Umfeld

Sehr gute Kenntnisse mit Tribe


Meine Vorteile

Abwechslungsreiche Tätigkeit in einem renommierten Unternehmen

Aussicht auf Folgeprojekte

Betreuung im laufenden Projekt durch unser Team


Puh. Das Einzige was man aufgrund dieser Punkte über die hier beschriebene Einheit sagen kann ist, dass hier anscheinend angelehnt an das Spotify Model gearbeitet wird (was gut oder schlecht sein kann, man weiss es nicht). Was genau dieser Tribe tut geht aus dem Text nicht hervor, auch nicht wie gross er ist, wie er intern strukturiert ist, in welche grösseren Kontexte er eingebettet ist oder was seine im Moment wichtigen Herausforderungen und Ziele sind.


Auch in Bezug auf die zu besetzende Stelle wird man nicht so richtig schlau. Der "Coach Tribe Lead" ist nach allem was bekannt ist nichts was bei Spotify jemals existiert hätte, es scheint also eine Neuerfindung zu sein. Alleine aufgrund des Titels ist aber zu befürchten, dass hier versehentlich ein Intra-Rollen-Konflikt eingebaut wurde, da anscheinend eine Führungsrolle (der Tribe Lead) und eine Coach-Rolle zusammengeworfen wurden.


Die Beschreibung der auszufüllenden Tätigkeiten hilft ebenfalls nur bedingt weiter. "Sparring zur inhaltlichen Ausrichtung", Sparring zum Führungsverständnis" sowie "Vorbereitung und Durchführung interner Formate" können alles und nichts bedeuten, zumindest drängt sich aber auch hier der Verdacht auf, dass nicht Zusamenpassendes zusammengeworfen wurde. Die ersten Punkte deuten auf Coaching hin, die beiden anderen eher auf einen Projektmanager.


Ins Absurde kippt das Ganze dann bei den geforderten Qualifikationen. "Sehr gute Kenntnisse mit Tribe" kann man eigentlich nur so verstehen, dass der Verfasser "Tribe" für eine Methode oder eine Programmiersprache hält. Für jeden dem auch nur in Ansätzen klar ist, dass es sich dabei um eine Organisationseinheit handelt ergibt dieser Satz keinen Sinn (bzw. genau so wenig Sinn wie die inhaltlich vergleichbare Anforderung "Sehr gute Kenntnisse mit Abteilung").


Das Tragische an dieser Ausschreibung: vielleicht verbirgt sich dahinter sogar ein spannnder Job, der bei einer verständlichen Beschreibung die richtigen Leute angelockt hätte. Wissen kann man es aber nicht, denn selbst die Projektvermittlerin, die kurz nach dem Versenden der Mail anrief, kannte auch nur die Informationen die dort aufgeschrieben waren. In dieser Form sorgt der Text bei der Zielgruppe aber eher für Amüsement als für Interesse.


Warum er trotzdem in dieser Form herausgeschickt wurde kann man natürlich nur raten, ausgehend von ähnlichen Situationen die ich bereits miterleben durfte würde ich aber auf eine Kombination aus einer stark ausgeprägten Silo-Struktur und einer möglichst hohen Auslastung der einzelnen Mitarbeiter tippen. Das erste verhindert, das die Einheit in der der Einsatz stattfinden soll Einfluss auf die Ausschreibung nehmen kann, das zweite verhindert, dass der ausführende Einkauf Zeit für Sinnfragen hat.


Ironischerweise wäre genau das einer der Missstände die ein Agile Coach oder Business Coach thematisieren würde - wenn das für ihn vorgesehene Stellenprofil nicht so verquer formuliert wäre, dass sich vermutlich niemand findet der die Position einnimmt.

Donnerstag, 22. Juli 2021

5S

Bild: Pixabay / Blickpixel - CC0 1.0

Zur Zeit darf ich mal wieder für einen Kunden tätig sein der nicht nur Software herstellt sondern auch die dazugehörige Hardware. Das was derartige Einsätze aus methodischer Sicht spannend macht ist, dass in ihnen häufig zwei verschiedene Optimierungsansätze aufeinandertreffen: die aus der (agilen) Produktentwicklung kommende Effektivitätsoptimierung und die aus der Fabrikation kommende Effizienzoptimierung.


Eine zum zweiten Ansatz gehörende Methode trägt den schlichten Namen 5S. Sie kommt aus dem erweiterten Umfeld von Lean Management und ist darum interessant, weil sie zwar in der Hardware-Fertigung erfunden wurde, sich aber bei leichter Neuinterpretation auch in der Softwareentwicklung einsetzen lässt, und zwar nicht anstelle der hier gängigen methodischen Frameworks wie Extreme Programming, Scrum, etc. sondern in Kombination mit ihnen.


Zunächst zum grundlegenden Verständnis: 5S ist in Japan entstanden als traditionelle Prinzipien des Ordnung Haltens aus Haushalt und Küche in die Industrie übertragen wurden. Dabei wurden fünf von ihnen als besonders zentral und wichtig erkannt, und da sie alle mit dem Buchstaben S beginnen erhielt die Methode so ihren Namen: es sind Seiri (整理), Seiton (整頓), Seisō (清掃), Seiketsu (清潔) und Shitsuke (躾), bzw. deren Übersetzungen, für die man auch versucht mit S beginnende Begriffe zu finden.


Grafik: Wikimedia Commons / Nikita Klyuchko - CC BY-SA 3.0


Seiri (Sort out/Selektieren)

Ständiges Aussortieren und Entfernen unbrauchbarer oder unnötiger Rohstoffe und Komponenten, um im Arbeitsalltag ausschliesslich mit hochwertigen Materialien arbeiten zu können. Im der Hardware-Fertigung ursprünglich auf minderwertige Werkstoffe und defekte Bauteile bezogen, in der Software etwa anwendbar auf nicht mehr benötigte Branches oder obsolete Schritte in Skripten.


Seiton (Set in Order/Sortieren)

Sortiertes Anordnen und gut sichtbares Bereithalten aller Arbeitswerkzeuge. Klassische Hardware-Beispiele wären nach Länge und Durchmesser sortierte Schraubenschlüssel oder Schraubenzieher an der Wand oder im Werkzeugkasten, in der Softwareentwicklung könnte es das gut geordnete Product Backlog sein oder die Übersichtsseite mit Links zu allen Entwicklungs-, Test- und Staging-Umgebungen.


Seisō (Shine/Sauberkeit)

Regelmässiges Säubern und Sauberhalten des Arbeitsplatzes. In der Fabrik kann das die Entfernung von Staub, Spänen und allem anderen sein, was zum sprichwörtlichen Sand im Getriebe werden könnte, in der Software wäre eine Entsprechung das Löschen von auskommentiertem Code oder von veralteten und kontaminierten Testdaten.


Seiketsu (Standardize/Standardisieren)

Übertragen bewährter Vorgehensweisen auf vergleichbare Anwendungsfälle. An dieser Stelle sind Sinn und Effekt in Hardware- und Softwareentwicklung die Gleichen. Die Verwendung gleicher Abläufe, wiedererkennbarer Visualisierungen und identischer Begriffe ermöglichen ein schnelles Zurechtfinden und arbeitsfähig werden in neuen Umgebungen.


Shitsuke (Sustain/Selbstverständlich machen)

Verinnerlichung der ersten 4 S, so dass sie zu einem selbstverständlichen Teil der Arbeit werden. Das Ziel ist es, durch tägliche Übung die Anwendung in eine Habitualisierung zu überführen, so dass sie auch ohne Anleitung und Erinnert Werden stattfinden. Ein häufig verwendetes Hilfsmittel sind visuelle Erinnerungsstützen wie z.B. Kamishibai-Boards.


Soweit die schnelle Übersicht, weitere Anwendungsfälle wird sich jeder herleiten können der in der professionellen Softwareentwicklung arbeitet. Der Vollständigkeit halber sei auch erwähnt, dass 5S zwar die häufigste, aber nicht die einzig mögliche Mengengrösse dieser Methode ist. Es gibt auch 4S (meistens ohne Shitsuke), 6S (häufig mit Safety/Sicherheit als sechstem Element) und in manchen Firmen auch noch höhere, je nach Fall anders belegte Nummern.


Für Software-Teams ist 5S vor allem dann zu empfehlen, wenn sie das Gefühl haben, dass bei ihnen die schnelle Liefer- und Reaktionsfähigkeit zu sehr auf Kosten von Ordnung und Übersichtlichkeit herbeigeführt wurde. Die Methode für einige Sprints einzuführen und bei eintretenden Verbesserungen dauerhaft beizubehalten kann in solchen Fällen ein sinnvoller Weg sein. 


Als scheinbar kleiner, in seinen Auswirkungen nicht zu unterschätzender Nebeneffekt kommt noch dazu, dass man plötzlich ungeahnte Gemeinsamkeiten mit den Kollegen aus der Hardware-Fertigung entdecken kann, wodurch gegenseitiges Verständnis und Zusammengehörigkeitsgefühl in der Firma gefördert werden. Vielleicht kommt es dann dadurch zu einem weiteren Austausch, aus dem sich die Idee ergibt welche weitere Arbeitsmethode der anderen Seite man sich näher ansehen sollte.

Montag, 19. Juli 2021

Doch wie Spotify werden

 

Bild: Wikimedia Commons / Florian Koppe - CC BY-SA 4.0

Wirft man einen Blick auf die Versuche grosser Organisationen sich agil zu organisieren, wird man mit grosser Wahrscheinlichkeit schon nach kurzer Zeit auf das so genannte "Spotify Model" stossen (das hier näher erklärt wird). 2012 eher zufällig in dieser Firma eintwickelt (und mittlerweile in der Ursprungsform dort gar nicht mehr im Einsatz) scheint es in vielen Konzernen einen Nerv getroffen zu haben. ING, Axa, Commerzbank, Telekom und viele mehr versuchen es bei sich umzusetzen.


Dass sich diese Change-Programme in der Realität schwierig gestalten (Beteiligte berichten unter der Hand von z.T. sehr durchwachsenen Ergebnissen) liegt natürlich zum einen daran, dass derartige Vorhaben immer schwer sind, zum anderen aber auch daran, dass der Ansatz mittlerweile aus verschiedenen Richtungen sehr stark politisiert und dogmatisiert wird, wodurch eine unbefangene Beschäftigung mit ihm immer schwerer wird.


Zum einen sieht diese Dogmatisierung so aus, dass versucht wird das Spotify Model unreflektiert als Blaupause für alle agilen Skalierungsvorhaben einzusetzen (warum das ein Problem ist kann man hier nachlesen), zum anderen hat sich als Gegenreaktion darauf unter vielen Scrum Mastern und Agile Coaches eine so reflexhafte und ebenso unreflektierte Ablehnung verbreitet, dass auf den Begriff ähnlich hysterisch reagiert wird wie in im Film Life of Brian auf das Wort Jehova.


In beiden Fällen bleibt eine wirkliche Beschäftigung mit dem Modell auf der Strecke. Das ist vor allem deshalb schade, weil viele seiner Elemente gute Lösungsansätze für real existierende Probleme bieten, so dass es sehr wohl Sinn machen kann einige oder sogar alle von ihnen bei sich einzuführen - immer unter der Voraussetzung, dass man diese Probleme wirklich hat, und dass regelmässig überprüft wird ob sie sich wirklich so lösen lassen.


Beispielsweise kann das Konstrukt eines Tribes, also einer Gruppe von Teams die aufeinander abgestimmt an einem gemeinsamen Produkt arbeiten, eine grosse Hilfe sein wenn die einzelnen Teams (noch) nicht oder nur zu langsam in der Lage sind dieses Produkt alleine weiterzuentwickeln. Ebenfalls nicht zu unterschätzen ist die Aussenwahrnehmung, in der ein Tribe deutlich sichtbarer und ansprechbarer erscheint als eine Ansammlung von für Teilprodukte zuständigen Einzelteams.


Auch die in den Tribes vorhandenen Chapter (Querschnittsorganisationen für gleichartige Spezialisten) können einen Mehrwert bieten. Zum Einen wegen ihrer Koordinations- und Abstimmungsfunktion, zum Anderen wegen der Beschränkung der "Chapter Lead"-Rolle auf eine Teilzeitstelle, die von einem Mitglied neben der Entwickler-Tätigkeit übernommen wird. Die bei Team- und Gruppenleitern sonst häufige Entfremdung von der Arbeit der Teams kann so gar nicht erst entstehen.


Ebenfalls hilfreich können die Gilden sein, der dritte Skalierungs-Aspekt des Spotify Models. Von Bedeutung ist hierbei, dass sie explizit keine Koordinationsfunktion haben (für die es ja bereits die Chapter gibt) sondern dass sie lediglich gemeinsame Interessen zum Gegenstand haben. Bedingt dadurch entfällt die Notwendigkeit für Führungsrollen, Regeln, Dokumentationspflichten und ähnliche Bürokratie-anfälligen Elemente, so dass der Fokus ganz auf Wissensaustausch und Erkenntnisgewinn liegen kann.


Um es noch einmal klar zu sagen: jeder der das Spotify Model bei sich einführen will sollte vorher überprüfen ob die Probleme für deren Lösung es entwickelt wurde in der eigenen Organisation vorhanden sind (und nicht bereits anders gelöst werden), nur dann macht die Einführung Sinn. Wenn diese Voraussetzung gegeben ist, ist dieser Weg aber eine brauchbare (wenn auch regelmässig zu validierende) Vorgehensweise.


Und sollte diese Entscheidung doch wie Spotify werden zu wollen dazu führen, dass der Scrum Master oder Agile Coach laut Jehova, Jehova! schreit - dann weiss man wenigstens wen man fragen kann ob er Interesse an einem Gespräch über Offenheit und Growth Mindset hat.

Donnerstag, 15. Juli 2021

Agilität und Sorgfalt

Der aktuelle Sturm im Wasserglas betrifft ein Gremium von dem die meisten noch nie gehört haben dürften, den Beirat „Junge Digitale Wirtschaft“, des Bundeswirtschaftsministeriums. Diese aus den Vertretern deutscher Startups zusammengesetzte Beratergruppe veröffentlichte im April ein Positionspapier, das die Regierung zur "Disziplinierung" der Medien aufrief, also de facto zu Zensur und Eingriffe in die Redaktionsfreiheit (siehe oben) und damit zur Verletzung des Grundgesetzes.


Nach einem Bericht des Handelsblatts ruderten alle Beteiligten zurück und wollten nichts von diesem Text gewusst oder ihn nicht so gemeint haben. Bemerkenswert ist dabei die in der FAZ abgegebene Begründung dafür, dass er trotzdem veröffentlicht wurde - das alles hätte nur passieren können weil der Beirat seit kurzem agil arbeiten würde. Dadurch sei es nicht mehr möglich gewesen eine gründliche Qualitätssicherung zu machen und nur deshalb sei es zur Veröffentlichung gekommen.


Durch die Umstellung auf eine agilere Arbeitsweise haben sich die Entscheidungs-Prozesse innerhalb des Beirats in den vergangenen Monaten stark verändert. Wichtige Checks-and-Balances-Vorgänge, die für eine solche Arbeit fundamental sind, haben in diesem Moment nicht ausreichend stattgefunden.
Aus der Stellungnahme des Beirats „Junge Digitale Wirtschaft“


Nun ja. Sollte das nicht der verzweifelte Versuch sein eine Ausrede zu erfinden müsste man den Verfassern konstatieren zur Agilität ein ähnlich gestörtes Verhältnis zu haben wie zur Pressefreiheit, denn das was sie hier behaupten entspricht eben nicht dem Anspruch der agilen Produktentwicklung. Es geht in ihr nicht darum schlampig und unsorgfältig zu arbeiten um schneller fertig zu werden, sondern darum, dass alle notwendigen Qualitätskriterien so schnell wie möglich erreicht werden (siehe auch hier).


Am Beispiel des misslungenen Positionspapiers lässt sich gut aufzuzeigen wie ein gleichzeitig agiler und sorgfältiger Prozess aussehen könnte. In einem ersten Schritt könnte man den Text in seine noch zu schreibenden Abschnitte unterteilen, in diesem Fall Beseitigung von Überregulierung, Reduzierung der Anforderungen an Börsengänge, Gewährleistung ausgewogener Berichterstattung, etc, die dann durch eine erste Qualitätssicherung gehen. Bestenfalls würde der Zensur-Teil schon hier gestrichen.


Sollte er an dieser Stelle noch durchrutschen kann als nächstes ein Abschnitt nach dem anderen erstellt werden, wodurch es möglich wird die fertigen bereits reviewen zu lassen während die späteren noch in Bearbeitung sind oder auf ihre Verfassung warten. Hier könnte bereits eine qualitätssichernde Definition of Done zum Einsatz kommen, die in diesem Fall z.B. den Punkt "darf nicht geltenden Gesetzen widersprechen" enthalten sollte.1


Beim Zusammenfügen der derartig qualitätsgesicherten Textbausteine müsste dann nur noch ein "Integrationstest" erfolgen, also eine Überprüfung ob die einzelnen Abschnitte inhaltlich aufeinander aufbauen, gleich formatiert sind, etc. Da dieser Integrationstest jedesmal durchgeführt werden sollte wenn ein neues Abschnitt fertig ist würde jeder Durchgang vergleichsweise schnell sein, da er auf vergangene Durchläufe aufbauen kann.


Auch die am Ende stattfindende Schlussredaktion würde in diesem Vorgehensmodell schnell über die Bühne gehen können, da der Grossteil der Arbeit bereits in den vorherigen Arbeitsschritten erledigt wurde. Der in Schlussphasen häufige Zeitdruck würde weniger ins Gewicht fallen und die Versuchung bei der Qualitätssicherung zu schlampen um schneller fertigzuwerden wäre nicht mehr gegeben. In der Gesamtsicht wäre der Prozess sowohl agil (flexibel, iterativ, incrementell) als auch sorgfältig.


Übrigens: als Nebenprodukt eines solchen Vorgehens würden schon früh die Punkte auffallen, über die man in zwischen- oder nachgelagerten Retrospektiven reden sollte, in dem hier thematisierten Fall etwa das Verhältnis der Beteiligten zur freiheitlich demokratischen Grundordnung. Das wäre sicherlich ein interessanter Termin.


1Bei einem politischen Beratergremium in einem stark regulierten Umfeld weniger abseitig als man auf den ersten Blick annehmen könnte

Montag, 12. Juli 2021

Agile Bauprojekte (VII)

Und ich dachte, das Praxisbeispiel für agilen Gebäudebau das ich vorletzte Woche gefunden hatte wäre bemerkenswert gewesen. So wie es aussieht ist es einer chinesischen Firma nochmal gelungen ein weiteres Level zu erreichen: durch die Nutzung vorgefertigter Wohnungs-Module, die vor Ort nur noch "zusammengeschraubt" werden müssen, kann ein zehnstöckiges Hochhaus in nur einem Tag (!) errichtet werden, und wenn man es wollte könnte man es wieder auseinandernehmen, einzelne Module austauschen und die in andere Gebäude einbauen. Wirklich beeindruckend.



Einige Abstriche sind bei diesem Gebäude sicher zu machen, z.B. limitiert die Modulgrösse die Raumgrösse und es gibt auch keine Tiefgarage (zumindest keine in Modulbauweise, beim Tiefbau stösst die noch an Grenzen). In einem Artikel der FAZ wird auch bezweifelt, dass in dieser Bauweise (im Wesentlichen aus Stahl) ein Schallschutz und eine Atmungsaktivität der Wände möglich sind die westeuropäischen Standards entsprechen.


Damit ist aber auch eine weitere Parallele zu anderen agilen Vorhaben in der Software- und Hardware-Entwicklung gegeben - Agilität kommt häufig mit einem Preis, dessen muss man sich bewusst sein. Wenn schnelle Baubarkeit und Veränderbarkeit diesen Preis wert sind sollte man es machen. Wenn nicht, dann sollte man es lassen.

Donnerstag, 8. Juli 2021

Methodenwechsel während des Projektlebenszyklus

Mit welcher Methodik machen wir eigentlich unser nächstes Projekt? Mit SAFe, Scrum oder Kanban? Vielleicht auch mit Lean Six Sigma, LeSS oder Extreme Programming? Diese Frage stellt sich immer wieder, und wie so oft ist die einzig richtige Antwort darauf das gute alte "kommt darauf an". Spannend ist aber das worauf es ankommt. Das können Erfahrungswerte, Vorlieben, Rahmenbedingungen oder Unternehmensstandards sein, es kann aber auch auf einen weiteren, oft unterschätzten Faktor ankommen - die jeweilige Phase des Projekt-Lebenszyklus.


Bevor wir darauf eingehen etwas Grundsätzliches: es macht grossen Sinn Arbeit nicht um Projekte sondern um Produktlinien zu gruppieren, da dadurch kontinuierliche Weiterentwicklung, DevOps und andere sinnvolle Dinge einfacher werden. Manchmal geht das aber nicht wirklich gut, etwa bei Legacy-Ablösungen, Auftragsarbeiten für externe Kunden oder Hardware-Produkten, die ja irgendwann in die Serienfertigung überführt werden. Hier machen Projekte meistens mehr Sinn, und um diese Fälle soll es hier gehen.


Am Anfang derartiger Vorhaben steht  in der Regel eine Phase grosser Ergebnis-Offenheit. Es werden vor allem Hypothesen geprüft und Proofs of Concept, Prototypen und frühe MVPs erzeugt, zwischen deren Erstellung längere Pausen liegen können in denen Ergebnisse validiert, Make or Buy-Entscheidungen getroffen oder Budgets ausgehandelt werden. Hier können Design Thinking-Workhops Sinn machen, Design Sprints, Rapid Prototyping oder in Teilzeit betriebene Innovationsprojekte. Für voll ausgelastete Projektteams ist es meistens noch zu früh.


Erst wenn diese Vollauslastung möglich ist (z.B. nach Bestätigung der Bedarfshypothese, der Bestätigung der Machbarkeitshypothese und Bestätigung des Budgets) kann ein dazu passender Arbeitsmodus eingesetzt werden, wobei sich im Rahmen komplexer Vorhaben mehr und mehr iterative Ansätze wie Scrum, SAFe, XP oder LeSS durchsetzen. Neben den kontinuierlichen Lern- und Lieferzyklen bieten sie den Vorteil, dass ihre Regeltermine lange im Voraus festliegen, so dass Stakeholder und Nutzervertreter dann verfügbar sein können.


Gegen Ende wird diese regelmässige Verfügbarkeit von Stakeholdern und Nutzervertretern allerdings weniger wichtig. Da dann (bei richtig umgesetztem agilem Vorgehen) keine kritischen Entscheidungen oder Weiterentwicklungen mehr anstehen, sondern vor allem Restarbeiten umgesetzt und kleinere Optimierungen durchgeführt werden, gibt es zum Einen kaum noch wirkliche Neuerungen zu denen in Reviews Feedback gegeben werden kann, zum anderen werden die Ergebnisse eher kleinteilig, Detail-spezifisch oder technisch (z.B. bei Refactorings). Hier können Lean-Ansätze wie Kanban oder Six Sigma passend sein.


Sich auf die Idee der Methodenwechsel während des Projektlebenszyklus einzulassen kann aus mehreren Gründen sinnvoll sein. Nicht nur weil es den Arbeitsmodus den aktuellen Erfordernissen anpasst (statt das Umgekehrte zu versuchen), sondern auch weil es in Erinnerung ruft, dass Methoden kein Selbstzweck und keine Silberkugeln sind, und weil es daran erinnert, dass man auch spät im Projekt noch Scrum Master oder ähnliche Rollen braucht die regelmässig aus dem Hamsterrad heraustreten und Sinnfragen stellen (auch hier nochmal: nein, der Scrum Master macht sich nicht irgendwann selbst überflüssig).


Zum Schluss noch eine häufig gestellte Frage: ist so ein "häufiger" Methodenwechsel nicht teuer? Die Antwort darauf kann nur sein: umsonst ist er zwar nicht, ein Projekt über weite Strecken mit einer zu diesem Zeitpunkt nicht passenden Methodik zu betreiben ist im Zeifel aber viel teurer. Die Umstellung lohnt sich also.

Montag, 5. Juli 2021

Transparenz im galaktischen Bauamt

Grafik: Wikimedia Commons / Nasa - Public Domain

Am Anfang von Douglas Adams Roman The Hitchhiker's Guide to the Galaxy steht die Zerstörung der Erde. Ausserirdische Raumschiffe erscheinen und kündigen die Sprengung des Planeten an um Platz für eine Hyperraum-Autobahn zu schaffen. Auf die entsetzten Bitten das nicht zu tun folgt nur der Hinweis, die Pläne hätten lang genug im Bauamt auf Alpha Centauri ausgelegen, jetzt sei es zu spät für Protest. Und diese Szene ist nicht nur der Beginn einer der bekanntesten literarischen Erzählungen überhaupt, sie ist auch eine beissende Kritik an der scheinbaren Transparenz von grossen Planungsprozessen.

There’s no point acting all surprised about it. All the planning charts and demolition orders have been on display in your local planning department in Alpha Centauri for fifty of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now.
The Hitchhiker's Guide to the Galaxy

Um mit dem offensichtlichsten zu beginnen: die Existenz des galaktischen Bauamts ist den von den geplanten Bauarbeiten betroffenen Menschen gar nicht bewusst, und damit auch nicht, dass man dort Pläne einsehen kann. Dies ist eine deutliche Parallele zu vielen grossen Bau-, Produktions- und internen Change-Vorhaben. Theoretisch hätte man ja wissen können wo die dokumentiert werden, weshalb eine ankündigende Kommunikation für nicht nötig gehalten wird.


Direkt daran anknüpfend kommt dazu, dass der Standort Alpha Centauri von der Erde aus nicht einfach zu erreichen ist. Auch hier kann man eine Gemeinsamkeit zu vielen Grossvorhaben erkennen. Man muss für Einsicht und Einspruch zwar nicht auf andere Planeten, der Zeitaufwand, die nötigen Prozesskenntnisse und die ggf. geforderten Bearbeitungsgebühren sind aber für viele Menschen ein Hindernis das so gross ist, dass es kaum noch überwindbar ist.


Die Kombination aus geringem Wissen und hohem Aufwand führt schliesslich zu einem weiteren Effekt: einem sehr starken Unterschied beim jeweils anfallenden Aufwand. Die planende Seite muss ihn nur einmal auf sich nehmen um die Dokumente zu hinterlegen, die von den Planungen betroffene Seite müsste das immer wieder tun um sicher zu sein, dass es keine Planänderungen gibt. Da in den meisten Fällen aber keine anliegen wäre das unwirtschaftlich und frustrierend, weswegen es meistens unterbleibt.


Der vermutlich weitreichendste Punkt ist aber einer der nicht sofort in Auge fällt: sowohl in Adams Roman als auch in den real existierenden Grossvorhaben fühlen sich die Planungsverantwortlichen absolut im Recht und sehen darum keine Notwendigkeit ihr Verhalten zu ändern. Aus ihrer Sicht wäre es die Holschuld der von den Vorhaben Betroffenen gewesen sich zu informieren ob und in welcher Weise sie betroffen sind. Tun diese das nicht sind sie selbst schuld.


Hier - und das ist entscheidend - liegt auch der Schlüssel für eine bessere Kommunikation: statt es durch zusätzliche Regeln und Standards scheinbar immer offensichtlicher zu machen wo die Betroffenen sich informieren können (was in der Realität aber nur zu noch mehr Bürokratie und Intransparenz führt) müssen die Planungsverantwortlichen auch für die proaktive Kommunikation verantwortlich sein. Was dabei zu beachten ist steht hier.