On Lean and Agility

Zu den Begriffen an denen man bei der Beschäftigung mit agilen Zielsetzungs-Systemen (OKRs, Sprint Goals, etc.) früher oder später vorbeikommt, gehört auch das Loose Coupling (ins Deutsche übersetzt die lose Koppelung). Beschrieben wird das meistens damit, dass über- und untergeordnete Ziele und Massnahmen nicht zu fest miteinander verbunden sein sollen (das wäre Tight Coupling, bzw. enge Koppelung) - aber warum will man diese enge Verbindung eigentlich oft nicht?

Zum besseren Verständnis hilft es, sich Zielsetzungssysteme anzusehen, die umgekehrt gestaltet sind, in denen also Tight Coupling stattfindet. Das sieht meistens so aus, dass die untergeordneten Ziele und Massnahmen fest definierte Teilmengen der übergeordnetend sind, was zwei Folgen hat: zum einen müssen sie alle erfüllt werden um das übergeordnete Ziel zu erreichen, zum anderen sind sie so eng miteinander verbunden, dass sie sich gegenseitig beeinflussen.

Wenn das übergeordnete Ziel z.B. die Gründung einer neuen Niederlassung ist, und davon das Mieten eines Gebäudes, die Einrichtung der Arbeitsräume und die Anstellungung von geeignetem Personal abgeleitet werden, dann ist das eine enge Koppelung. Sollte eine einziges dieser Unterziele oder der dazugehörigen Massnahmen scheitern oder sich deutlich verzögern, wäre auch das übergreifende Gesamtziel in gleicher Art davon betroffen.

Drehen wir es um, wie würde hier eine lose Koppelung aussehen? Das übergreifende Ziel könnte z.B. sein, die neue Niederlassung möglichst schnell arbeitsfähig zu bekommen. Abgeleitet davon könnte man die Onboarding-Handbücher verbessern, einen Bonus für bestehende Kollegen ausloben, die sich zeitweise versetzen lassen um die neuen einzuarbeiten, oder temporär mehr Home Office erlauben. Man sieht an diesen Beispielen: wenn sie nicht gelingen sollten, wären die Folgen weit weniger tiefgreifend.

Noch einmal einfacher ist das Loose Coupling in der digitalen Produktentwicklung. Wenn z.B. das Ziel ist, die Zeit die man in einem Genehmigungsportal verbringen muss zu reduzieren, können verschiedene Entwicklungsteams völlig unterschiedliche Ideen einbringen: besseres UX-Design, schnellere Ladezeiten, hilfreiche Chatbots, etc. Alle diese Ideen tragen zum übergeordneten Ziel bei, untrennbar mit ihm verbunden sind sie aber alle nicht, und untereinander auch nicht.

Durch diese Gestaltung wird etwas möglich, was in jeder ernsthaften Bemühung agil zu Arbeiten enthalten sein sollte: autonome, selbstorganisierte Teams. Durch das Vorgeben der übergeordneten Ziels wird sichergestellt, dass sie im Sinn der Gesamtstrategie arbeiten, mit welchen untergeordneten Ziele und Massnahmen sie das machen und auf welche Art und Weise sie diese umsetzen liegt aber bei ihnen (natürlich müssen dafür bestimmte Vorbedingungen erfüllt sein, z.B. Crossfunktionalität).

Es wird aber an dieser Stelle auch offensichtlich, an welcher Stelle Loose Coupling an Grenzen stösst: dort nämlich, wo aus technischen, juristischen oder sonstigen Gründen sehr klare Vorgaben nötig sind, die dann auch genau so erfüllt werden müssen. Andererseits handelt es sich dann bei ehrlicher Betrachtung auch nicht mehr um Zielsetzungs-Systeme sondern um Anleitungs- und Kontrollsysteme. Das wäre aber nochmal ein eigenes Thema für sich.

Ein Hoch auf die Wissenschaft! Heute auf den amerikanischen Wirtschaftswissenschaftler Jason Furman, der am Peterson Institute for International Economics in Washington DC eine vielbeachtete Vorlesung zum Thema des aktuellen Zustands seines Fachgebiets gehalten hat, die den schönen Namen In Defense of the Dismal Science trägt. Daraus ist vor allem ein Aspekt interessant, der des unterschiedlichen Umgangs mit Change-Projekten duch unterschiedliche Gruppen.

In einer bewussten Vereinfachung teilt Furman alle an Veränderungen Beteiligten Menschen in zwei Gruppen ein, die er die Progressivenen ("the Liberals")¹ und die Konservativen nennt. Beiden wirft er dabei ein jeweils spezifisches Laster (englisch: Vice) vor, womit er meint, dass beide Gruppen beim Umgang mit Veränderungen zu bestimmten Denkfehlern neigen, die beide dazu führen, dass es ihnen schwer fällt, für ihre Sichtweisen Mehrheiten zu gewinnen.

The way in which this happens often varies between liberals and conservatives. I am going to overgeneralize in describing what I call the “liberal vice” and “conservative vice” in policy analysis. But disclaimer: many liberals and conservatives do not suffer from these vices and moreover some liberals suffer from the conservative vice and vice versa.

Jason Furman, 2024: In Defense of the Dismal Science

The Conservative Vice

Das konservative Laster besteht darin, in allen Veränderungen vor allem die damit verbundenen Risiken zu sehen und sie in Folge dessen derartig mit Befürchtungen zu überladen, dass am Ende ein unrealistisch bedrohliches Zerrbild entsteht, aufgrunddessen alles Neue abgelehnt wird. Wie gesagt überzeichnet Furman bewusst, aber der Kern seiner Aussage ist nachvollziehbar.

The Liberal Vice

Das progressive Laster besteht darin, dass in allen Veränderungen vor allem die dadurch potentiell möglichen Verbesserungen gesehen werden, während die ebenfalls möglichen Verschlechterungen ausgeblendet oder sogar negiert werden. Das so entstehende gedankliche Konstrukt ist letztendlich genauso realitätsfern wie das Konservative.

In beiden Fällen ist das jeweilige Denkmuster mit dem Risiko verbunden, die Unterstützung aller anderen Beteiligten zu verlieren. Beim konservativen Laster, weil der Wunsch nach Veränderungen unterschätzt wird, bem progressiven Laster, weil berechtigte Sorgen und Ängste ignoriert werden. Und an der Stelle kommt jetzt die Transferleistung - lässt sich Furmas Idee der konservativen und progressiven Laster auf andere Themenfelder übertragen oder einengen? Ja, das geht.

The Agile Vice

Übertragen auf die agilen Transitionen, um die es auf dieser Seite ja im Wesentlichen geht, ist es so, dass sich vor allem ein Blick auf das progressive Laster lohnt, denn die Parallelen zu den in vielen dieser Transitionen gemachten Fehlern sind offensichtlich - so sehr, dass man in Anlehnung an Furman sogar von einem "agilen Laster" sprechen könnte.

Sowohl vom Management als auch von den "agilen Berufsmethodikern" wird die Umstellung des Arbeitsmodus auf Scrum, Kanban, SAFe und Co. meistens als ausschliessliche Win-Win-Rechnung verkauft: alles soll dadurch schneller, einfacher und besser werden und dabei auch noch mehr Spass machen als vorher. Was dabei unterschlagen wird: Agilität kommt mit einem Preis, dessen sollte man sich bewusst sein. Und er kommt oft in einer erstaunlichen Form: vielen zusätzlichen Regeln.

Wer jetzt innerlich protestiert, da er überzeugt ist, dass agiles Arbeiten keineswegs mit zusatzlichen Regeln verbunden ist, der ist dem agilen Laster bereits verfallen. Denn natürlich gibt es sie: WIP-Limits, Definitions of Done and Definitions of Reday, begrenzte Meeting-Dauern, mindestens ein Increment pro Sprint, gleichlange Sprints von maximal einem Monat Länge, kontinuierliche Integration, kontinuierliche Verbesserung, keine geteilte Product Owner Rolle, etc. Passend dazu noch einmal Jason Furman:

The more common problem is not that people who commit the liberal vice rule out too many policies because they reject anything with a tradeoff. Instead they are more likely to rule these policies in by getting the analysis wrong and denying the tradeoffs. People suffering from the liberal vice can be tempted to think that companies systematically make mistakes that, if corrected, would advance whatever other goals they have.

Jason Furman, 2024: In Defense of the Dismal Science

Und spätestens hier dürfte beim Einen oder Anderen eine Selbsterkenntnis eintreten: wenn nicht alles problemlos läuft, dann liegt es nur an einer fehlerhaften Umsetzung; würden alle sich einfach verhalten wie gedacht, würde alles sofort gut werden - genau das ist es, was Agile Coaches und Scrum Master sich regelmässig gegenseitig versichern, wenn die erwarteten Verbesserungen ausbleiben und es ggf. sogar zu Verschlechterungen kommt.

Um es zu einem versönlichen Ende zu bringen - nicht jeder agilen Berufsmethodiker ist dem agilen Laster verfallen, und genau wie bei Furmans konservativen und progressiven Lastern handelt es sich dabei um eine Übertreibung. Was aber auch klar sein muss: diese Übertreibung veranschaulicht ein reales Problem, nämlich das (bewusste oder unbewusste) Ignorieren und Kleinreden des Preises, den man zahlen muss, wenn man agil arbeiten möchte.

Die Konsequenz sollte klar sein: ständiges Hinterfragen der eigenen Positionen, ständiges Überprüfen der eigenen Positionen auf Fehlannahmen, Einholen von Feedback der von den Veränderungen Betroffenen, Bereitschaft zur Einsicht der eigenen Fehlbarkeit. Oder mit anderen Worten - Anwendung von Inspect & Adapt auf die eigenen Überzeugungen. Eigentlich etwas, was im Umfeld agiler Arbeitsweisen das Normalste der Welt sein sollte.

Bild: Wikimedia Commons / L.C. Dwyer - CC BY-SA 4.0

Mit der Zeit haben sich viele Menschen Gedanken über die ungeschriebenen Gesetze der Organisationsentwicklung gemacht und versucht sie (auf manchmal seriöse, manchmal aber auch eher zynische Art) auf Papier zu bringen. Besonders produktiv war dabei Craig Larman, der Erfinder von LeSS, der insgesamt fünf Gesetze verfasst hat, die er Larman's Laws of Organizational Behavior genannt hat. Heute soll es hier um das Vierte von ihnen gehen. Es lautet:

If after changing the change some managers and single-specialists are still displaced, they become “coaches/trainers” for the change, frequently reinforcing [the redefinition the new terminology to mean basically the same as status quo] and [the deriding of any other change initiative as needing pragmatic customization for local concerns], and creating the false impression ‘the change has been done’, deluding senior management and future change attempts, after which they become industry consultant.¹

Wie bei Larman's anderen Gesetzen muss man sich auch bei diesem durch eine oberste Schicht aus Sarkasmus und Zynismus arbeiten, bevor man zum eigentlichen Kern kommt, der dann aber tatsächlich seine Berechtigung hat. Verkürzt gesagt geht es in dieser Gesetzmässigkeit darum, dass in vielen Gross-Organisationen mittlere Hierarchieebenen dafür belohnt werden, Veränderungsprogramme scheinbar anzunehmen und umzusetzen, sie in Wirklichkeit aber auszuhöhlen und wirkungslos zu machen.

Dazu etwas Kontext: jede grössere Organisation ist von Innen deutlich uneinheitlicher als man von Aussen vermuten würde. Einzelne Standorte, Ressorts, Sparten oder funktionale Einheiten haben jeweils eine eigene Geschichte, eigene Kultur, eigene Ziele und eigene Sachzwänge, wegen denen es extrem schwierig ist, sie übergreifend den gleichen Organisationsprinzipien zu unterwerfen, ohne dabei Ineffizienzen, Fehlanreize oder Widersprüchlichkeiten in Kauf zu nehmen.

Gleichzeitig ist es für die Führungsebene schwierig bis unmöglich, all diese Besonderheiten zu erfassen (und diese Erfassung aktuell zu halten), geschweige denn, im Rahmen von Veränderungsprogrammen für jede von ihnen eine passende Lösung zu erarbeiten und umzusetzen. Um überhaupt handlungsfähig zu sein werden diese Unterschiede daher erstaunlich oft (bewusst oder unbewusst) ignoriert und es wird doch ein übergreifend einheitlicher Ansatz eingeführt, der dann nicht überall passt.

Das mit der Umsetzung der Veränderungen beauftragte Mittelmanagement hat in einer derartigen Situation zwei Optionen: entweder auf die Probleme aufmerksam machen oder offiziell alles mitmachen, den Spielraum der neuen Vorgaben dabei aber soweit wie möglich auszureizen, um möglichst viel beim Alten lassen zu können, um so arbeitsfähig und effizient zu bleiben. Welcher dieser Wege eingeschlagen wird, hängt dabei in der Regel an einer Frage - welcher wird von oben belohnt und welcher bestraft?

Wenn es der zweite ist, der belohnt wird, ist Larman's viertes Gesetz praktisch eingetreten. Belohnung bedeutet in grossen Organisationen nämlich meistens eine Beförderung in eine verantwortungsvollere Position, und für jemanden der Veränderungen (von aussen gesehen) erfolgreich umgesetzt hat, ist eine Beförderung in eine Position im Veränderungsmanagement naheliegend. Und da auch dort die gleichen Dinge belohnt und bestraft werden, finden auch dort die gleichen Verhaltensmuster statt.

Wie es besser ginge ergibt sich aus dieser Beschreibung fast von selbst: es müssen andere Dinge belohnt werden, wie z.B. das Aufdecken von Fehlannahmen, Übervereinfachungen und Fehlplanungen, das Aufzeigen von Konsequenzen, der Verzicht auf Beschönigungen und Scheinerfolge und die Bereitschaft, höheren Hierarchieebenen zu widersprechen. Dort wo das passiert ist die Wahrscheinlichkeit, von Larman's viertem Gesetz betroffen zu sein, deutlich geringer.

Nachtrag:

Ja, ich weiss. Ich bin nicht auf die "Industry Consultants" eingegangen. Hätte an dieser Stelle zu weit geführt. Kommt noch. Vielleicht.

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.

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.

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.

Grafik: Pixabay / Geralt - Lizenz

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

Erik de Bos: The Puzzle of Self-Organisation

Bob Galen: Shatters Anonymous

Prateek Singh: On Deterministic Fixed-Length Timeboxes

Charles Lambdin: What Is Cost of Delay?

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.