Mittwoch, 31. Dezember 2025

Kommentierte Links (CXXXV)

Bild: Pexels / Ekam Juneja - Lizenz
Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" aber trotzdem lesenswerten Texte aus dem letzten Jahr.

James Shore: The Best Product Engineering Org in the World

Eigentlich war ich mir ziemlich sicher, das Video von James Shore's Keynote auf dem Regional Scrum Gathering Tokyo irgendwann mal in einen Post auf dieser Seite eingebunden zu haben. Da ich es nicht finde, ist hier das Transkript. Anscheinend ist seine Firma, die er hier beschreibt, einer der mittlerweile seltenen Fälle, in denen Extreme Programming der offizielle Arbeitsmodus ist - und wenn man ihm glauben darf, mit durchschlagendem Erfolg.

Charles Lambdin: Why Agile Is Losing Steam

Artikel über die Ursachen der zur Zeit abnehmenden Beliebtheit agiler Arbeitsweisen gibt es viele, die meisten davon allerdings nur mit geringem Tiefgang, bzw. mit der offensichtlichen Absicht, mit einer Alternative zu Geld oder (unternehmensintern) zu mehr Macht zu kommen. Charles Lambdins Text hat wesentlich mehr Tiefgang, da er auf einer systemischen Betrachtung der umgebenden Gesamt-Organisationen aufbaut, mit denen die agilen Teams und Methodiker oft eher unglücklich interagieren.

Itamar Gilad: Embracing Uncertainty - A Modern Take On Strategy, Goals, and Roadmaps

Itamar Gilad setzt mit seinen Überlegungen an einem häufigen Problempunkt an: wenn die Märkte und Technologien sich ständig ändern, wie kann man da planen? Und umgekehrt - wie soll man ohne Planungen in der Lage sein, ein Unternehmen zu führen? Seine Ausführungen fassen einige bewährte Praktiken zusammen, mit deren Hilfe man diesem Dilemma entkommen kann, verbunden mit einigen hilfreichen Tools und Visualisierungen.

Steve Denning: How Networks Of Competence Help Avoid The Trauma Of Reorganizations

Dass Reorganisationen grosser Unternehmen auf viele Mitarbeiter traumatisierend wirken können ist einer der dunklen Aspekte des Change Managements, über die eher selten gesprochen wird. Steve Denning sieht die Ursache dafür in dem typischen Organisationsdesign, in dem Identifikation und Expertenstatus sich aus der Zugehörigkeit zu Organisationseinheiten ableiten (und mit ihnen verloren gehen können). Seine naheliegende Lösung: die Entkoppelung dieser Aspekte von der Firmenstruktur.

Tobias Mayer: A simple Guide to Scrum

Um zu verstehen, warum das eigentlich sehr einfache Scrum-Framework von vielen Menschen als kompliziert und unverständlich empfunden wird, muss man sich die offiziellen Scrum-Regeln wie eine Legacy-Software vorstellen, die seit mehr als einem Vierteljahrhundert ständig erweitert und angepasst wird. Das was Tobias Mayer gemacht hat, kann man im Rahmen dieser Metapher als Refactoring verstehen: die Funktionsweise ist die gleiche geblieben, aber der Aufbau ist wesentlich klarer.

Charity Majors: In Praise of “Normal” Engineers

Der Hintergrund dieses Artikels ist ein Mythos, und zwar der des so genannten "10x Engineer", also einer Softwareentwicklers, der zehnmal besser ist als der Durchschnitt, und der daher der ideale Angestellte einer IT-Firma ist. Charity Majors relativiert diese Wunschvorstellung und ordnet sie ein: in einem so grossen und sich so stark ändernden Berufsfeld wie der IT ist es praktisch unmöglich, dauerhaft 10x Engineer zu sein. Besser als trotzdem nach einem zu suchen ist es daher, ein Umfeld zu schaffen, in dem auch normale Entwickler das Beste aus sich herausholen können.

Benji Weber: Teamwork & XP in the era of Genies

Um Missverständnisse zu vermeiden: wenn Benji Weber von "Genies" spricht, dann meint er nicht geniale Menschen, sondern die Softwareentwicklung unterstützende KI-Programme, die für ihn Geister (englisch: Genies) sind, die man nicht wieder in ihre Flasche zurückbekommt. Was er herausstreicht: der beste Arbeitsmodus für sie ist der, der auch bei menschlichen Programmierern der beste ist - kleine Releases, kleine Codebase, schnelle Tests, viel Automatisierung und verständlicher Code.

Mike Fisher: How Culture Scales (or Doesn’t)

Von vielen Menschen wird (Unternehmens-)Kultur als etwas gesehen, das einfach da ist und sich nicht gezielt verändern oder gestalten lässt Die Organisationssoziologie und -psychologie würde widersprechen: es geht, allerdings mit dem Haken, dass es nicht einfach ist - vor allem in grossen Organisationen. Zum Glück hat Mike Fisher gerade für die einiges an Ratschlägen parat, mit deren Hilfe man sich dieser verdienstvollen Aufgabe annehmen kann.

Melissa Suzuno: The Product Operating Model Explained

Zum Product Operating Model, dem v.A. von Marty Cagan popularisierten Arbeitsmodus der kalifornischen Tech-Firmen, ist schon viel gesagt und geschrieben worden. Was diese Erklärung von Melissa Suzuno aus dieser Masse heraushebt ist die Mischung aus Struktur und Ausführlichkeit. Man muss sich etwas Zeit nehmen, aber dann weiss man nicht nur wie das Ganze gedacht ist, sondern auch wie man versuchen kann, es bei sich einzuführen und was man dabei beachten sollte..

Jeff Gothelf: What if there’s no behavior change to measure?

Zu den grossen Mantras der Objectives und Key Results (in der Produktentwicklung) gehört es, dass sie auf eine Verhaltensänderung der Käufer oder Nutzer eines Produktes abzielen sollten, und zwar auf eine, die gemessen werden kann. Das macht erstmal Sinn, wirft aber die Frage auf, wie man dann im Fall von Refactorings oder nichtfunktionaler Anforderungen mit OKRs arbeiten kann, schliesslich soll dabei ja keine Änderung spürbar sein. Jeff Gothelfs eigentlich naheliegende Antwort: in solchen Fällen sollte darauf hingearbeitet werden, dass Käufer oder Nutzer ihr Verhalten nicht ändern. Eigentlich einfach.

Montag, 29. Dezember 2025

Kommentierte Links (CXXXIV)

Grafik: Pixabay / Brian Penny - 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.

John Cutler: Product Operating Models vs Operating Systems (Part I, Part II)

In den letzten Jahren ist das "Product Operating Model" zu einem beliebten Buzzword in der Welt der Manager und Unternehmensberater geworden, häufig verbunden mit der Ankündigung, es im eigenen Unternehmen, bzw. beim Kunden einführen zu wollen. Das das nicht ganz so einfach ist, kann man sich denken, und John Cutler zeigt auf warum: ein Operating Model ist per Definition so abstrakt, dass es an den jeweiligen Kontext angepasst werden muss. Da beginnen dann die Schwierigkeiten.

Roman Pichler: Should Product Teams be Self-Managing?

In den Produktmanagement- und Agile-Communities dürfte diese Frage fast durchgehend mit ja beantwortet werden - (gute) Product Teams müssen selbstorganisiert sein. Wie das im konkreten Fall aussehen soll ist dann schon weit weniger klar (siehe oben). Roman Pichler nennt daher einige zentrale Erfolgsfaktoren: die Team-Zusammenstellung, das Zusammenarbeitsmodell, den Handlungsspielraum, die Führung und die Förderung.

Andi Roberts: Why Tuckman’s model may no longer serve 21st century teams

Wenn wir über Tuckmanns Phasen-Modell sprechen (Forming, Storming, Norming, Performing, Adjourning) muss uns bewusst sein, dass es keine empirisch überprüfbare Regelmässigkeit ist, sondern ein in der Realität kaum auftretendes Ideal. Alternative Ansätze wie dieser hier von Andi Roberts sind daher hochgradig sinnvoll, allerdings handelt es sich in seinen eigenen Worten zunächst nur um ein mögliches Vorgehen, also eines, für das noch Erfahrungswerte fehlen.

Jessica Wolfe: Rethinking “The Developer” - Builders, Modernizers, Orchestrators

Um die oft komplexe Realität für uns begreifbar zu machen, neigen wir Menschen zur Bildung von Kategorien oder Gruppen, denen wir dann gemeinsame Merkmale zuschreiben. Dass wir dabei manchmal über das Ziel hinausschiessen, zeigt Jessica Wolfe am Beispiel der Gruppe der Software-Entwickler. Die ist in der Realität keineswegs einheitlich, sondern umfasst verschiedene, sehr kontextspezifische Ausprägungen, mit denen jeweils eigene Interaktionsformen Sinn machen.

Mike Fisher: When Change Outruns Us

Eine der Regeln für den totalen Stillstand in Unternehmen lautet, dass die Geschwindigkeit auf der Beschlussebene höher sein sollte als die Geschwindigkeit auf der Umsetzungsebene. Mike Fisher zeigt in diesem Text auf, dass das mehr als nur eine Pointe ist - in vielen Firmen ist es ein ernsthaftes Problem, das dort die Profitabilität, Innovationsfähigkeit und Handlungsfähigkeit massiv einschränken kann. Und er gibt auch Ratschläge, wie sich Veränderungen nachhaltiger gestalten lassen.

Freitag, 26. Dezember 2025

Silent Code

Es ist ja die besinnliche Zeit - passend dazu gibt es besinnliche Musik. 


Dienstag, 23. Dezember 2025

Überwintern

Bild: Pixabay / Fabio Piccini - Lizenz

Es gibt Phasen, in denen machen agile Transitionen eine Pause. Ein neues Management kommt, will durchregieren und alles kontrollieren, langfristige Detailplanungen machen, die Arbeit in Gewerke oder Wasserfall-Stufen aufteilen, Herrschaftswissen aufbauen und dergleichen mehr. Das ist unschön, zumindest in grossen Organisationen aber temporär - der nächste Management-Umschwung kommt so sicher wie der nächste Frühling. Irgendwann gibt es dann wieder Transparenz und Selbstorganisation.


Die typische Reaktion von Konzernmitarbeitern mit Neigung zu solchen Arbeitsweisen ist es, in einen "Überwinterungszustand" zu gehen. Man zieht sich von der Vorderbühne der Organisation zurück, sucht sich einen geschützten Raum (Projekte, Abteilungen, etc), in dem der Veränderungsdruck erträglich erscheint, und bildet dort mit anderen gleichgesinnten eine Schläferzelle, die wieder aktiviert werden kann, wenn der Management-Wind sich erneut dreht.


Derartige Überwinterungen werden häufig vom Management eher kritisch gesehen, da hier ein Unterlaufen der aktuellen Unternehmensführung gesehen wird. Man kann aber auch eine positive Sicht darauf haben - wer in die Überwinterung geht, macht die Bühne frei für andere, die vom aktuellen Vorgehensmodell überzeugter sind, gibt ihnen die Chance sich zu beweisen, bewahrt aber die eigene Expertise, für den Fall, dass sie doch gebraucht wird.


Die spannende Frage, die sich daraus ergibt, ist aber, wie der Expertisen-Erhalt in einer Überwinterungs-Phase stattfinden kann? Der offizielle Arbeitsmodus ist schliesslich ein anderer, so dass Learning by Doing (oder Sustaining by Doing) nicht mehr so einfach möglich sind wie vorher. Und auch das Budget für Weiterbildungen und Schulungen wird jetzt für andere Zwecke eingesetzt. Hier sind einige praxiserprobte Ideen wie das gelingen kann.


Agile Ausgestaltung anderer Termine und Prozesse

Auch in einem formal nicht-agilen Arbeits-Setting spricht nichts dagegen, den Tag mit einer Morgenrunde zu beginnen, in dem jeder ein Update dazu gibt woran er gerade arbeitet, wie er vorankommt oder wo er Hilfe brauchen könnte. In Status-Meetings kann man Feedback integrieren, in Abteilungs- oder Projektmeetings Verbesserungsideen, etc., etc.


Arbeit an technischer Exzellenz

Ein spannender Fall von notwendiger und hinreichender Bedingung: man kann ohne technische Exzellenz nicht agil arbeiten, aber ohne agil zu arbeiten technische Exzellenz vorantreiben. Von Clean Code über hohe Testabdeckung bis hin zu klarer Architektur - das alles hilft in jedem Arbeitsmodus, und es kann später wieder eine gute Ausgangsbasis für iterativ-incrementelles Arbeiten sein.


Lösungsorientiertes Vorschlagswesen

Selbst wenn man in einem hierarchisch organisierten Umfeld vieles nicht selbst entscheiden kann - Vorschläge machen kann man immer. Und wenn die zum Gegenstand haben, dass sich irgendetwas mit vertretbarem Umwand so umstellen lässt, dass es schneller, billiger oder in besserer Qualität fertig wird, dann ist die Wahrscheinlichkeit gross, dass man Gehör findet.


Nutzung leichtgewichtiger Tools

Es müssen nicht immer Jira und Miro sein, in fast jeder Firma finden sich mittlerweile Tools, die kollaboratives Arbeiten ermöglichen. Um ein einfaches Beispiel zu nennen: geteilte Präsentationen in Google Docs oder Microsoft 365 können mittlerweile in Meetings ähnlich genutzt werden wie Miro oder Conceptboard (siehe hier). Man muss nur bereit sein, etwas herumzuprobieren.


Feedback auf dem kurzen Dienstweg

Nur weil es keine Sprint Reviews gibt heisst das nicht, dass man mit Kollegen und internen Anwendern nicht sprechen kann. Vom schnellen Abstimmungscall über gemeinsames Kaffeetrinken bis hin zum Sitzen an benachbarten Arbeitsplätzen (wenn es im Büro flexible Platzwahl gibt) ist vieles möglich, um einfache und schnelle Kommunikation möglich zu machen.


Über den Tellerrand blicken

Auch über die unmittelbare eigene Arbeitsumgebung hinaus gibt es Möglichkeiten, die eigene "agile Expertise" zu erhalten und auszubauen. Geld für Konferenzen und Schulungen mag keines da sein, aber in fast jeder grösseren Stadt gibt es einen Scrumtisch, einen Lean Coffee oder ähnliche Meetups auf denen man sich austauschen und dazulernen kann.


Wie immer bei derartigen Listen ist es auch bei dieser so, dass sie noch lange weitergehen könnte, die Grundidee ist aber klar: auch in einem offiziell nicht-agilen Arbeitsumfeld lässt sich viel machen, um auch während einer Überwinterungsphase noch agil arbeiten und lernen zu können. Gegebenenfalls nicht mit den sonst üblichen Begriffen, Tools und Methoden, aber orientiert an den darunterliegenden Ideen und Prinzipien. Und das ist schliesslich das eigentlich Wichtige.


Und ganz nebenbei: auch wenn es länger dauern sollte bis auch offiziell wieder agil gearbeitet werden kann - die Dinge die weiter oben stehen machen auch jeden anderen Arbeitsmodus effektiver. Ein weiterer Grund dafür, sie zu tun.

Freitag, 19. Dezember 2025

The agile Bookshelf: Range

Falls jemand noch ein Buch zum Verschenken sucht - Range: Why Generalists Triumph in a Specialized World ist sehr empfehlenswert. Geschrieben wurde es vom amerikanischen Journalisten David Epstein, und er hat mit ihm das Kunststück vollbracht, ein Werk zu schreiben, das für gleich mehrere unterschiedliche Bereiche relevant ist: Erziehung, Karriereplanung, Persönliche Entwicklung, Personalentwicklung, Organisationsentwicklung und mehr.


Der Entstehungshintergrund des Buches ist eine zu Beginn des 21. Jahrhunderts stattfindende Debatte darüber, ob eine möglichst frühe, und idealerweise bereits in der Kindheit beginnende, Spezialisierung der beste Weg zu überdurchschnittlichen Leistungen in einem Wissensgebiet oder Tätigkeitsfeld ist. In der allgemeinen Wahrnehmung wurde das eher bejaht, und mit Verweisen auf "Wunderkinder" wie Tiger Woods oder Wolfgang Amadeus Mozart belegt.


In dieser Zeit fiel Epstein bei seinen Recherchen zu seinem vorherigen Buch The Sports Gene auf, dass es zahlreiche Fälle von Spitzensportlern gab, deren Karriere genau gegenteilig verlief - bis in in ihre jungen Erwachsenenjahre wechselten Sie zwischen verschiedenen Sportarten, bevor sie sich für eine entschieden. Und sie benannten diese grosse Bandbreite nicht etwa als ein Hindernis für ihren Erfolg, sondern sogar als einen der wichtigsten Erfolgsfaktoren.


Aufmerksam geworden begann er zu recherchieren, ob diese Abweichungen von der angenommenen Wahrheit der sinnvollen frühen Spezialisierung auch ausserhalb des Sports auftraten, und wurde auch dort fündig. Egal ob in Wirtschaft, Wissenschaft, Kunst oder anderen Bereichen, überall gab es Karrieren, in denen sich Schwerpunkte erst spät oder nur temporär herausgebildet hatten, von Charles Darwin über Albert Einstein und Roger Federer bis Mark Zuckerberg.


Alleine die Erkenntnis, dass frühe Spezialisierung nicht der beste oder einzige Weg zum Erfolg ist, war bereits bemerkenswert, darüber hinaus fand Epstein aber einen Bereich, in dem vielfältig, generalistisch oder fachfremd ausgebildete Menschen bessere und schnellere Lösungen fanden als die, die sich schon früh auf nur ein Thema focussiert hatten - bei neuartigen oder komplexen Problemen. Hier war es offensichtlich von Vorteil, einen breiten Erfahrungshorizont zu haben.


Range: Why Generalists Triumph in a Specialized World ist eine Leseempfehlung, weil es eine seltene Kombination verschiedener Aspekte ist. Es regt zum Denken an und hinterfragt scheinbare Gewissheiten, es ist mit zahlreichen Fakten und Belegen untermauert, es ist flüssig und unterhaltsam geschrieben und es enthält Anstösse, die man im  eigenen Berufs- und Privatleben umsetzen kann.

Montag, 15. Dezember 2025

Trust as Infrastructure

Trotz aller künstlichen Intelligenz - am Ende sind es Menschen, die Software erstellen. Auf diese Prämisse baut Bryan Cantrill seinen Vortrag auf, in dem er das Vertrauen in die Menschen in den Software-Entwicklungsorganisationen zu einer zentralen Infrastruktur der IT-Industrie erklärt. Dieses Vertrauen muss gegeben sein, da in einem komplexen Umfeld vollständige Kontrolle nicht möglich ist.



Spannend ist dabei, dass Cantrill das Thema Vertrauen von seiner verbreitetsten Interpretation löst, nämlich dem, dass es eine auf einzelne Personen bezogene positive Erwartung ist. Stattdessen arbeitet er heraus, dass es in Organisationen oder Bewegungen (wie der Open Source-Bewegung) ein ganzes Geflecht verschiedenster Vertrauensbeziehungen innerhalb zwischen verschiedenen Gruppen geben muss, wenn irgendetwas funktionieren soll.

Freitag, 12. Dezember 2025

Wie der Staat wieder handlungsfähig wird (IV)

Manchmal finden die spannenden Sachen direkt vor der eigenen Haustür statt, wie in dieser Woche die Fachkonferenz Public Sektor und Beratung in Bonn. Vertreter verschiedener grosser und kleiner Beratungsfirmen (u.a. meiner) könnten hier mit Experten aus dem Bundesministerium für Digitales und Staatsmodernisierung, dem Landesrechnungshof, dem Bundesverwaltungsamt und anderen Behörden diskutieren, wie die öffentlich Verwaltung effektiver arbeiten und beraten werden kann


Ein Thema, das sich dabei durch fast alle Vorträge und Diskussionen zog, war dabei das staatliche Einkaufswesen, bzw. dessen Unzulänglichkeiten. Mehrere Sprecher gingen sogar soweit, die hier nötigen Reformen zum entscheidenden Erfolgsfaktor der Verwaltungsmodernisierung zu erklären. Da er einen derartig prominenten Status zu haben scheint, lohnt sich ein näherer Blick auf die Konferenz-Erkenntnisse - was liegt denn laut Expertenmeinung im Argen im staatlichen Einkauf?


Beauftragende Stellen und Einkaufsabteilungen sind oft schlecht abgestimmt

Einer der schlimmsten Punkte direkt zu Beginn: der Einkauf und die Menschen für die etwas eingekauft wird reden in vielen Fällen zu wenig miteinander. Wenn z.B. eine kleine Behörde einen IT-Administrator braucht, fragen viele Einkäufer nicht nach für welche Systeme oder mit welchen benötigten Fähigkeiten, sondern googlen nur danach, was man dafür können müsste, und übernehmen das dann unverändert.


Viele Ausschreibungen sind inhaltlich irreführend oder sogar falsch

Vor diesem Hintergrund ist es wenig überraschend, dass viele eingekaufte Leistungen komplett am Bedarf vorbeigehen. Ein Beispiel das auf der Konferenz genannt wurde war eine Behörde, die auf der Suche nach jemandem war, der in der Poststelle physische Werbesendungen aussortieren sollte. Beauftragt wurde jemand, der Spezialist für Spamfilter in Email-Programmen war.


Zusammengehörende Gewerke werden separat ausgeschrieben

Dieser Missstand hat einen erkennbaren Taylorismus-Ursprung. Statt zusammengehörende Leistungen gemeinsam zu beauftragen, werden sie oft künstlich getrennt und separat vergeben. Ein Beispiel war ein IT-System das von einem Dienstleister kontinuierlich weiterentwickelt wurde, während ein zweiter die Nutzer darin schulen sollte - ohne zu wissen, was daran zuletzt geändert worden war.


Die Ausschreibungen sind oft unnötig detailliert

Hier kann man zumindest den Wunsch unterstellen, genau das Richtige einzukaufen. In der Realität kommt es aber immer wieder zu einem absurden Detailgrad, etwa dann, wenn ein Dienstleister nicht nur für alle Mitglieder seines Teams die Schul- und Hochschulzeugnisse angeben soll, sondern auch an welchen Kalendertagen diese Zeugnisse jeweils ausgestellt wurden.


In vielen Ausschreibung stehen unrealistische Anforderungen

In diesen Fällen zeigt sich, wie viele Detailkenntnisse die jeweiligen Einkäufer haben. Immer wieder genannte Klassiker sind die Anforderungen nach fünf- oder zehnjähriger Erfahrung mit Technologien, die es noch gar nicht so lange gibt (z.B. modernen LLM-Anwendungen). Die Zahl der Fälle, in denen wegen derartiger unerfüllbarer Anforderungen kein einziges Angebot eingeht, ist anscheinend beträchtlich.


Selbst kleine Formfehler können zum Ausschluss führen

Ein Beispiel, dass ich selbst erlebt habe: beim Nachfassen wegen eines abgegebenen Angebots wurde mir mitgeteilt, dass wir aussortiert worden waren, da der angebotene Berater keine PSM II-Zertifizierung hatte. Was in unseren Unterlagen stand - er hatte eine PSM 2-Zertifizierung. Inhaltlich das Selbe, aber da wir arabische statt römischer Zahlen benutzt hatten, waren wir draussen.


Die Vergabekriterien sind oft sehr unklar

Um mit dem Positiven zu beginnen: es wird oft versucht, den Entscheidungsprozess transparent zu machen, etwa indem angegeben wird, durch welchen Faktor wieviele Bewertungspunkte zu erreichen sind. Bei einer Angabe wie "Konzept: 20 Punkte" (ein reales Beispiel) bleibt aber völlig offen, anhand welcher Kriterien das einzureichende Konzept bewertet wird.


Zu häufig gibt nur der Preis den Ausschlag

In der Theorie ist zwar der Preis nur eines von mehreren Entscheidungskriterien, in der Realität vieler Beratungs-, Bau- und IT-Projekte wird aber sehr häufig das billigste Angebot angenommen, das gaben die Behördenvertreter auf der Konferenz zu. Da niedrige Preise aber vor allem durch Niedriglohn-Personal und billiges Material möglich werden, bedeutet das meistens auch schlechte Qualität der Ergebnisse.


Ausschreibung ≠ Beauftragung

Für die an Ausschreibungen teilnehmenden Unternehmen einer der grössten Frustfaktoren: anders als man denken könnte, ist der Gewinn einer Ausschreibung oft nicht mit einer Beauftragung gleichzusetzen. Man gewinnt nur einen Rahmenvertrag, ob in dessen Rahmen wirklich die eigentliche Beauftragung stattfindet ist unklar. Viele Behörden schreiben "auf Vorrat" aus, nicht wegen akutem Bedarf.


Die Liste liesse sich noch ewig fortsetzen, auf der Konferenz wurden noch zahlreiche weitere Ärgernisse genannt, von ausufernden Dokumentationspflichten über in der Realität nur schlecht funktionierende juristische Konstruktionen wie das 3 Partner Modell/3PM bis zu dreisten Forderungen wie einer unbezahlten Einarbeitungszeit. Aber genug gejammert, wie ginge es besser?


Worüber sich fast alle Konferenzteilnehmer einig waren: zusätzliche Vorschriften, Richtlinien und Verbote für die staatlichen Einkaufsabteilungen wären keine Lösung, sondern würden nur zu noch mehr Bürokratie führen. An vielen Stellen wäre es vielmehr sinnvoll, der Regulierungsumfang zurückzufahren, da er ein wesentlicher Grund für das Ausufern der Einkaufsprozesse ist.


Ein zielführenderer Ansatz wäre eine bessere Qualifizierung und Begleitung der staatlichen Einkaufsabteilungen. Diese sind bisher in vielen Fällen von Umfang und Komplexität der Materie überfordert. Man denke z.B. an eine Kleinstadt, die durch die Übernahme einer aufgegebenen Kaserne ein Bauprojekt noch nie dagewesener Grösse stemmen muss. Woher soll dafür die Kompetenz kommen?


Für die Qualifizierung und Begleitung der Mitarbeiter in derartigen Behörden gibt es tatsächlich bereits mehrere staatliche Stellen, die als "Inhouse Consulting" der öffentlichen Verwaltung funktionieren, etwa das Beratungszentrum des Bundes oder das Auftragsberatungszentrum Bayern. Ein erster Schritt wäre es, diese relativ unbekannten Angebote bekannt zu machen.


Auch weitere Ideen gibt es, etwa den auf der Fachkonferenz Public Sektor und Beratung vorgestellten "Berater-Führerschein". Angedacht ist, dass diese Weiterbildung für jeden verpflichtend wird, der Beratungsaufträge ab einer bestimmten Höhe vergeben darf. Die Idee ist, durch ihn nicht nur Wissen über den Einkauf, sondern auch über die Steuerung und Effizienzmessung von Beratern zu vermitteln.


Die Gemeinsamkeit derartiger Ansätze: den auf diese Art qualifizierten Einkäufern wird danach grösserer Freiraum gelassen, in dem Vertrauen, dass ja auch sie selbst ein Interesse an einer möglichst reibungslosen und erfolgreichen Abwicklung ihrer Einkaufsprozesse haben. Und als Seiteneffekt wird der Beruf dadurch auch attraktiver.


Siehe auch: 

Steve Blank: The Department of War Just Shot the Accountants and Opted for Speed

Dienstag, 9. Dezember 2025

Agile Bauprojekte (IX)

Bild: Pexels / Javier Gonzalez - Lizenz

Der grosse Hype um das Thema Künstliche Intelligenz (KI/AI) ist nicht mehr ganz so ausgeprägt wie er es kurz nach dem Markteintritt von ChatGPT & Co war. Eigentlich gut so, denn jetzt kann man mit etwas nüchternerer Betrachtung bewerten, wo dadurch ein wirklicher Mehrwert erbracht wird. Einer der Bereiche in denen das stattfindet ist das Baugewerbe, und die Technik die hier im Einsatz ist, trägt einen relativ unbekannten Namen: Parametric Design.


Kurz zum Kontext: beim Bauen von Gebäuden kann man anders als beim Maschinen- und Gerätebau nicht mit einem Prototypen beginnen, aus ihm lernen und einen besseren bauen. Was einmal steht lässt sich nur teuer wieder abreissen. Die ersten Ergebnisse (wenn man von Design-Skizzen absieht) bestehen hier daher aus Berechnungen der Statik und der Materialbelastbarkeit der zukünftigen Gebäude. Erst wenn die fertig sind, kann das eigentliche Bauen beginnen.


Da diese Berechnungen aufgrund der zahlreichen Parameter (u.a. Höhe, Breite, Grösse der Innenräume, Material, Untergrund, Wetter) sehr umfangreich sind, führten sie bis ins 21. Jahrhundert fast durchgehend zu langen vorgelagerten Planungsphasen. Waren diese einmal abgeschlossen, war ein nachträgliches Anpassen kaum möglich (und wenn es erzwungen wurde sehr teuer, wie im Fall des Berliner Flughafens). Das Vorgehen war also eher Anti-Agil.


Mit dem Aufkommen von KI-Anwendungen hat sich das geändert, vor allem aufgrund des genannten parametrischen Designs. Bei ihm werden nur bestimmte Rahmenbedingungen (Parameter) fest vorgegeben, etwa Stabilität und zu tragende Last. Das System wird dann angewiesen, unter Respektierung dieser Vorgaben Lösungsvarianten für einen Design-Entwurf zu erstellen. Das kann dann deutlich schneller erfolgen als durch einen Menschen.


Zu Beginn wurde diese Technik vor allem für Gebäudepläne eingesetzt, bei denen eine Berechnung durch Menschen extrem lange gedauert hätte, die aber auch mit KI noch langwierig waren (z.B. bei den Setas de Sevilla von 2011). Mit dem Fortschritt in der KI-Technologie ist das aber noch einmal deutlich beschleunigt worden - bei aktuellen Vorhaben, wie dem West Bund Convention Center in Shanghai, konnte eine komplette Neuberechnung im wahrsten Sinn des Wortes über Nacht erfolgen.


Damit ist agiles Arbeiten jetzt auch in der frühen Planungs- und Berechnungsphase eines Bauvorhabens möglich. In wenigen Tagen können umsetzbare Entwürfe entworfen, berechnet und vorgestellt werden, und das bei Bedarf mehrfach nacheinander oder parallel zueinander. Und wenn dann beim eigentlichen Bauen noch modulare Konstrktion oder 3D-Druck zum Einsatz kommen, kann das Bauen von Gebäuden ähnlich schnell möglich werden wie das von Software.