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.

Mittwoch, 30. Juni 2021

Kommentierte Links (LXXVI)

Grafik: Pixabay / The Digital Artist - CC0 1.0

Jutta Eckstein, Eric Abelen, Hendrik Esser: Overcoming One-Size-Fits-All Budgeting

Zu den Fallstricken die eine agile Transition scheitern lassen können gehört auch die Budgetierung. Wenn diese weiterhin so verläuft als wäre die Zukunft vorhersehbar und planbar helfen alle neuen Prozesse, Rollen und Regeln wenig bis gar nicht. Der Ansatz von Jutta Eckstein, Eric Abelen und Hendrik Esser ist naheliegend, dürfte aber den meisten klassisch geprägten Unternehmen sehr schwerfallen: wenn es mit hoher Wahrscheinlichkeit dazu kommen wird, dass die Realität sich anders entwickelt als geplant, sollten lediglich grobe Rahmen und Grenzwerte gesetzt werden, innerhalb derer die Umsetzungs-Verantwortlichen weitgehende Freiheit haben. Die Voraussetzung dafür ist, wie so oft, Vertrauen. Aber dort wo das nicht gegeben ist, ist die Budgetierung auch nicht das grösste Problem.

Jeff Kavanaugh, Rafee Tarafdar: Break Down Change Management into Small Steps

Zum Thema agiles Change Management habe ich selbst schon einiges geschrieben, Jeff Kavanaugh und Rafee Tarafdar geben dem Ganzen aber einen schönen neuen Namen: Microchange Management. Hinter diesem Begriff verbirgt sich ein Framework das ähnlich aufgebaut ist wie OKRs oder agiles Backlog-Management - grosse Vorhaben werden so lange in immer kleinere heruntergebrochen bis diese in kurzen Zeiträumen umsetzbar sind, und selbst in diesen Zeiträumen findet in kurzen täglichen Synchronisationsmeetings ein kontinuierliches Abarbeiten und Überprüfen statt, bei Bedarf auch ein Anpassen von Zielen und Massnahmen. Wie bei den anderen oben genannten Vorgehen dürfte auch hier gelten: einfach zu erklären, anspruchsvoll in der Umsetzung und lohnend wenn es gelingt.

Emma Garofalo: What Is Chaos Engineering?

Ein schöner Spruch den ich vor kurzem mitbekommen habe geht so: "Chaos Engineering ist das was früher Extreme Programming war. Alle ahnen, dass es für die agile Softwareentwicklung einen grossen Sprung nach vorne bedeuten kann, aber weil die meisten Agile Coaches zu wenig Ahnung von Technik haben kann es keiner erklären, und darum macht es fast niemand." Man muss es eingestehen - völlig abwegig ist dieser Spruch nicht, aber gerade deshalb ist das was Emma Garofalo hier macht um so verdienstvoller: sie erklärt das Konzept so, dass auch Nicht-Techniker es verstehen können.

Marcus Raitner: Agilität ist wie Fahrradfahren

Das Erlernen agiler Arbeitsweisen mit dem Erlernen des Fahrradfahrens zu verbinden ist nicht immer unumstritten, gerade in Bezug auf Scrum gibt es den einen oder anderen unpassenden Vergleich. Der den Marcus Raitner hier anbringt ist dafür um so passender: genau wie man das Radfahren nicht auf einem Downhill-Track im Gebirge bei aufziehendem Gewitter lernen sollte, sollte man auch das Arbeiten in agilen Frameworks nach Möglichkeiten nicht in Stress- oder Krisenphasen zu erlernen versuchen. Wesentlich zielführender ist es, die ersten Versuche dort zu machen wo Aufwand und Auswirkungen noch überschaubar sind, so dass man ohne grosse Sorgen Experimente wagen kann.

Thomas Knüwer: Home Office - es ist alles noch viel schlimmer

In den Filterblasen der IT-Branche, der agilen Community und der Medienbranche gibt es in den letzten Monaten die Tendenz zu einer starken Verklärung des Heimarbeit, oft verbunden mit der Aussage, dass diese Art zu arbeiten in nahezu jeder Hinsicht besser wäre als die Präsenzarbeit im Büro. Das Problem dabei - es handelt sich fast ausschliesslich um nicht statistisch validierte Meinungsbilder, bestenfalls angelehnt an anekdotische Evidenz. Thomas Knüwer hält dem eine ganze Reihe von Studien und Statistiken gegenüber die ein ganz anderes Bild aufzeigen. Das heisst zwar nicht, dass Heimarbeit grundsätzlich schlecht wäre (das wäre nur ein anderes überzogenes Meinungsbild), es zeigt aber, dass man sich durchaus kritischer mit diesem Thema beschäftigen sollte als es häufig der Fall ist.

Montag, 28. Juni 2021

Agile Bauprojekte (VI)

Das ist ein interessantes Praxisbeispiel: ein Manager der amerikanischen Firma Clark Pacific stellt vor, wie dort mit Hilfe von Scrum und Lean Management Gebäude gebaut werden. Der Schlüssel ist einmal mehr die Nutzung vorgefertigter Bauteile, von vor Ort "nur noch" zusammengesetzt werden müssen. Der Anspruch ist dabei, dass erste Räume bereits genutzt werden können während andere Teile des Gebäudes sich noch frühen Planungs- oder Bauphasen befinden.



Es ist kein Konferenzvortrag, sowohl rhetorisch als auch grafisch hält er mit anderen hier eingebundenen Videos daher nicht ganz mit, wegen des seltenen Themas lohnt sich das Ansehen aber trotzdem. Und die eingebundenen Bilder von Baufortschritten, Kanban-Boards und Meetings geben interessante Einblicke in die gelebte Praxis.