Donnerstag, 10. Oktober 2024

Rapid Prototyping on Steroids

Auf den ersten Blick ist das hier einer dieser Holy Shit-Momente. In gerade einmal fünf Minuten erstellt Henrik Kniberg hier mit Hilfe eines KI-Chatbots einen funktionsfähigen Prototypen einer mobile App in mehreren Versionen, samt Dokumentation und einem initialen Backlog mit den nötigen Anforderungen um daraus eine voll funktionsfähige erste Version zu erstellen. Früher wäre damit ein ganzes Team einen ganzen (Design-)Sprint lang beschäftigt gewesen, jetzt geht es in wenigen Momenten.



Wenn man weiss wie derartige Chatbots funktionieren relativiert sich die Leistung ein bisschen. Das Demonstrationsobjekt ist eine To Do-Listen-App, von denen es bereits unzählige gibt, deren Code hier Teil des Traningsmaterials der KI gewesen ist. Würde man sie dort einsetzen wo Prototypen normalerweise gebraucht werden, in der innovativen Neuentwicklung nämlich, wäre kaum Trainingsmaterial vorhanden und das Resultat wäre entsprechend wenig beeindruckend.


Trotzdem bleibt das Ergebnis dieser Vorführung natürlich beachtlich. Um das Potential dieser Technologie voll nutzen zu können, wird es darauf ankommen, zu wissen, wo sie einsetzbar ist und wo nicht. So werden sich beispielsweise die wenig innovativen Teile einer neuen Anwendung (Login, Profilseite, etc.) schnell generieren lassen, so dass mehr Zeit für die wirklich innovationsbringenden Tätigkeiten bleibt. Alleine das kann schon sehr viel bewirken.


Am Ende sollte trotzdem in jedem Fall klar sein, dass der auf diese Art entstandene Code mindestens durch ein gründliches Refactoring gehen, wenn nicht sogar neugeschrieben werden sollte, bevor er veröffentlicht wird. Wenn nicht, dürften einige unschöne Überraschungen bevorstehen. Selbst das kann im Vergleich zu einer vollständigen Selbstentwicklung aber immer noch deutlich effektiver und effizienter sein. Die Zukunft hat bereits begonnen.

Montag, 7. Oktober 2024

Agile Bauprojekte (VIII)

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

Ein Massenphänomen sind sie noch immer nicht, aber die Anwendung agiler Arbeitsweisen in Bauprojekten ist mittlerweise nichts mehr was sich als unmöglich bezeichnen lässt, von Teslas MVP-Fabrikgebäuden bis hin zu "konfigurierbaren" und in Tagen errichtbaren Modulbau-Häusern gibt es zahlreiche funktionierende Beispiele. Zur Zeit wird agiles Bauen aber noch einmal einfacher, billiger und flexibler, denn eine weitere Technik ist im Bau angekommen: 3D-Druck.


Diese ursprünglich nur für Kunststoffe verwendete Technik ist mittlerweile durch technische Neuerungen auch für Baustoffe nutzbar, und ermöglicht so nicht nur die schnelle und ggf. individuelle Anfertigung von Bauelementen oder den erwähnten Modulen, sondern sogar von ganzen Gebäuden (davon ausgenommen bleiben weiterhin die Tiefbauarbeiten, und bei denen vor allem der Aushub und die Sicherung der Baugruben, die noch immer klassisch geplant und durchgeführt werden müssen).


Ein bekanntes Beispiel kann man seit 2021 in Amsterdam nicht nur betrachten sondern sogar betreten: eine ganze Brücke ist dort mit einem 3D-Drucker erstellt worden - aus Stahl. Dafür wurde schichtweise Metallpulver aufgetragen und so festgeschmolzen, dass dadurch nach und nach die Brückenform entstand. Darüber hinaus ist das ganze Bauwerk mit Sensoren versehen, die Belastungen messen und inspect & adapt ermöglichen - die nächste so gebaute Brücke wird stabiler und braucht weniger Material.


Auch Betonwände lassen sich mittlerweile schichtweise mit einem 3D-Druck-Roboter hochziehen, und auch hier können Ergebnisse in der Nähe betrachtet werden: in Heidelberg wurde 2023 das Gebäude eines Rechenzentrums mit einem Beton-3D-Drucker in nur sieben Tagen erstellt und seit 2024 steht in Beckum bei Münster das erste so entstandene Wohnhaus, dessen Bau nur zwei Wochen gedauert hat - beides ist also in einem Zeitraum fertig geworden, der einem Sprint entspricht.


Die beste Kombination aus Geschwindigkeit und Flexibilität bietet schliesslich die Kombination aus 3D-Druck und Modulbauweise. In Japan und den USA gibt es jetzt schon Baufirmen, die naben der Baustelle temporäre Fabriken errichten und in ihnen Baumodule erstellen, die dann gleich zusammengesetzt werden können. In diesem Rahmen können auch Schäden am Gebäude schnell behoben und etwahige Fehler der Planung schnell korrigiert werden. Auch hier also - inspect & adapt.


Wenn wir also über agile Vorgehensweisen in Bauprojekten sprechen, geht es nicht mehr darum, ob das überhaupt möglich ist, das ist bereits bewiesen. Auch die Genehmigung dieser Bauweise ist offensichtlich bereits da, der Bau der genannten Beispiele durfte ja stattfinden. Und was die Kosten betrifft - laut der oben verlinkten Artikel ist Bauen im 3D-Druckverfahren sogar billiger. Die Frage ist daher nur noch, warum es nicht viel öfter passiert. Vielleicht weil es noch zu wenige der dafür nötigen Roboter gibt?

Donnerstag, 3. Oktober 2024

Trios

Bild: Wikimedia Commons / Matthias Klein - CC BY-SA 3.0

Eine Besonderheit der Rollen in agilen Frameworks ist, dass fast immer mehrere von ihnen auf der gleichen Hierarchieebene einer gemeinsamen Organisationseinheit vorkommen, wo die Aufgabengebiete unter ihnen aufgeteilt sind. Die häufigste derartige Aufteilung ist die in Paare, v.a. mit Scrum Master und Product Owner, es gibt aber auch verbreitet so genannte Trios, also Dreiergruppen. Welche drei Rollen das sind ist aber nicht einheitlich, es haben sich über die Zeit verschiedene Varianten entwickelt.


Die drei Amigos

Die vermutlich älteste Variante eines Trios wird auch die drei Amigos genannt. Es handelt sich um eine in der Frühzeit der agilen Softwareentwicklung (vor 2010) verbreitete kleinstmögliche Form eines crossfunktionalen agilen Entwicklungsteams, bestehend aus jeweils einem Vertreter von Business, Softwareentwicklung und Qualitätssicherung. Als Vorgänger der Scrum Teams arbeiteten diese Trios vor allem an der Product Delivery also dem (agilen) Abarbeiten eines Lieferplans von Features.


Das Product Trio

Eine ähnliche, aber deutlich später (ca. 2020) entstandene Form eines kleinen, crossfunktionalen agilen Teams ist das durch Thereresa Torres popularisierte Product Trio, bestehend aus einem Product Manager, einem Designer und einem Software Engineer. Der Unterschied zu den drei Amigos ist vor allem das Tätigkeitsfeld - statt in der Product Delivery arbeiten Product Trios vor allem in der Product Discovery, also der ergebnisoffenen Neuentwicklung von Produkten.


Das TPD Trio

In gewisser Weise die skalierte Version eines Product Trio, wenn auch ca. 10 Jahre früher entstanden. Entwickelt als Teil des Spotify Models besteht ein TPD Trio aus einem Tribe Lead (Eingineering Manager), einem Product Lead und einem Design Lead, die zu dritt einen Tribe, also eine Einheit aus mehreren Squads (Entwicklungsteams) leiten. Statt selbst an der Umsetzung mitzuarbeiten erstellen sie dabei in ihrem jeweiligen Themengebiet Anforderungen und Vorgaben für die Teams.


Das ART Trio

Zu einer ähnlichen Zeit wie das TPD Trio entstanden, erfüllt das Führungs-Trio eines Agilen Release Train (ART) in SAFe zwar einen ähnlichen Zweck, ist aber anders zusammengesetzt. Neben dem Product Manager sind hier ein für die Prozesse verantwortlicher Release Train Engineer (RTE) und ein System Architect Mitglied. Im "Full SAFe" gibt es noch eine Entsprechung auf der nächsthöheren Ebene, bestehend aus Solution Manager, Solution Train Engineer (STE) und Solution Architect.


Andere Trios

Je nach Kontext können noch zahhlreiche weitere Formen von Trios bestehen, gesehen habe ich z.B. schon UX, Entwicklung und QA oder Entwicklung, Operations und Security. Wichtig ist aber in allen Varianten, dass es sich um gleichberechtigte Teile eines kleinen, crossfunktionalen Entwicklungs- oder Führungsteams handelt, die in Summe alle Aufgaben abdecken können, die zur Erledigung ihres jeweiligen Auftrages notwendig sind.


Und natürlich gibt es auch etwas grössere Einheiten, die dann Quartett, Quintett, etc. heissen können. Sie sind aber deutlich seltener anzutreffen als die Trios, die durch Product Discovery, Spotify und SAFe einen recht hohen Bekanntheitsgrad erreicht haben.

Montag, 30. September 2024

Kommentierte Links (CXVIII)

Grafik: Pixabay / Geralt - Lizenz
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.

Pim de Morree: The Anatomy of a Self-Managing Organization - Why Networks Trump Hierarchies

Die Idee einer netzwerlartigen Organisation wird immer wieder angeführt, wenn diskutiert wird, wie auch im grossen Masstab Agilität und Flexibilität möglich sein können, die dabei immer wieder gestellte Frage ist aber die, ob das auch in der Realität funktionieren kann. Pim de Morree kann diese Zweifel ausräumen indem er verschiedene grosse und mittelgrosse Unternehmen nennt, in denen bereits jetzt so gearbeitet wird, von Haier über Indaero, Buurtzorg und Vertica bis hin zu W.L. Gore. Derartige Praxisbeispiele können nicht nur Zweifel zerstreuen, sie bringen die Diskussion auch wieder zum richtigen Thema zurück: was müssen wir tun um selbst so arbeiten zu können?

Erik de Bos: The Puzzle of Self-Organisation

Dieser Artikel von Erik de Bos enthält mit Enrise ein weiteres Beispiel für eine Netwerk-Organisation, konzentriert sich aber auf ein anderes Thema: was muss für wirkliche Selbstorganisation auf Teamlevel eigentlich gegeben sein? Der wichtigste unter den von ihm genannten Faktoren ist dabei eine gewisse Erfahrung, was auch intuitiv Sinn ergibt - ohne Erfahrungwerte ist es schwer, Potentiale und Risiken einzuschätzen, und ihnen vorbeugend oder reaktiv zu begegnen. Dort wo Erfahrungen vorhanden sind (oder nach und nach entstehen) sind Effektivität und Erfolgsaussichten von selbstorganisierten Einheiten dagegen deutlich höher.

Bob Galen: Shatters Anonymous

Ein bisschen Meta-Perspektive. Bob Galen sinniert hier über zwei viral gegangene Linkedin-Artikel des Disciplined Agile-Erfinders Scott Ambler, in denen dieser (mit grenzwertiger Wortwahl) der agilen Bewegung vorgeworfen hat, ihre eigene Position durch Dogmatismus, Kommerzialisierung und fehlende Lösungsorientierung untergraben zu haben. Galen stimmt dieser Beschreibung grundsätzlich zu, was ihm darin fehlt, ist aber eine wie auch immer geartete Lösungsorientierung. Er ruft daher alle Meinungsführer der agilen Bewegung dazu auf, die zu erarbeiten. Ein Aufruf dem man sich nur anschliessen kann.

Prateek Singh: On Deterministic Fixed-Length Timeboxes

Ein Artikel, der in gleich zweifacher Hinsicht interessant ist. Zum einen, weil Prateek Singh in ihm die Probleme, die mit festen Deadlines oder festen Sprintlängen verbunden sind, gut herausarbeitet. In komplexen Umfeldern lässt sich eine Fertigstellungsdauer nicht seriös prognostizieren, dafür gibt es zu viele Unbekanntheiten und Dynamiken. Zum anderen ist aber interessant, wie wenig er über die Praktiken zu wissen scheint, mit denen in den Iterativen Ansätzen damit umgegangen wird (vereinfacht gesagt mit variablem Scope eines fixen Ziels). Mit diesem Wissen hätte er (der hier stellvertreten für die Kanban-Community steht) Scrum noch besser kritisieren können.

Charles Lambdin: What Is Cost of Delay?

Zuletzt etwas Grundsätzliches. Charles Lambdin nimmt sich eines oft diskutierten aber z.T. sehr unterschiedlich verstandenen Konstrukts an, der Verspätungs-Kosten (Cost of Delay). Zu den verschiedenen interessanten Aspekten auf die er dabei eingeht gehört u.a., dass es auch negative Verspätungskosten gibt (die er mit Benefits of Delay treffender benennt) und dass es trotz einer letztendlichen Unbezifferbarkeit gute Gründe dafür gibt, es trotzdem zu versuchen. Lesenswert.

Donnerstag, 26. September 2024

Agile Success Stories: Entwickler und Anwender zusammenbringen

Bild: Pexels / Ivan Samkov - Lizenz

Dass "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln, ist leider ein verbreitetes Phänomen. Das ist auch irgendwie verständlich, wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann schnell in Frustration abrutschen. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.


Diese hier beginnt mit einem Problem. In einem Konzern, dessen agile Transformation ich begleiten durfte, galt das Verhältnis zwischen der internen Softwareentwicklung und den Anwendern in den Filialen als zerrüttet. Die Software würde schwer zu verstehen und zu bedienen sein, hiess es von den Filialkräften, umgekehrt beschwerten sich die Entwickler über unvollständige und erratische Anforderungen und Fehlermeldungen. Jede Seite sah das Problem bei der anderen.


Nach kurzem Nachforschen liess sich ein Grund für diese Missstände identifizieren: der Anforderungsmanagement-Prozess war (freundlich gesagt) suboptimal. Neue Anforderungen wurden (wenn sie überhaupt aus den Filialen kamen) von deren Leitern gestellt, die gar nicht mit den jeweiligen Systemen arbeiteten. Auf dieser Basis erstellte die IT-Konzeptionsabteilung eine Detailspezifikation und gab diese ohne Rücksprache mit dem Anforderer an die Entwicklung weiter, die nur noch umsetzte.


Natürlich kam es entlang dieser Strecke fast schon zwangsläufig zu Missverständnissen und Stille Post-Effekten, die dann in den oben genannten Problemen resultierten. Um das zukünftig zu verhindern, sah der neue Prozess etwas für diese Firma geradezu Revolutionäres vor: Anwender und Entwickler sollten diekt miteinander sprechen, und das nicht nur ab und zu sondern regelmässig. Und mit regelmässig war gemeint mindestens einmal pro Monat.


Umgesetzt wurde das, indem der gewählte Arbeitsmodus Scrum etwas angepasst wurde. Nach jedem zweiten Sprint fanden die Sprint Reviews in einer der Filialen statt. Im Mittelpunkt standen dabei nicht die Ergebnisse des letzten Sprints (die wurden in den dazwischenliegenden "normalen" Reviews besprochen) sondern das Feedback der Filialkräfte, und zwar sowohl zu Verständlichkeit und Bedienbarkeit der Anwendungen als auch zur Sinnhaftigkeit der als nächtes geplanten Funktionen.


Diese Filialbesuche brachten regelmässig erhellende Erkenntnisse. Immer wieder kam es vor, dass Funktionen, die Management und IT-Konzeption für zentral gehalten hatten, sich in der Realität als unbenötigt herausstellten, umgekehrt wurden von den Anwendern wiederholt Features gewünscht, die an die niemand gedacht hatte. Und nachdem dieser Arbeitsmodus eine Zeit lang gelaufen war, wurden die Reviewss immer positiver, da mehr und mehr der Wunsch-Features tatsächlich gebaut wurden.


Zur ganzen Wahrheit gehört, dass die Veränderungen nicht für alle Beteiligten positiv waren. Besonders die IT-Konzeptionsabteilung musste damit leben, in der Entwicklung der Filial-Software praktisch nicht mehr benötigt zu werden - und dass dann noch betont wurde, dass erst durch die direkte Kommunikation zwischen Entwicklern und Anwendern die Zufriedenheit mit der Software besser geworden war, dürfte für die bisher zwischen ihnen vermittelnden IT-Konzepter deprimierend gewesen sein.


Im Grossen und Ganzen empfanden aber fast alle das neue Vorgehen als eine Verbesserung, sowohl in Bezug auf die Zusammenarbeit als auch in Bezug auf die dadurch erzielten Ergebnisse. Wie ein Manager es irgendwann mal treffend bemerkte: "Wenn man sieht, wie gut es jetzt läuft, fragt man sich schon, warum wir das jemals anders gemacht haben."

Montag, 23. September 2024

Wie ein einziger Manager eine Firmenkultur herunterwirtschaften kann

Bild: Pixabay / The Digital Artist - Lizenz

Eine der grossen Gemeinheiten beim Thema Firmenkultur ist es, dass man sie nur sehr schwer und langsam zum Besseren verändern kann, aber erstaunlich schnell zum Schlechteren. Und während eine Verbesserung immer nur durch eine Gemeinschaftsleistung erreichbar ist, kann eine Verschlechterung sogar von nur einem einzigen Manager herbeigeführt werden, wenn er denn nur weit genug oben in der Hierarchie seine Position hat. Das klingt unglaublich, ist aber immer wieder zu beobachten.


Nehmen wir den Fall von Peter, den ich selbst miterleben durfte (und der in Wirklichkeit natürlich anders heisst). Peter war relativ neu in einer Führungsposition in einem Konzern, der bis dahin eine vergleichsweise gute Unternehmenskultur gehabt hatte. Auf die traf jetzt Peter, der zuvor in einer anderen Landesgesellschaft gearbeitet hatte, und sich dort einen besonderen Glaubenssatz angeeignet hatte: der Chef muss möglichst allen wichtigen Entscheidungen selber treffen, sonst sind sie nicht gut.


Am Anfang hatten alle gedacht, dass das alleine daran scheitern würde, dass Peter gar nicht die Zeit finden würde, um sich um alle Themen zu kümmern. Aber er war anderer Meinung und glaubte, mit einem strikten Zeitmanagement wäre das kein Problem. Er teilte seinen Tag in eine ununterbrochene Reihe von dreissig- oder sechzigminütigen Calls und Meetings ein, von Acht Uhr morgens bis Neun Uhr Abends. In denen hörte er sich jeweils die Sachstände an, traf Entscheidungen und setzte Deadlines.1


Mit diesem strikten Zeitmanagement war allerdings ein Risiko verbunden - wenn es einmal nicht zu einer Entscheidung kam, wurden Folgetermine nötig, die aber in den vollen Kalender nicht mehr hineinpassten. Um es nicht dazu kommen zu lassen, versuchte Peter in möglichst jedem Termin eine Entscheidung zu erzwingen. Und sobald die einmal stand, durfte das Thema nicht nochmal aufgebracht werden. "Warum reden wir darüber?" fragte er dann, "Ich habe doch schon entschieden, nächsten Thema."


Für die anderen Angestellten waren diese Verhaltensweisen ein Problem. Nicht nur mussten sie die Erklärung ihrer z.T. hochkomplexen Themen so zusammenkürzen, dass wichtige Aspekte fehlten, die auf dieses Basis getroffenen (und praktisch irreversiblen) Entscheidungen waren dementsprechend auch nicht immer die besten und führten oft zu neuen Problemen, vermeidbarer Mehrarbeit, verärgerten Kunden oder verpassten Geschäftspotentialen.


Schon bald begannen sich daher die in Peters Termine mitgebrachten Unterlagen zu verändern. Um ihn an vorschnellen Entscheidungen zu hindern, wurde prominent auf noch fehlende wichtige Informationen hingewiesen, auf unabsehbare Konsequenzen zu früher Entscheidungen, auf eine unklare Rechtslage oder ähnliche Faktoren. Mit anderen Worten: die ursprünglich sehr lösungsorientierten Menschen in Peters Umfeld entwickelten mehr und mehr eine Problemfixierung und Bedenkenträger-Argumentation.


Bereits das wäre schon problematisch gewesen, es ging aber noch weiter. Immer wieder kam es vor, dass Peter zwar mit Verweisen auf fehlende Informationen oder unabschätzbare Risiken von Schnellschüssen abgehalten werden konnte, er aber in einem anderen Termin von anderen Mitarbeitern versehentlich Informationen bekam, die ihm doch eine Entscheidung ermöglichten. Von der dann nur noch in Kenntnis gesetzt zu werden war eine erstaunlich häufige Frustrations-Erfahrung.


Um dieser Erfahrung nach Möglichkeit nicht ausgesesetzt zu sein, begannen die Mitarbeiter damit, Informationen nicht mehr untereinander zu teilen oder sie möglichst unklar zu formulieren. Da es sich oft im Nachhinein herausstellte, dass einige dieser Informationen auch für andere wichtig gewesen wären, verschlechterte sich die Stimmung in der Belegschaft deutlich. Während vorher ein kollegialer und hilfsbereiter Umgang vorherrschte, entstand jetzt eine Misstrauens- und Blaming-Kultur.


Die Geschichte hatte noch einige weitere unschöne Aspekte, aus den hier beschriebenen lässt es sich aber erkennen, dass tatsächlich ein einziger Manager eine Firmenkultur herunterwirtschaften kann. Und selbst wenn dieser Fall hier ein besonders plakativer ist, es gibt noch viele andere Möglichkeiten, es zu tun, von falsch gesetzen finanziellen Anreizen über bürokratische Prozessvorgaben bis hin zur gezielten Einstellung und Beförderung nicht teamfähiger "Rockstars".


Natürlich steht auch hier am Ende die Frage, wie es besser ginge - die auch (scheinbar) einfach zu beantworten ist: man sollte Menschen wie Peter nicht in hohe Verantwortungspositionen befördern. Das zu schaffen ist aber eine grössere Herausforderung als man denken sollte. Finale Pointe: der hier beschriebene Peter hiess zwar nicht so, wurde aber hinter seinem Rücken so genannt, da seine Karriere dem Peter-Prinzip zugeschrieben wurde. Das wäre nochmal ein grosses und eigenes Thema.



1Auch das Mittagessen war ein Arbeitstermin, und Emails beantwortete er Nachts oder am Wochenende

Freitag, 20. September 2024

Rocks, Pebbles, Sand

In der Theorie klingt das Arbeiten in Sprints ganz einfach. Zu Beginn wird ein fachliches Ziel mit hohem Business Value ausgewählt und ggf. noch einmal in kleinere (Teil-)Ziele aufgeteilt, die jeweils in einen Sprint passen. Während dieses Zeitraums (meistens zwei oder drei Wochen) wird konzentriert an der Fertigstellung gearbeitet, danach wird das Ergebnis den Stakeholdern vorgestellt und mit ihnen besprochen, im Anschluss daran wird ein neuer Sprint mit einem neuen Ziel geplant.


In der Realität ist es meistens schwieriger. Zum Einen ist es meistens so, dass es auch Aufgaben gibt, die nicht den höchsten Business Value haben, die aber irgendwann erledigt werden müssen (Einspielen von Versionsupgrades, Vereinheitlichung von Farbschemata, etc). Meistens sind die auch nicht gross genug für ein eigenes Sprintziel. Zum anderen füllen Sprintziele einen Sprint fast nie völlig aus, es bleibt immer eine gewisse Restkapazität übrig.


Viele Teams gehen mit dieser Situation um indem sie etwas Naheliegendes machen: sie planen zuerst alles ein, was für die Erreichung des Sprintziels nötig ist und füllen die verbleibende Kapazität auf indem sie in der restlichen Zeit die anderen Aufgaben abarbeiten. Das ist auch grundsätzlich sinnvoll - unter der Voraussetzung, dass diese Arbeiten auch im verbleibenden Sprint abgeschlossen werden können und nicht halbfertig in den nächsten rutschen und dort Kapazität blockieren.


Ein Weg um das sicherzustellen trägt den Namen Rocks, Pebbles, Sand. Angeblich bei PayPal erfunden und durch die PayPal Mafia popularisiert funktioniert er folgendermassen: zu Beginn eines Planungstermins plant man die grossen Arbeitspakete ein, die "Felsbrocken" (Rocks). Als nächstes füllt man die verbleibende Zeit mit mittelgrossen Aufgaben, den "Steinen" (Pebbles). Die zuletzt verbleibende Zeit ist schliesslich für Kleinst-Aufgaben vorgesehen, den "Sand".


Was der Schlüssel für eine erfolgreiche Anwendung dieses Vorgehens ist, ist ein Focus auf dem Erstellen von Aufgaben, die so klein sind, dass sie die eingeplante Zeit möglichst nicht sprengen. Rocks sollten maximal so gross sein wie ein Sprint, Pebbles maximal so gross wie die im Sprint verbleibende Zeit nach dem Abzug des für die Rocks eingeplanten Aufwandes, die "Sandkörner" maximal so gross wie das, was danach noch übrig ist.


Natürlich ist damit das Risiko verbunden, dass eine derartige Kapazitätsplanung zu einer versehentlichen Überlastung führt, oder zu einer Situation in der bereits kleine zusätzliche Aufwände den verfügbaren Zeitrahmen sprengen. Es empfiehlt sich daher, auch in diesem Vorgehen einen gewissen Teil der Zeit unverplant zu lassen. Ebenfalls möglich ist es, die Aufgaben des Sand-Typs nur dann in den Sprint zu ziehen, wenn gerade kurzfristiger Leerlauf besteht.


Mit ein bisschen Übung kann es gelingen, durch Rocks, Pebbles, Sand in einen Modus zu kommen, in dem wichtige Aufgaben zuerst bearbeitet werden, kleinere nicht unnötig lange liegen bleiben, die verfügbare Zeit effektiv genutzt wird und es zu keinen in den nächsten Sprint zu schiebenden Langläufern kommt. Das ist vielleicht noch nicht der Idealzustand focussierter Outcome-orientierung, für ie meisten Teams dieser Welt wäre es aber ein Fortschritt.

Dienstag, 17. September 2024

The World Depends on 60-Year-Old Code: COBOL

Heute ein etwas abseitiges Thema: COBOL. Es handelt sich dabei um eine Programmiersprache aus den 50er Jahren (!), auf der bis heute (!!) der Grossteil der Kern-Anwendungen in Banken, Versicherungen, der öffentlichen Verwaltung und vielen anderen grossen Organisationen beruht. In Coding mit Dee gibt es dankenswerterweise einen Überblick darüber was COBOL ist, und was man zu seiner Geschichte und Anwendung wissen muss.



Was mir an Dees Ausführungen besonders gefällt ist die neutrale Einordnung, samt aller Vor- und Nachteile. Sie legt Wert darauf, dass nicht die veraltete Programmiersprache selbst das Problem ist, sondern dass es stattdessen Faktoren wie fehlende Dokumentation, die Verrentung der Wissensträger und die "historisch gewachsenen" Systemstrukturen sind, die zu den Schwierigkeiten führen, über die sich bei COBOL häufig beklagt wird (und wegen denen oft behauptet wird, COBOL-Anwendungen nicht agil weiterentwickeln zu können).