Kommentierte Links (LXXV)

Grafik: Pixabay / The Digital Artist - Lizenz

Kai Pukall: Kann man Businesswert messen?

Das Thema Business Value, bzw. dessen Bestimmung und Messung ist einer der grossen Klassiker für agile (und nicht-agile) Teams, Produktmanager und Unternehmen. Was Kai Pukall hier zurecht anmerkt ist, dass es sich dabei grösstenteils um Business-Theater handelt. Die Zukunft vorauszusagen (und mit ihr die Gewinne oder Einsparungen die sich mit einem Produkt oder Feature erzielen lassen) ist nicht möglich, aber ganz umsonst ist die Beschäftigung mit dem Thema nicht - es lassen sich so Indikatoren, Wahrscheinlichkeiten und Risiken identifizieren. Aus meiner persönlichen Erfahrung würde ich noch einen weiteren oft unterschätzten Mehrwert von Business Value-Diskussionen einwerfen: sie helfen dabei Anforderungen aus den Backlogs und Roadmaps herauszunehmen die fast keinen Wert haben, aber trotzdem irgendwann eingeplant wurden. Das ist oft schmerzhaft, bringt aber sehr viel.

Neil Rahilly, Casey Winters, Fareed Mosavat, Keya Patel: The art of removing features and products

Apropos herausnehmen. Was hier ein "Autorenkollektiv" aus den Firmen Reforge und Mixpanel zusammengetragen hat ist die umfangreichste Auseinandersetzung mit dem Thema des Ausbauens von Produkt-Features die ich bisher gelesen habe. Angefangen bei den Gründen dafür (Spoiler: es gibt auch gute Gründe für das Entfernen von Features deren Einführung Sinn gemacht hat), über die technischen, menschlichen und wirtschaftlichen Probleme die dabei auftreten können bis hin zu den Erfolgsfaktoren und notwendigen oder hilfreichen organisatorischen Rahmenbedingungen. Ein Text der jedem Product Owner und Produktmanager wärmstens zu empfehlen ist.

Steve Denning: How To Lead Change From Anywhere

Vor allem in grossen Organisationen ist eines der grössten Hindernisse für positive Veränderungen die weit verbreitete Meinung, selbst nicht der Lage zu sein dazu beitragen zu können (→ Untertanenkultur). Dass das nicht so ist wird zwar von Change Managern und Agile Coaches immer wieder betont, wie es vor sich gehen kann wird aber häufig nicht gesagt. Steve Denning stösst in diese Lücke und gibt eine gute Anleitung zum Verändern einer Organisation "von unten". Wie immer muss zwar auch hier klar sein, dass es sich um eine Inspiration handelt und nicht um eine Blaupause, es ist aber auf jeden Fall vieles dabei was sich in fast jedem Kontext anwenden lässt.

Jason Yip: Making the rules explicit becomes more critical shifting from co-located to remote

Das Explizit machen von Regeln ist einer der grossen Klassiker im Rahmen agiler Transitionen und führt immer wieder zu wertvollen Erkenntnissen. Das gilt bereits dann wenn Teams in Co-Location zusammensitzen, es gilt aber nochmal verstärkt im Fall von Remote-Arbeit. Was Jason Yip völlig zu Recht anmerkt ist, dass in diesem Fall die implizite Kommunikation wegfällt, sowohl in Bezug auf das weniger sichtbar werdende Verhalten der anderen Teammitglieder als auch in Bezug auf die abnehmbare Sichtbarkeit der Aktionen von Experten und erfahrenen Kollegen, an denen andere (bewusst oder unbewusst) ihre Handlungen ausgerichtet haben. Yip geht soweit, dass er nicht nur das Explizit Machen von Arbeits- und Entscheidungsprozessen sondern auch von Informationsströmen empfiehlt, um so in Summe alles abzubilden was für die Produktentwicklung relevant ist.

Gojko Adzic: Nijute - how to solve impossible problems

Ich gebe zu, auch ich neige vermutlich manchmal dazu, im Kanban-Umfeld (zu) viele japanische Lehnwörter zu benutzen. Aus diesem Grund fühlte ich mich leicht ertappt als Gojko Adzic mit seinem japanisch klingenden (?) Begriff "Nijute" ein bisschen die Agile-Community trollte, bei dem es sich in Wirklichkeit um die Abkürzung für "Not Impossible, Just Too Expensive" handelt. Unanhängig von diesem Hintergrund kann man ihm nur zustimmen, dass "möglich, aber zu teuer" bei Machbarkeitsdiskussionen ein besseres Argument ist als das häufig benutzte "das geht nicht". Weshalb das so ist und warum hinter dieser Aussage mehr steckt als im ersten Moment zu vermuten kann man schön herausgearbeitet bei ihm nachlesen.

2001 Agile vs 2021 Agile

Grafik: Pixabay / Bytrangle - Lizenz

Während der letzten Monate ist Jeff Patton, einer der bekannten Vordenker der agilen Bewegung, in zwei Podcasts zu Gast gewesen, die ich zufällig kurz nacheinander gehört habe (nachzuhören hier und hier). Unter seinen vielen anregenden Denkanstössen stach in beiden Auftritten einer heraus: in Pattons Wahrnehmung haben wir heute ein anderes Verständnis von Agilität als die Verfasser des Manifests für agile Softwareentwicklung vor 20 Jahren, denen wir den Begriff immerhin verdanken.

Das ist insofern bemerkenswert, da das agile Manifest eigentlich als zeitlos gültiges Dokument konzipiert wurde und von seinen Verfassern und dem überwiegenden Teil der "agilen Bewegung" auch bis heute noch so gesehen wird. Patton vertritt hier also eine Minderheits-Meinung, wenn auch eine die er gut begründen kann. Und angesichts seiner anerkannten Verdienste und Expertise ist diese Meinung eine nähere Betrachtung wert.

Ein zentraler Unterschied zwischen den Verständnissen von 2001 und von 2021 den er sieht, ist die unterschiedliche Bedeutung von Product Discovery, Outcome-Orientierung und Erfolgsmessung. Seiner Auffassung nach spielten diese schon im New New Product Development Game vorhandenen Konzepte auf der legendären "Leightweight Methods Conference" in Snowbird/Utah keine Rolle, während sie heute aus agiler Produktentwicklung nicht mehr wegzudenken sind.

Was er dagegen im agilen Manifest noch sehr stark wahrnimmt, ist eine Betonung des Delivery-Aspekts, die er an den Formulierungen "deliver working software frequently" und "working software is the primary measure of progress" festmacht. Die Ursache dafür sieht er in den Berufen der Verfasser des agilen Manifests, bei denen es sich grossteils um externe Berater und Entwickler handelte, deren Beruf weniger aus Produktinnovation und mehr aus der Umsetzung von Kundenaufträgen bestand.

Ein dritter Unterschied liegt für ihn im technischen Fortschritt begründet - 2001 wurde Software noch auf CDs und DVDs verschickt und war nach dem Absenden für die Entwickler nicht mehr erreichbar, diese mussten also möglichst perfektionistisch arbeiten. Abweichend davon machen die heute durchführbaren Updates über das Internet es möglich, auch frühe und noch unperfekte Versionen auszuliefern und sie im laufenden Betrieb kontinuierlich zu optimieren und zu erweitern.

Soviel zu Pattons zentralen Punkten, jetzt zur eigentlich interessanten Frage - hat er recht? Die nicht ganz befriedigende Antwort: in gewisser Weise schon, je nach Sichtweise aber auch nicht. Er hat recht damit, dass Product Discovery, Outcome-Orientierung, Erfolgsmessung und Continuous Delivery im Manifest für agile Softwareentwicklung nicht explizit genannt werden. Aber - wenn man es möchte lassen sie sich implizit aus den anderen Punkten ableiten, z.B. Continuous Delivery aus dem "Constant Pace".

Vielleicht ist aber auch gerade das eine Besonderheit dieses Dokuments: obwohl sich die Nutzergewohnheiten, Produktlebenszyklen und technischen Rahmenbedingungen über die letzten 20 Jahre deutlich verändert haben lässt es sich für jeden Zeitpunkt dieser Spanne so interpretieren, dass eine für diesen Moment passende Interpretation von Agilität entsteht. Damit wäre es also doch zeitlos (was Pattons Denkanstösse übrigens nicht weniger wertvoll macht).

Nachtrag:

Zum Thema Agile 2001 vs Agile 2021 passt auch diese Äusserung von Ron Jeffries, einem der Unterzeichner des Manifests:

Quelle: Twitter

Begriffs-Entfrachtung

Bild: Wikimedia Commons / Rohit Choudhary Raj - CC BY-SA 3.0

Zu den grossen Problemen nahezu aller agilen Transformationsvorhaben (und auch vieler Firmen die ihre Arbeitsweisen bereits umgestellt haben) gehört die Unklarheit des Begriffs "Agil". An keiner Stelle (auch nicht im Manifest für agile Software-Entwicklung) wird definiert was genau darunter zu verstehen ist, man kann lediglich versuchen es sich aus dem Kontext herzuleiten - in irgendeiner Form läuft es auf beweglich, schnell und reaktionsfähig heraus, völlig klar wird es aber nicht.

Diese Unklarheit hat mit der Zeit dazu geführt, dass der Begriff mitunter sehr weit ausgelegt und manchmal sogar erweitert wird. Immer wieder werden verschiedene ähnliche, verwandte oder nicht im Widerspruch stehende Konzepte zu (halb)offiziellen Elementen der Agilität erklärt. Das ist in verschiedener Hinsicht problematisch: zum einen wird die Umsetzung unnötig eingeengt, zum anderen liefert es all jenen Munition die nach Gründen suchen um das Konzept ablehnen zu können.

Um die Diskussion und die Umsetzung wieder zurück zu Klarheit, Offenheit und Realismus zu führen kann es nötig sein den Begriff zu "entfrachten" ihn also von allem zu befreien was ihm nachträglich aufgeladen wurde. Das macht sowohl zu Beginn agiler Transitionen Sinn als auch bei Firmen und Teams die schon länger so arbeiten, bei denen sich aber (ggf. unbemerkt) derartige Überfrachtungen eingeschlichen haben.

Vermutlich das häufigste Überfrachtungselement ist die Überzeugung, dass agiles Arbeiten erfordert, "dass jeder alles kann". Abgeleitet von dem Wunsch Crossfunktionalität zu haben und Flaschenhälse zu vermeiden ist die Grundidee Wissen zu verteilen zwar richtig, in diesem Extrem führt sie aber entweder dazu, dass die Betroffenen sich überfordert fühlen oder dazu, dass sie unverhältnismässig viel Zeit für Lernen und Ausprobieren einfordern.

Ein weiteres Element mit dem agile Arbeitsweisen überfrachtet werden ist Basisdemokratie. Vermutlich ausgehend von den hohen Mitbestimmungsrechten der agilen Teams stösst man in vielen Organisationen auf Menschen die der Meinung sind, dass in einem "wirklich agilen" Unternehmen auch über Entscheidungen zu Produktstrategie oder Stellenbesetzungen abgestimmt werden müsste. Aber bei aller Liebe zur Demokratie - um schnell liefer- und reaktionsfähig zu sein braucht man sie nur bedingt.

Oft mit der Forderung nach Demokratie einhergehend kommt als drittes Überfrachtungselement der Konsens-Zwang. Ohne dass klar ist wie diese Idee entstanden ist herrscht in vielen Teams die Überzeugung vor alle Entscheidungen einstimmig treffen zu müssen, mitunter wird auch gefordert das auf grössere Organisationseinheiten zu übertragen. Hier droht sogar das Gegenteil von Agilität - lähmende Dauer-Debatten bis endlich alle zustimmen.

Ebenfalls immer wieder anzutreffen ist die Überzeugung, dass konsequent agil arbeitende Firmen ihren Kunden jeden denkbaren Wunsch erfüllen müssten. So naheliegend das angesichts des hohen Wertes der Kundenorientierung auch klingt, stimmen tut es nicht. Spätestens bei dem (menschlich verständlichen) Kundenwunsch immer die höchste Qualität zum niedrigsten Preis haben zu wollen muss sich die Frage nach der Wirtschaftlichkeit stellen.

Und auch das kann in Extremfällen auftreten: die Überzeugung, dass agile Unternehmen eher gemeinwohl- als gewinnorientiert arbeiten müssten. Man kann die Ursache dafür vermutlich bei den amerikanischen XP- und Scrum-Teams der 90er Jahre finden, die sich ihre Handlungsfreiheit noch gegen das Shareholder Value-getriebene Management erkämpfen mussten, eine daraus abgeleitete grundlegende Ablehnung von Gewinnorientierung ist aber eher anarchistisch als agil.

Die Liste liesse sich noch weiterführen, die Grundproblematik ist aber klar: sobald sich die Überfrachtung des Begriffs "Agil" mit einem oder mehreren der hier genannten Aspekte in den Köpfen festgesetzt hat wird der Versuch so zu arbeiten eher zu Frustration und Unwillen führen als zu Erfolgen. Da dieses Antipattern in vielen Fällen aber unbewusst herbeigeführt wird oder schleichend und unbemerkt entsteht kann man es kaum verhindern. Also was tun?

Ein Lösungsansatz ist es, möglichst früh eine intern geltende "offizielle Definition" des Begriffs zu verfassen, idealerweise eine die sich auf die Kernaspekte der Liefer- und Reaktionsfähigkeit beschränkt und breit kommuniziert wird. Die kann dann regelmässig genutzt werden um sich zu fragen ob sich mittlerweile alte oder neue Überfrachtungselemente eingeschlichen haben, die dann wieder entfernt werden sollten.

Und bevor es zu Missverständnissen kommt: das heisst nicht, dass man diese Ideen nicht nutzen könnte. Wenn eine Organisation z.B. alles im Konsens entscheiden will, nur zu. Sie sollte das nur nicht deshalb tun weil es angeblich zur Agilität gehört.

Customer-Vendor Antipattern (II)

Bild: Pixabay / Suju-Foto - Lizenz

Würde man die populärsten Missverständnisse über Scrum sammeln gäbe es eines das ganz sicher weit oben in der "Beliebtheitsskala" auftauchen würde: das, dass sich der Inhalt eines Sprints nicht mehr ändern darf sobald er gestartet wurde. Gerade weil es so verbreitet ist lohnt sich ein näherer Blick. Worum geht es in diesem Missverständnis, wie konnte es zu ihm kommen und überhaupt - was ist eigentlich falsch daran?

Zunächst zur Erläuterung. Im Rahmen eines Sprints, also eines Zeitraumes von ein bis vier Wochen, liefert ein Scrum Team eine bestimmte Menge an Mehrwert ab, z.B. in Form neu programmierter Software-Features. Diese zu liefernden Features werden vor dem Sprint in Anforderungen beschrieben (häufig in Form von User Stories) und in das so genannte Sprint Backlog übernommen, das im Sprint abgearbeitet wird. An dieser Stelle steht dann häufig das Missverständnis: viele Menschen glauben, dass während des Abarbeitens keine Änderungen an diesen Anforderungen mehr stattfinden dürfen.

Wann dieser populäre Irrtum entstanden ist lässt sich zwar nicht mehr genau rekonstruieren, die mit ihm regelmässig mitgelieferten Begründungen lassen aber erahnen wie das geschehen sein dürfte. Von Product Owner-Seite heisst es meistens, dass die Entwickler sich durch Änderungen am Sprint-Inhalt aus den gemachten Zusagen herauswinden könnten, von Entwickler-Seite, das ihnen der Product Owner auf diese Weise zusätzliche Arbeit unterschieben könnte. Beides lässt tief blicken.

Was aus diesen Aussagen erkennbar wird ist, dass sich hier alle Beteiligten im Customer-Vendor Antipattern verfangen haben. Beide betrachten den Sprintumfang als das Ergebnis einer Verhandlung in der sie versucht haben der jeweils anderen das Maximum an Zugeständnissen abzuringen. Der Product Owner hat möglichst viele Anforderungen in den Sprint drücken wollen, die Entwickler dagegen haben deren Menge möglichst gering halten wollen um ohne Zeitdruck arbeiten zu können.

Auch eine ähnliche Variante kommt häufig vor: in ihr ist es nicht der Product Owner der den Entwicklern möglichst hohe Zusagen abringen will sondern es sind ausserhalb des Teams stehende Stakeholder. Der Product Owner befindet sich in dieser Konstellation entweder gemeinsam mit den Entwicklern in einer Abwehrhaltung oder eher befindet sich in einer Zwischenposition in der er es keiner der beiden Seiten recht machen kann.

Die Auswirkungen des Customer-Vendor Antipatterns können weit über das Team hinaus verheerend sein. Latentes Misstrauen im Refinement, erbittertes Feilschen im Planning, ein Gefühl des übervorteilt worden Seins im Review und gegenseitige Vorwürfe in der Retrospektive sind häufig auftretende Folgen dieser gegeneinander gerichteten Positionierung der Teammitglieder, die den Ruf der Beteiligten, der angewandten Methodik aber auch der diese Konflikte zulassenden Firma schwer beschädigen können.

Um es dazu nicht kommen zu lassen ist es dringend anzuraten bereits auf erste Zeichen dieses Antipatterns zu achten und ihnen von Anfang an entgegenzutreten. Das kann innerhalb des Teams durch Retrospektiven geschehen oder ausserhalb dadurch, dass übergriffige Stakeholder in ihre Schranken gewiesen und die Autorität des Product Owners ihnen gegenüber gestärkt wird, es kann aber auch durch Arbeit an den Rahmenbedingungen geschehen.

Die einfachste Art das zu tun führt dabei wieder zurück zum Beginn dieses Textes, denn sie besteht aus der Beseitigung des Missverständnisses, dass der Inhalt eines Sprints sich nicht mehr ändern darf sobald er gestartet wurde. Richtig ist in Scrum nämlich, dass der Sprintinhalt sehr wohl geändert werden kann (siehe hier), lediglich das Sprint-Ziel nicht. Mehr noch: der Sprint-Inhalt muss sogar geändert werden sobald das Sprint-Ziel gefährdet ist, um es zumindest in einer abgespeckten Version erreichen zu können. Und umgekehrt: wenn es früher als gedacht erreicht wird kann Arbeit nachgezogen werden.

Hat ein Scrum Team diese Vorgaben einmal verinnerlicht wird das Customer-Vendor Antipattern von sich aus nach und nach verschwinden, alleine deshalb weil alle mühsam erfeilschten zu grossen oder zu geringen Zusagen wieder ausgeglichen werden sobald klar wird, dass sie an der Realität vorbeigehen. Die Möglichkeit und damit auch der Anreiz den anderen zu übervorteilen entfallen einfach, und als Folge dessen gehen auch die schädlichen Verhaltensweisen zurück.

Sprintfähigkeit (wieder)herstellen

Bild: Pexels / Jonathan Borba - Lizenz

Auf den ersten Blick sieht Scrum wie eine Arbeitsweise aus auf die man sich einfach umstellen kann, der Scrum Guide scheint schliesslich lediglich den Sprint, die drei Rollen, die vier Meetings und die drei Artefakte vorzugeben. Das scheint sich schnell einführen zu lassen. Auf den zweiten Blick wird es allerdings deutlich schwieriger, denn das dritte der drei Artefakte hat es in sich: das Increment ist eine neue, benutzbare Produktversion, und davon muss es mindestens eine pro Sprint geben.

Wer schon einmal in einem komplexen Produktentwicklungs-Umfeld gearbeitet hat wird erkennen welche Herausforderung das bedeuten kann: die initialen Anforderungen müssen so geklärt sein, dass die Arbeit an ihnen sofort beginnen kann, das Team muss crossfunktional genug sein um nicht auf Zulieferungen warten zu müssen und Tests und Deployments müssen automatisiert sein um möglichst schnell stattfinden zu können.

Die wenigsten Teams die bisher in einem eher klassischen Umfeld mit bürokratischem Anforderungs-Management, starker Arbeitsteilung und vielen manuellen Arbeitsschritten gearbeitet haben werden aus dem Stand dazu in der Lage sein, mit dem Effekt, dass aus einem sofort gestarteten Sprint kein auslieferbares Increment entstehen kann (und aus den nächsten vermutlich auch nicht). Frustration und Enttäuschung wären die Folge.

Um es dazu nicht kommen zu lassen ist es wichtig, dass vor dem ersten Sprint die Grundlagen dafür geschaffen werden ihn überhaupt durchführen zu können. Es wird häufig versucht das in einen so genannten Sprint 0 zu packen, was aber nicht immer funktioniert. Gerade in grösseren Organisationen können Wochen und Monate dafür nötig sein, was den Begriff des Sprints völlig konterkarieren und unbrauchbar machen würde.

Zielführender ist es in solchen Fällen überhaupt erstmal die Sprintfähigkeit herzustellen bevor man mit Scrum beginnt. Das kann ein letztes mal in Form eines klassischen Projekts entstehen, es kann aber auch nach einem anderen mehr oder weniger agilen Vorgehen durchgeführt werden. Wichtig ist in jedem Szenario aber ein klares Zielbild: nur wenn nachvollziehbar definiert ist welche Kriterien für eine Sprintfähigkeit zu erfüllen sind ist klar wann diese Vor-Phase vorbei ist.

Ein Sonderfall dieser Situation tritt ein wenn ein bereits nach Scrum arbeitendes Team seine Sprintfähigkeit verliert, zum Beispiel durch Personalabgänge oder ausfallende Infrastruktur. Der Scrum-Begründer Ken Schwaber empfiehlt in diesem Fall (zumindest bei grösseren Vorhaben) so genannte Scrumble-Phasen, in denen die Sprints ausgesetzt werden und stattdessen an der Wiederherstellung der Sprintfähigkeit gearbeitet wird.

Elementar in beiden Varianten ist, dass in ihnen ein möglichst ausschliesslicher Focus darauf liegt an den Voraussetzungen für Scrum zu arbeiten. Wird parallel dazu bereits mit der Arbeit am Produkt begonnen, werden diese fehlenden Voraussetzungen dazu führen, dass sich nicht integrierte Arbeit anstaut oder Vorarbeiten durchgeführt werden die sich später ggf. nicht abschliessen lassen. Beides würde wieder zu den Problemen führen für deren Beseitigung Scrum eigentlich erfunden wurde, es wäre also nicht im Sinne der Idee.

Scrum goes Pop Music (II)

Als ich vor ein paar Monaten entdeckt habe, dass Chad Beier angefangen hat auf Scrum umgetextete Lieder neu aufzunehmen hatte ich direkt gehofft, dass noch weitere nachkommen. Tatsächlich wurde ich nicht enttäuscht, mittlerweile gibt es drei weitere. Mein persönliches Highlight ist die neue Version von Nirvanas Smells like teen spirit, aber auch die beiden anderen kann man sich gut anhören. Ich bin gespannt wieviele noch kommen werden.

Der Werkvertrag über agile Produktentwicklung

Bild: Pixabay / Aymenjed - Lizenz

Dass ich immer wieder an Phillipp Kühn vorbeikomme wenn es um das Thema Agilität und Verträge geht sagt viel Gutes über ihn aus und zeigt auf, dass er einer der (noch) zu wenigen Experten in diesem Bereich ist. In seinem aktuellen Auftritt im Scrum meistern Podcast greift er einiges von dem auf was er schon letztes Jahr in einem Vortrag in meiner Firma gesagt hat, er geht aber auch auf neue Aspekte ein. Einen davon möchte ich herausgreifen, da er auch mir schon wiederholt begegnet ist - die (falsche) Gleichsetzung von Werkvertrag und Festpreis.

Zur Einordnung: viele grosse Unternehmen versuchen ihre von externen Dienstleistern umgesetzten IT-Projekte über Werkverträge einzukaufen, was grundsätzlich auch Sinn macht. Egal ob es eine Server-Migration ist, ein Website-Relaunch oder die Ablösung eines Legacy-Systems - irgendwo sollte schliesslich geregelt sein was eigentlich die zu erbringende Leistung ist (in welchem Detailgrad das zu erfolgen hat wäre dabei nochmal ein Thema für sich).

Zu einem Problem wird diese Art des Einkaufs dadurch, dass im Verständnis vieler Einkaufsabteilungen ein Werkvertrag automatisch einem Festpreis-Vertrag entsprechen muss, also einer Abmachung bei der für die Werk-Erfüllung nur ein bestimmter Betrag zu bezahlen ist, und zwar unabhängig vom nötigen Umsetzungsaufwand und auch dann wenn dieser Aufwand durch sich ändernde Rahmenbedingungen von der ursprünglichen Schätzung abweicht.

Für den Einkäufer ist diese Art der Abmachung scheinbar vorteilhaft, da sie ihn vor Kostensteigerungen schützt, für den Dienstleister scheinbar mit Nachteilen behaftet, da er im Fall unvorhersehbarer Aufwände (im komplexen IT-Umfeld ein häufiges Phänomen) die höheren Kosten alleine zu tragen hat. In der Realität verlieren häufig beide Seiten, da der Dienstleister höhere Kosten dadurch eindämmt, dass er spart wo der Käufer es nicht sofort sieht: bei Lastfähigkeit, Wartbarkeit, Erweiterbarkeit, etc.

Ein Ausweg aus dieser Loose-Loose-Situation ist die Erkenntnis, dass Werkverträge keineswegs zwangsläufig einen fixen Preis haben müssen. Das einfache Beispiel aus dem oben genannten Podcast: auch eine Badezimmer-Renovierung lässt sich per Werkvertrag beauftragen, der Preis wird aber trotzdem schwanken, abhängig davon welche Schäden während der Bauarbeiten entdeckt und behoben werden. Eine Übertragung dieses Beispiels auf die IT ist problemlos möglich.

Sich auf ein derartiges Vertragsmodell einzulassen fordert allerdings verschiedene Voraussetzungen: die Einsicht des Auftraggebers, dass sich in der IT Aufwände nicht genau vorhersagen lassen, die Bereitschaft beider Vertragspartner vertrauensvoll und ehrlich miteinander umzugehen und primäre Nutzung des Vertrages als Kooperationsvereinbarung und nicht als Sanktionierungs-Werkzeug. Andererseits - ohne all das wird jedes Projekt noch ganz andere Probleme bekommen. Das kommt oft genug vor, aber dann ist die Vertrags-Art bei weitem nicht mehr das grösste Problem.

Praxisbeispiel: Lean Management im Impfzentrum

Bild: Unsplash / Mufid Manjun - Lizenz

Dass Lean Management keineswegs nur für die Optimierung von Fabriken geeignet ist dürfte sich schon länger herumgesprochen haben, nach einfach nachvollziehbaren Beispielen dafür musste man aber etwas suchen - bis jetzt. Mitten in der Corona-Pandemie ist es gelungen mit diesem Vorgehen eine der Einrichtungen zu optimieren die im Augenblick im absoluten Mittelpunkt des öffentlichen Interesses stehen: ein Impfzentrum.

Eine kurze Rückblende. Bis Mitte April waren alle Berichte über das Impfzentrum des Rhein-Kreises Neuss eher negativ. Lange Warteschlangen und bürokratische Prozesse sorgten für Unwillen unter den Bürgern die sich für ihre Impfung im kalten Wetter anstehen mussten und angesichts der dort aufgestauten Menschenmengen einem erhöhten Ansteckungsrisiko ausgesetzt waren. Das einzig Gute an diesen Missständen: die Notwendigkeit von Verbesserungen wurde durch sie offensichtlich.

An dieser Stelle kam das sprichwörtliche Glück im Unglück ins Spiel. Unter den freiwilligen Helfern befand sich auch der Lean-Experte Andreas Syska, der ab März mit der Optimierung der Abläufe betraut war. Aus seinem ersten Bericht kann man entnehmen welche Praktiken nach und nach eingeführt wurden: Wertstrommapping, Line Balancing, Verschwendungsanalyse, Kreidekreis, Standardisierte Arbeitsprozesse und bessere Visualisierung.

Die Ergebnisse dieser Massnahmen werden jedem bekannt vorkommen der schon einmal mit der Optimierung von Produktions- und Geschäftsprozessen befasst war. Flaschenhälse wurden erweitert, Rückstaus aufgelöst, Laufwege selbsterklärend gestaltet und unnötige oder redundante Abläufe abgeschafft. Bereits Ende April gehörte das Impfzentrum dadurch zu den effektivsten in Deutschland. Einen kleinen Einblick gibt dieses Video:

Überhaupt scheint das Impfzentrum des Rhein-Kreises für Innovationen grundsätzlich sehr aufgeschlossen zu sein. So gehörte es zu den ersten die es impfwilligen Personen ermöglichten per SMS über Impfstoff-Restposten informiert zu werden um sich selbst als Nachrücker anzubieten. Letztendlich nichts anderes als eine Kombination aus Digitalisierung und Pull-Prinzip. Und für noch mehr Beschleunigung sind mobile Impfteams unterwegs.

Das Beispiel aus Neuss zeigt sehr gut zu welchen Effektivitätssprüngen selbst öffentliche Einrichtungen in der Lage sind wenn sie sich auf moderne Management-Methoden einlassen. Und neben den geimpften Bürgern profitieren auch die deutschen Agile- und Lean-Coaches, die jetzt über ein weiteres plakatives Beispiel verfügen um die Vorteile ihrer Ansätze für jeden nachvollziehbar zu erklären.

Nachtrag 10.06.2021:

Auch in Japan gibt es vergleichbare Initiativen. Wenig überraschend.

Nachtrag 03.01.2022:

Anllässlich der Wiedereröffnung nach zeitweiser Schliessung fasst Andreas Syska nochmal Erfolge und Erfolgsfaktoren zusammen.

Das Remote-Produktivitäts-Paradox

Bild: Startup Stock Photos/Eric Bailey - CC0 1.0

Was die Auswirkungen von vermehrter oder sogar vollständiger Heimarbeit auf die Produktivität eines Unternehmens sind ist ein umstrittenes Thema. Bedingt durch die Vielzahl der verschiedenen einwirkenden Faktoren ist es schwer möglich zu sagen welche Effekte auf den Arbeitsort zurückgehen und welche auf begleitende Umstände wie z.B. die Corona-Pandemie 2020/2021. Praktisch alle Studien sind daher mit Vorsicht zu lesen.

Was wissenschaftliche Untersuchungen auch in diesem Umfeld können ist aber das Aufzeigen von Auffälligkeiten und scheinbaren Inkonsistenzen in den gesammelten Daten, die die Ausgangslage für weitere Nachforschungen bilden können. Ein aktueller derartiger Fall ist eine Metastudie der Deutschen Bank, deren Verfasser auf etwas gestossen sind das sie das "Produktivitäts-Paradox" nennen - obwohl sich die Angestellten im Home Office produktiv fühlen geht aus der Sicht ihrer Firmen die Produktivität im Vergleich zur Präsenzarbeit zurück.

Die Ursache für diese Diskrepanz dürfte erst mit weiteren Studien zu erklären sein, bis diese verfügbar sind lassen sich aber zumindest anhand anekdotischer Evidenz erklärende Hypothesen formulieren. Eine die ich aufgrund der Erfahrungen in mehreren Firmen für vielversprechend halte ist dabei diese: die unterschiedliche Wahrnehmung der Heimarbeits-Produktivität durch Angestelle und Firmen geht stark darauf zurück, dass die beiden Gruppen ein unterschiedliches Verständnis davon haben was Produktivität überhaupt ist.

Aus Angestellten-Perspektive wird Produktivität häufig gleichgesetzt mit der Menge an Zeit die für die Arbeit zur Verfügung steht. Da das Wegfallen der Abeitswege zum und im Büro (und umgekehrt die kurzen Wege in der eigenen Wohnung) dazu führen, dass mehr Zeit am Schreibtisch verbracht wird, kann sich das produktiver anfühlen. Verstärkt wird dieses dadurch, dass keine Kollegen im Raum sitzen von denen man von Aufgaben abgelenkt wird. Man hat nicht nur mehr Zeit, man erledigt auch mehr.

Auf der anderen Seite ist aus Firmensicht wichtiger, dass in der zur Verfügung stehenden Arbeitszeit nicht nur Aufgaben erledigt werden sondern auch ein Ergebnis erzielt wird. Dass die Angestellten ausreichend Zeit zum Arbeiten haben und viele Aufträge erledigen ist zwar wichtig, wenn dabei aber keine (oder zu wenige) Produkte erzeugt oder Geschäftsprozesse erledigt werden geht das am Ziel vorbei. Produktivität entspricht in dieser Perspektive dem effektiven Einsatz von Zeit und Mitteln.

Wie diese abweichenden Verständnisse in der Realität entstehen können zeigt eine weitere Studie aus dem Jahr 2020: in 50 untersuchten IT-Teams führte die in der Corona-Pandemie eingeführte Heimarbeit dazu, dass zwar mehr Code geschrieben wurde (die Entwickler schafften es also viele Aufgaben zu erledigen), gleichzeitig war dieser aber in gesteigertem Ausmass fehlerhaft oder am Bedarf vorbei entwickelt (aus Firmensicht wurden also Zeit und Mittel ineffektiv genutzt).

Was die Verfasser als Ursache ausmachten würde auch ich aus meiner Erfahrung bestätigen: gerade das was aus individueller Perspektive als produktiver empfunden werden kann (vereinfacht gesagt: mehr Zeit alleine vor dem Computer) führt aus systemischer Perspektive dazu, dass die Produktivität zurückgeht, da informeller oder impliziter Informationsaustausch, spontane Reviews, Pair Programming und ähnliche effektivitätsfördernde Praktiken zurückgehen und nur schwer wieder zu etablieren sind.

Wie oben gesagt, verlässliche Daten gibt es noch nicht, sowohl die Studien als auch meine Erfahrungen sind eher Indikatoren als fertige Erkenntnisse. Zumindest sind sie aber ein erster Erklär-Ansatz für das Remote-Produktivitäts-Paradox, also dafür dass sich manche Menschen im Homeoffice produktiver fühlen als sie sind.