Montag, 10. Dezember 2018

Schläferzellen

FS
Bild: Pexels / Burst - CC0 1.0
Es ist nur ein einziger Satz aus einem Bericht vom Peter Drucker Forum 2018, aber es lohnt sich länger über ihn nachzudenken. Er steht in einem Absatz in dem die immer stärker werdende Verbreitung von "Human-Centered Management" beschrieben wird und lautet "'Sleeper cells' of the new way of managing have sprung up in many more organizations." Aber was soll uns das sagen?

Zunächst zur Begrifflichkeit. Sleeper Cell (Schläferzelle) bezieht sich in diesem Zusammenhang auf eine Frühphase revolutionärer Bewegungen. Gruppen von Menschen kommen mit neuen, radikalen oder ungewöhnlichen Ideen in Berührung, die zu diesem Zeitpunkt noch nicht anerkannt, nicht zulässig oder stigmatisiert sind. Bedingt dadurch erfolgt die Beschäftigung damit zunächst zurückgezogen im privaten oder informellen Raum.

Wenn die neuen Ideen schliesslich in der öffentlichen Diskussion oder sogar der Umsetzung ankommen werden die bis dahin ruhigen (schlafenden) Gruppen aktiv und sorgen dafür, dass (von aussen betrachtet) aus dem Nichts eine Unterstützerbasis entsteht auf die sich der entstandene Veränderungsprozess stützen kann. Beispiele dafür sind der Prager Frühling oder der Arabische Frühling1.

Auch im Rahmen von Management und Menschenführung kommen Schläferzellen vor, wenn auch mit einer sehr unterschiedlichen Dichte und Beteiligung, je nachdem um welche Denkrichtung es geht. Während prozess- und hierarchiezentrierte Ansätze von den potentiell Betroffenen eher skeptisch gesehen werden haben team- und menschenzentrierte Frameworks wie XP und Scrum aufgrund ihrer Soft Power-Faktoren eine sehr hohe Anziehungskraft.

Wenn eine Organisation sich dazu entschliesst es mit Agilität zu versuchen gibt es daher in der Regel den oben beschriebenen Effekt: scheinbar aus dem Nichts entstehen (vor allem in der IT) Gruppen die bereits Vorwissen mitbringen, sich an der Umsetzung und Gestaltung des Veränderungsprozesses beteiligen wollen und den Finger in die Wunde legen wenn er sich in die falsche Richtung entwickelt.

Für die Veränderung ist das ein doppelter Glücksfall. Zum einen ist sie von Beginn an in Teilen der Organisation verankert, wodurch sie eine ganz andere Wirkungskraft entfalten kann als ein rein von oben getriebenes Vorgehen. Zum anderen wird frei Haus eine Validierungsmöglichkeit geliefert. Ob es mit dem Veränderungswillen ernst gemeint ist kann man jetzt u.A. daran erkennen ob sich die "erwachten Schläfer" beteiligen dürfen oder nicht.

Und selbst wenn die Veränderungsbemühungen fehlschlagen oder sich festfahren sollten bleibt Positives zurück: die Zahl der Zellen die wieder zurück in den Schlafmodus gehen hatte die Chance deutlich zuzunehmen. Bei der nächsten Aktivierung ist der initiale Schwung dadurch nochmal grösser.


1Es gibt auch den Fall von destruktiven Schläferzellen, aber das wäre ein anderes Thema.

Donnerstag, 6. Dezember 2018

Delivering twice the value in half the time

FS
Bild: Pixabay / Annca - CC0 1.0
Weitgehend unbemerkt von der Öffentlichkeit hat sich irgendwann in den letzten Wochen eine unscheinbare aber bedeutsame Änderung ergeben: eines der bekanntesten Versprechen von Scrum wird anscheinend nicht mehr in seiner ursprünglichen Form weiterverwendet. Die Rede ist von doing twice the work in half the time, bekannt geworden als Titel eines Buches von Scrum-Mitbegründer Jeff Sutherland. Stattdessen spricht er seit kurzem von delivering twice the value in half the time. Ein kleiner aber feiner Unterschied.

Die Aussage "Doing twice the work", die seit je her von Scrum Practitionern kritisch gesehen wird, impliziert, dass die Einführung von Scrum zu einem höheren Durchsatz führt. Egal welche Tätigkeiten ein Team durchführt, es wird in die Lage versetzt noch mehr davon zu leisten. Man spricht im Englischen in diesem Zusammenhang von der Erhöhung des Output. Was nicht klar ist (und hier setzt die Kritik an der Formulierung an) ist, ob der durch diese Tätikeiten erzeugte Output überhaupt einen Sinn ergibt.

Wer in grossen Organisationen arbeitet kennt das Risiko - viele Teams erzeugen Arbeitsergebnisse von fragwürdigem Wert: Konzepte die an der Realität vorbeigehen, Statistiken die Offensichtliches oder Irrelevantes messen, Funktionalitäten die die Kunden nicht brauchen, etc. Davon mehr zu bekommen hilft niemandem weiter. Und selbst wenn Sutherlands Buch inhaltlich nichts derartiges fordert, der Titel verführt zu diesem Fehlschluss.

Besser ist es, bei jeder bisher durchgeführten Tätigkeit die Sinnfrage zu stellen. Je mehr an Elfenbeintürmen, Junk Charts, Bloatware, etc. weggelassen werden kann, desto mehr Zeit bleibt für die Arbeit an wirklich wichtigen Themen. Um es mit den Worten des Manifests für agile Softwareentwicklung zu sagen: Simplicity - the art of maximizing the amount of work not done - is essential. Viele der Bestandteile von Scrum (Definition of Done, Sprintziel, User Stories, etc.) zielen genau darauf ab.

Diese Art von werthaltigen und sinnstiftenden Ergebnissen nennt man im Englischen Outcome. Da für ihre Fertigstellung im Idealfall nur die nötigste Arbeit verrichtet und alles Unnötige unterlassen wurde, sind der Aufwand und die Zeit die investiert werden müssen deutlich niedriger als im Fall einer Output-orientierten Arbeitsweise. Daher macht die Aussage delivering twice the value in half the time absolut Sinn. Richtig angewandt kann Scrum dafür sorgen, dass in weniger Zeit mehr Mehrwert entsteht.

Ganz aus der Welt bekommen wird man das "Doing twice the work" zwar wohl nicht mehr, zukünftig kann man aber jedem der es falsch versteht zeigen, dass die Formulierung weiterentwickelt wurde. Ganz im Sinn von Inspect & Adapt.

Montag, 3. Dezember 2018

Just in Time vs. Just in Case

FS
Irgendwo ist dieses Video durch meinen Twitterfeed gerauscht. Eine kurze Erklärung des Just in Time-Prinzips (Produktion nur nach Bedarf, ohne Lagerhaltung), mit netten, z.T. amüsanten, Visualisierungen. Man kann es sich gut als Einführung in das Thema anschauen.



Ein interessanter Ansatz für die Vermittlung dieser Idee ist dabei die Gegenüberstellung eines zweiten Prinzips: Just in Case. Die deutsche Übersetzung Für alle Fälle zeigt worum es geht - etwas mehr Zeit, Material und Personal als nötig hilft im Zweifel dabei, ungeplante und unvorhersehbare Aufwände zu bewältigen. Da beide Ansätze ihre Vorteile haben wird es in den meisten Fällen auf eine Abwägung herauslaufen. Und um die griffig beschreiben zu können ist das Gegensatzpaar Just in Time und Just in Case gut geeignet.

Freitag, 30. November 2018

Kommentierte Links (XXXXIII)

FS

  • Mark Schwartz: Your First Four Steps in Transforming Enterprise IT Governance

  • Ein Blick aus der Adlerperspektive. Was Mark Schwartz beschreibt ist letzten Endes nichts anderes als Kanban. Reduziere die Anzahl der Initiativen (bzw. des Work in Progress), verkürze die Durchlaufzeiten, schliesse Vorhaben so schnell wie möglich ab, fokussiere Dich bei den Ergebnissen auf die Erzeugung von Geschäftswert und die Validierung von Annahmen. Dass das auch der Ebene ganzer Konzerne möglich ist zeigt eine der Stärken von Kanban auf - es lässt sich auf jede Ebene skalieren.

  • Tobbe Gyllebring: What if demonizing “waterfall” pulled the rug out from under our Agile?

    Ein interessanter Denkansatz. Tobbe Gyllebring geht davon aus, dass agile Vorgehensweisen vor allem dann wirksam und verständlich sind wenn man das klassische Wasserfallmodell als Kontrast parat hat, weil man dieses noch erleben musste, bzw. durfte. Das ist zwar nicht völlig falsch, die Frage ist aber was die Konsequenz wäre. Dysfunktionale Strukturen (wieder)einzuführen nur um Kontextwissen zu erzeugen wäre sicher über das Ziel hinausgeschossen. Vielleicht sollte man bewusst eine Karrierestation dort einlegen wo man noch nicht so weit ist und man deshalb lernen kann wie es nicht geht? Eine gewagte Idee.

  • Heidi Araya: Why Agile Works

    Einmal mehr ein klassischer Erklär-Artikel. Angereichert um einige gute weiterführende Links fasst Heidi Araya ein "Best of" aus Agile, Kanban, Lean Startup, technischer Exzellenz und Kundenorientierung zu einer verständlichen Storyline zusammen. Falls wieder jemand nach einer schriftlichen Zusammenfassung fragt ist das hier ein guter Kandidat. Jetzt müsste ich nur noch die Motivation und die Zeit finden das ins Deutsche zu übersetzen ....

Dienstag, 27. November 2018

Gesetz der Penetranz der negativen Reste

FS
Bild: Public Domain Pictures / Ian Bunyan - CC0 1.0
Alleine der Name ist so schräg, dass man versucht ist herauszufinden was sich dahinter verbirgt. Das "Gesetz der Penetranz der negativen Reste" setzt sich mit dem Phänomen auseinander, dass die Lösung von Problemen bei vielen Menschen nicht dazu führt, dass sie mit ihrer Gesamtsituation zufriedener sind. Im Gegenteil bleibt der Grad der Unzufriedenheit durchgehend gleich, er konzentriert sich lediglich auf einen immer kleineren Problem-Restbestand.

Der Philosoph Odo Marquard, Schöpfer des Begriffs, definiert ihn so: Wo Fortschritte … wirklich erfolgreich sind und Übel wirklich abschaffen, da wecken sie selten Begeisterung. Sie werden vielmehr selbstverständlich, und die Aufmerksamkeit konzentriert sich dann ganz und gar auf jene Übel, die übrigbleiben. Da wirkt das Gesetz der zunehmenden Penetranz der Reste: ... Wer – fortschrittsbedingt – unter immer weniger zu leiden hat, leidet unter diesem Wenigen immer mehr.

Ursprünglich stammt dieses "Gesetz" aus Beobachtungen im Bereich der Medizin, wo sich trotz immer besserer Gesundheit der Gesamtbevölkerung die Sorgen um die eigene Gesundheit halten und auf immer nachrangigere Aspekte konzentrieren. Zum Teil kann es dort sogar in Extreme wie Medikalisierung und Pathologisierung umschlagen. Übertragen lässt es sich aber auch auf die Organisationsentwicklung, bzw. die zu dieser gehörenden Optimierungsprozesse.

Geht man davon aus, dass auch hier Fortschritte dazu führen, dass die verbleibenden Probleme pathologisiert und mit dauerhaft gleichbleibender Energie bekämpft werden, hat man eine Erklärung für den in vielen Organisationen anzutreffenden Drang zur "Über-Optimierung". Die scheinbare Irrationalität, mit der selbst kleinste Einspar- und Effizienzpotentiale hartnäckig verfolgt werden, wird plötzlich erklärbar.

Das Problem ist, dass es hier anders als beim Gesundheitsempfinden nicht bei Übersensibilität und Hypochondrie bleibt. Das Gesetz der Penetranz der negativen Reste kann schwerwiegende wirtschaftliche Folgen haben: nicht nur wegen des immer unverhältnismässiger werdenden Verhältnisses zwischen Optimierungs-Aufwand und Ertrag, sondern auch wegen der früher oder später fast zwangsläufig auftretenden Beeinträchigung elementarer Funktionen.

Getrieben von dem Drang auch kleinste Dysfunktionen aufzuspüren ist in vielen Organisationen ein derart engmaschiges und aufwändiges Reporting und Controlling entstanden, dass die Erfüllung der damit verbundenen Vorgaben einen Grossteil der Arbeitsleistung bindet. Die wertschöpfenden Tätigkeiten gehen dagegen immer weiter zurück, mitunter soweit, dass die erwirtschafteten Gewinne die entstandene Bürokratie nicht mehr finanzieren können.

Um die damit verbundenen Folgen (die im schlimmsten Fall bis zur Insolvenz reichen können) abzufedern empfiehlt sich eine regelmässige Überprüfung aller zur Zeit laufenden Optimierungsmassnahmen. Welches Ziel sollen sie erfüllen, welcher wirtschaftliche Effekt soll damit erreicht werden und wie hoch sind die dem gegenüberstehenden Verwaltungs- und Bürokratiekosten? Und bei lokalen Optimierungen: was sind deren Auswirkungen auf das Gesamtsystem?

Wenn es gelingt durch solche Evaluierungen die Stellen zu identifizieren, an denen das Gesetz der Penetranz der negativen Reste zu Überoptimierungen geführt hat, kann deren Abschaffung befreiend wirken. Je nach Kontext kann die dadurch mögliche (Wieder)Zunahme an Effektivität und Flexibilität sogar so gross sein, dass ihre Rücknahme bereits die Effekte einer agilen Transition hat, ganz ohne Scrum Master, Standup Meetings & Co.

Donnerstag, 22. November 2018

DoD Memory

FS
Bild: Pxhere / Rawpixel - CC0 1.0
When life gives you lemons - make lemonade. Gemäss diesem englischen Sprichwort haben wir (ich und ein von mir gecoachter Scrum Master) diese Woche eine neue Übung für die nächste Retrospektive entwickelt. Angelehnt an das Memory-Spiel ist der vorläufige Name DoD Memory, denn auch hier geht es um einen Test des Erinnerungsvermögens.

Zu den Hintergründen: das Team um das es geht leidet unter einer Sonderform der agilen Demenz - die eigene Definition of Done (DOD) gerät regelmässig in Vergessenheit. Selbst wenn sie in Retrospektiven oder gesonderten Workshops neu erstellt oder überarbeitet wird ist es nur eine Frage der Zeit bis sich niemand mehr an sie erinnern kann und demzufolge auch niemand mehr an sie hält. Aus den Augen, aus dem Sinn, wie man in einem anderen Sprichwort so schön sagt.

DoD Memory funktioniert jetzt so: der Scrum Master (oder jeder andere der sich berufen fühlt) kann in einer Retrospektive darum bitten, dass jedes Teammitglied alle Teile der DoD an die es sich erinnern kann aufschreibt - am besten in Stillarbeit. Die Ergebnisse werden gesammelt und dann mit der tatsächlichen DoD verglichen (die zu diesem Zweck verfügbar sein sollte).

Sollte es jetzt der Fall sein, dass Teile der Definition of Done keinem einzigen Teammitglied eingefallen sind stellt sich die Frage was das für das Team bedeutet. Da davon ausgegangen werden kann, dass nicht präsente Teile der DoD nicht angewendet werden, kann zur Debatte gestellt werden ob sie nicht gestrichen werden sollten. Gewissermassen wäre das die Anpassung der Regeln an die Realität. Alternativ kann überlegt werden wie die DoD präsenter gemacht werden kann.

Geschieht das gibt es zwei mögliche Endszenarien. Entweder gelingt es durch die Thematisierung in Retrospektiven und durch abgeleitete Massnahmen die DoD zu verinnerlichen oder sie schrumpft nach und nach zusammen bis nur noch der Rest übrig ist an den sich jeder erinnern kann. Beides hat Vorteile. Bei Bedarf kann natürlich auch wieder eine Erweiterung stattfinden, die dann aber irgendwann auf die selbe Art validiert werden sollte.

Letztendlich können vergleichbare Übungen auch mit anderen Vereinbarungen durchgeführt werden, etwa der Definition of Ready oder der Teamcharta. Auch in diesen Fällen ist es ein guter Weg um der agilen Demenz entgegenzuteten, die auch in den besten Teams um sich greifen kann.

Montag, 19. November 2018

Ein Bild sagt mehr als 1000 Worte (XXIII)

FS
Bild: Geek & Poke - CC BY 3.0
Und falls das eine Bild doch nicht reichen sollte um zu erkennen worum es hier geht - hier gibt es Kontext.

Donnerstag, 15. November 2018

Wie Angst lähmen kann

FS
Bild: Wikimedia Commons / J. M. Garg - CC BY-SA 4.0
Zu den deprimierendsten Erfahrungen als Agile Coach gehört es, mit dem Auftrag zur Veränderungsbegleitung bei einem Team zu erscheinen, ihm das theoretische und methodische Rüstzeug mitzugeben, erste Verbesserungspotentiale aufzuzeigen und dann zu hören "Nein, das machen wir nicht, das werden die uns nie erlauben." Gegen diese Stimmung anzukämpfen ist schwierig aber notwendig, denn wenn sie nicht verschwindet sind echte Veränderungen unwahrscheinlich.

Das Problem ist, dass es sich bei einem Grossteil dieser scheinbaren Verbote um keine offiziellen Regeln handelt sondern um inoffizielle. Es ist also nirgendwo festgehalten, dass man eine bestimmte Handlung (Überstunden ablehnen, selbst Entscheidungen treffen, Anforderung hinterfragen, etc.) nicht durchführen darf. Trotzdem wird oft angenommen, dass ein Verbot besteht und allein das in Erwägung ziehen eines nicht konformen Verhaltens wird vehement negiert.

Dort wo derartige Verhaltensweisen an den Tag gelegt werden kann mit hoher Wahrscheinlichkeit davon ausgegangen werden, dass das als verboten angenommene Verhalten irgendwann in der Vergangenheit bestraft worden ist. Alleine die Erinnerung daran (und die Angst vor einer neuen Bestrafung) kann dann dafür sorgen, dass mit allen Kräften versucht wird eine Wiederholung dieser Ereignisse zu verhindern. Für den psychologisch Interessierten: es ist die Übertragung des berühmten Rhesusaffen-Experiments von Gordon R. Stephenson auf den Menschen.

In einer solchen Situation ist es mit einem gut gemeinten Versuch es doch einfach nicht mehr getan. Was nötig ist, ist die Schaffung eines Safe Space, also einer Umgebung in der es sichergestellt ist, dass es nicht zu einer Bestrafung kommen wird - und zwar auch dann nicht (genauer gesagt gerade dann nicht!) wenn das Ergebnis nicht den Erwartungen entspricht oder ungeplante Seitenauswirkungen auf andere Bereiche hat. Nur wenn das gelingt kann es zu Verhaltensänderungen kommen.

Was ist für die Schaffung eines solchen Safe Space nötig? Zuerst das Ansprechen des Root Cause, also der in der Vergangenheit stattgefundenen Bestrafung1.Wenn sie aufgrund einer damals noch gültigen Regel stattgefunden hat muss klar gemacht werden, dass diese Regel nicht mehr in Kraft ist, wenn sie ohne derartige Grundlage stattgefunden hat muss das als Fehler eingestanden werden. Und diese Aussage muss von der Hierarchiebene kommen von der aus die Bestrafung stattgefunden hat oder von einer höheren.

Als nächstes macht es Sinn festzuhalten, dass die aktuellen Regeln ein bestimmtes Verhalten nicht nur zulassen sondern sogar ermutigen. Idealerweise findet das nicht nur durch eine Anpassung des dritten Absatzes der vierten Seite des achten Kapitels des Prozesshandbuches statt sondern durch plakatives Aufhängen an einer zentralen Stelle, etwa als Banner mit der Aufschrift "Wir dürfen und sollen Nein sagen."

Falls nötig kann auch vereinbart werden was der Rahmen ist innerhalb dessen ohne Sorgen gehandelt werden kann. Dass Selbstorganisation nicht grenzenlos sein kann sollte eigentlich offensichtlich sein, und dass diese Grenzen nicht festgelegt wurden ist oft ein Grund für unbewusste Überschreitungen und ein als Strafe empfundenes nachträgliches Festsetzen. Was an dieser Stelle wichtig ist: ist der Rahmen zu eng gesetzt wird er im Zweifel als einengend und einschüchternd empfunden werden.

Zuletzt kann es helfen wenn die Respektierung der gewährten Freiheiten (und das Nicht-Stattfinden von Bestrafungen) regelmässig validiert wird. Wie das vor sich gehen kann wird von Fall zu Fall unterschiedlich sein müssen, möglich ist z.B. das Durchführen von Experimenten in einem iterativ immer grösser werdenden Rahmen oder ein anlassgetriebener Lessons Learned-Prozess. In jedem Fall sollten aber positive Beispiele hervorgehoben und erörtert werden.

Klar sollte sein, dass all diese Massnahmen in den meisten Fällen nicht nötig sein sollten. Sie machen vor allem dort Sinn wo in einem Unternehmen eine Angstkultur herrscht, die es abzuschaffen gilt, und die man erkennt an Sätzen wie "Nein, das machen wir nicht, das werden die uns nie erlauben."


1Es gibt auch Fälle in denen das Management bestreitet, dass es eine Bestrafung gab, bzw. eine stattgefundene Handlung nicht als Bestrafung sehen will. Das sind dann nochmal ganz eigene Probleme.

Montag, 12. November 2018

Management 3.0

FS
Bild: Pixabay / Monfocus - CC0 1.0
Einer der kleineren, trotzdem aber immer erfolgreicher werdenden agilen Ansätze ist das so genannte Management 3.0. Was das ist und wo es herkommt wäre eine Geschichte für sich, an dieser Stelle soll es aber zuerst nur um den Namen gehen. Schon hinter ihm versteckt sich nämlich ein für das Verständnis des Frameworks zentraler Punkt. Er definiert nicht nur was Management 3.0 ist, sondern auch was es nicht ist.

Wie man sich denken kann ist es eine Differenzierung von anderen Management-Praktiken. Dabei setzt es sich zuerst ab von der "herkömmlichen" Art Menschen und Unternehmen zu führen. In diesem Kontext wird diese Management 1.0 genannt und ist geprägt durch Hierarchiedenken, Herrschaftswissen, Command & Control und ähnlichen problematischen Vorgehensweisen.

Warum diese Vorgehensweisen problematisch sind ist aus einer agilen Perspektive klar: Hierarchien verhindern, dass sich die ausführende Ebene verantwortlich fühlt (und benimmt), Herrschaftswissen hält die Mitarbeiter dumm und führt so zu unklugen Entscheidungen, Command und Control verlagert den Ziel des Arbeitens weg von der Sinnerfüllung und hin zur Vorgabenerfüllung. So weit, so bekannt.

Darüber hinaus wird davon ausgegangen, dass es noch eine zweite Art von Management Praktiken gibt, die zwar in ihren Zielen etwas weiter ist, diese aber mit den bisher üblichen Methoden umsetzen will und aus diesen Gründen zwangsläufig daran scheitert. Letztendlich ist er damit nur der bessere unter den schlechten Ansätzen. Für ihn gibt es den Namen Management 2.0.

In der Realität sieht er so aus, dass z.B. Selbstorganisation angestebt wird, die aber dadurch umgesetzt werden soll, dass die dazu (angeblich) nötigen Strukturen den Mitarbeitern ungefragt übergestülpt werden. Klassiker in diesem Bereich sind die von oben angeordneten Einführungen von SAFe oder (Pseudo-)Spotify, was meistens nichts anderes ist als die Ersetzung alter Hierarchien und Kommandostrukturen durch neue.

Auch der Versuch eine neue Unternehmenskultur von oben vorgegeben und zentral gesteuert einzuführen ist eine Ausprägung von Management 2.0. Alleine die Idee, dass man Kultur durch Anordnung verändern könnte ist ein Missverständnis. Wenn dann noch paternalistische Aspekte dazukommen ("die müssen zu ihrem Glück gezwungen werden", "die werden noch verstehen warum das gut ist", etc.) ist kaum noch ein Unterschied zu Management 1.0 erkennbar. (siehe auch: agiler Marxismus und Leninismus)

Management 3.0 ist dagegen der Versuch alle Ebenen in Veränderungen und Entscheidungen einzubeziehen, und zwar nicht nur als Betroffene sondern als Beteiligte. Um das zu erreichen gibt es eine Vielzahl von Praktiken und Techniken die in ihrer Gesamtheit das Management 3.0-Framework ausmachen (z.B. Merit Money und Delegation Poker). Ihnen allen ist gemeinsam, dass sie nicht angeordnet sondern gemeinsam durchgeführt werden sollen.

Mit der Benennung 3.0 erfolgt damit nicht nur eine Differenzierung zum "traditionellen" Management sondern ganz wesentlich auch zu denen, die zwar eigentlich das Richtige wollen, die Transition aber durch Bevormundung der Mitarbeiter und undifferenziertes Copy & Paste anderswo erfolgreicher Methoden umsetzen wollen. Ihnen die Management-Typen 1.0, 2.0 und 3.0 zu erklären kann schmerzhaft aber hilfreich sein und ist daher zu empfehlen.

Freitag, 9. November 2018

Struktur, die aus Post-Its entsteht

FS
Alberto Brandolini hat völlig recht wenn er sagt, dass das Identfizieren und Modellieren von Strukturen und Prozessen am besten mit bunten Zetteln auf einer grossen Wand stattfinden kann. Seine Art das zu tun nennt er Event Storming. Selbst wenn nicht alles davon in jeden Kontext passt, inspirieren lassen kann man sich durch seine Ideen auf jeden Fall.


Dienstag, 6. November 2018

Prozessverbesserung alleine ist keine Lösung

FS
Bild: Wikimedia Commons / Johannes Martin Conrad - CC BY 3.0
Kann sich noch jemand an den Spruch "pünktlich wie die Bundesbahn" erinnern? Lange ist es her, dass das der Normalfall war. Angesichts von Verspätungsquoten von 30 % allein im Fernverkehr versucht die Bahn AG gerade gegenzusteuern. Mit dem so genannten Deutschlandtakt sollen Züge besser aufeinander abgestimmt werden, mit weiteren Massnahmen soll das Ein- und Austeigen schneller und effizienter gemacht werden. Das Ziel: mehr Pünktlichkeit.

Um die Erwartungen von Anfang an zu dämpfen: pünktlich werden die Züge auf diesem Weg nicht werden. Ein bisschen werden die Verspätungen mit Sicherheit zurückgehen, zum grössten Teil aber bestehenbleiben. Denn so gut die Prozessverbesserungen auch sein mögen, dass Hauptproblem werden sie nicht lösen können - die veralteten und immer wieder ausfallenden technischen Systeme.

Man kennt es aus den Durchsagen am Bahnsteig. Weichenstörungen unterbrechen die Fahrt, Signalstörungen verhindern die Einfahrt in die Bahnhöfe, defekte Oberleitungen bringen Züge zum Stillstand, Waggons mit ausgefallenen Klimaanlagen müssen ausgetauscht werden, defekte Schranken dürfen nur im Schrittempo passiert werden - solange das alles nicht in den Griff bekommen wird kann auch der beste Prozess nicht helfen.

Die Parallelen zu IT-Projekten und -Abteilungen sind offensichtlich. Häufig wird die Einführung von Scrum oder Kanban mit grossen Hoffnungen verbunden, die dann an der veralteten Technik und Systemlandschaft scheitern. Computer haben zuwenig Diskspace, Test- und Entwicklungsumgebungen müssen manuell eingerichtet werden, Telefonkabel aus den 70er Jahren verlangsamen die Datenübertragung, etc. etc.

Wie beim Beispiel der Bahn heisst das nicht, dass Prozessverbesserungen nichts bringen. Starre Planungen und Bürokratie zu beseitigen ist immer eine Verbesserung. Ohne die begleitenden Modernisierungen von Software und Hardware wird ihre Wirksamkeit aber deutlich eingeschränkt bleiben. Erst durch eine Kombination dieser Faktoren kann es zum befreienden grossen Sprung nach vorne kommen.

Diese Themen anzusprechen kann in vielen Unternehmen zum Offenbarungseid führen: Agilität sei als Ansatz gewählt worden weil davon ausgegangen wurde, dass die Umstellung von Meetings und Rollen mit geringem Aufwand möglich ist, für darüber hinausgehende Modernisierung wäre aber kein Geld da. Das würde doch auch bestimmt ohne gehen, oder? Derartige Aussagen sind häufiger als man denken sollte.

Die Antwort darauf kann nur eine sein: Das kann man zwar so machen, aber dann sollte man seine Erwartungshaltungen deutlich herunterfahren.

Samstag, 3. November 2018

Wie technikfern darf ein Scrum Master oder Agile Coach sein? (II)

FS
Bild: Pexels / Tim Gouw - CC0 1.0
Die agile Welt ist ein Dorf. Sobald man einige Scrum- oder Kanban-Projekte ausserhalb der IT gemacht hat wird man schnell zum gefragten Ansprechpartner zu diesem Thema. Der Grundtenor klingt dabei immer ähnlich: "Ich interessiere mich ja sehr für Agilität, Scrum Master oder Agile Coach wäre was für mich. IT ist aber nicht so mein Ding. Wie finde denn ich Jobs in anderen Bereichen?" Nun ja.

Es ist nicht so als würde es diese Jobs nicht geben (zwar nicht viele, aber es gibt sie). Ich habe bereits Teams coachen dürfen die mit Scrum oder Kanban im Vertrieb, in der Hardwarefertigung, im Kundenservice und im Change Management gearbeitet haben, dazu kommen immer mehr Beispiele aus anderen Bereichen, zum Beispiel gibt es in meiner Heimatstadt Bonn sogar Scrum im Schulunterricht.

Das letzte dieser Beispiele zeigt aber auch direkt das erste Problem auf: selbst wenn manche Anwendungsgebiete IT-fern sind, einfach zugänglich sind sie aber trotzdem nicht unbedingt. Es darf eben nicht jeder an einer Schule unterrichten, dafür muss man vorher an einer Universität gewesen sein und Lehramt studiert haben. Auch in anderen Fällen stösst man schnell an Grenzen formaler Art, die nicht einfach zu überwinden sind.

Nun engt sich damit die Zahl in Frage kommender Jobs zwar weiter ein, aber es gibt sie, oder? Die Antwort: ja, aber. Sie existieren natürlich, in sehr vielen Fällen allerdings nur temporär. Agilität in Service- oder Hardware-Bereichen findet häufig da statt, wo Innovationsarbeit geleistet wird. Für Experimente, Prototypen und MVPs lohnt sich agiles Arbeiten, sobald die Serienfertigung oder -durchführung beginnt eher nicht mehr.

Scrum Master- oder Agile Coach-Stellen sind in solchen Kontexten nur zeitweise nötig. Derartige nicht-IT-Projekte leihen sich eine solche Person daher in der Regel vorübergehend aus, und zwar von da wo es sie bereits gibt - eben aus der IT. Die Alternative, das Vorhalten eines permanenten Scrum Master- oder Coach-Pools, würde eine Nachfrage voraussetzen die es in den meisten Firmen nicht gibt.

Ist die Suche nach einer Position ausserhalb der IT also völlig hoffnungslos? Das zwar nicht, realistisch betrachtet ist die Wahrscheinlichkeit einen zu finden aber sehr gering, zumindest wenn es eine langfristige Beschäftigung sein soll. Was am ehesten sein kann ist, dass sich eine temporäre Stelle finden lässt, die man mit etwas Glück besetzen kann. Es fragt sich nur - was passiert wenn dieses Projekt vorbei ist?

Die eine Möglichkeit wäre das Entlanghangeln von einer temporären Stelle zur nächsten. Nicht unmöglich aber sehr schwierig - so viele derartige Jobs gibt es auch nicht. Die andere Möglichkeit wäre, eine Beschäftigung im agilen nicht-IT-Bereich als Vorstufe für einen Einstieg in die IT zu benutzen. Aufgrund des Fachkräftemangels ist das nicht einmal unrealistisch, allerdings kommt man dann an der Beschäftigung mit der Technik nicht mehr vorbei. Dieser Umstände sollte man sich bewusst sein.

Mittwoch, 31. Oktober 2018

Kommentierte Links (XXXXII)

FS
  • Tim Harford: Why Big Companies Squander Brilliant Ideas

    Ein langer Text, aber lesenswert. Mit mehr als 20.000 Zeichen führt Tim Harford aus warum sich große Organisationen mit Innovationen schwer tun: zum einen weil neue, zu Beginn noch nicht profitable Ideen sich im internen Wettbewerb um Ressourcen nicht gegen die etablierten, seit langem Gewinn abwerfenden Cash Cows durchsetzen können, zum anderen weil die bestehenden Organisationsstrukturen so stark auf die bestehenden Produkte zugeschnitten sind, dass neue Produktideen nur umgesetzt werden wenn sie ebenfalls diesen Strukturen entsprechen - was häufig nicht der Fall ist. Der dritte Grund dagegen ist wesentlich polemischer und darum mit Vorsicht zu geniessen: "Because people are idiots."

  • Dennis Willkomm: Am Scheitern scheitern – Gefahren der Fehlerkultur

  • Ich freue mich ja immer wenn ich merke, dass ich nicht der erste aus der lokalen Agile-Community bin der dieses Internet vollschreibt. Dennis Willkomm hat sich hier eines selten behandelten Themas angenommen, nämlich dem, dass nicht nur die Einführung von Methoden sondern auch die Veränderung einer Unternehmenskultur im Cargo Cult enden kann. Mit Exkursen in die Psychologie unterfüttert wird eine Erkenntnis herausgearbeitet die man vielen Change Management-Abteilungen nur wünschen kann: wer glaubt seinen Mitarbeitern eine neue Kultur einfach überstülpen zu können wird damit alles mögliche erreichen, nur nicht das was er eigentlich beabsichtigt hat.

  • Alice Newton Rex: Escape From the Feature Roadmap to Outcome-driven Development

    Ein Thema das ich in letzter Zeit immer wieder in Product Owner-Workshops besprochen habe findet sich auch hier wieder: gegenüber Stakeholdern/Management/Kunden/Auftraggebern sollte sich ein Product Owner nicht zur Lieferung bestimmter Funktionalitäten verpflichten sondern zur Lieferung abstrakt formulierter Kundenmehrwerte, deren bester Umsetzungsweg sich erst im Rahmen der Umsetzung selbst ergeben wird. Dieser Ansatz widerspricht zwar dem üblichen Verhalten in vielen Organisationen (Alice Newton Rex erklärt gut warum), führt aber bereits mittelfristig zu besseren Ergebnissen als die vordefinierte Roadmap, die zuverlässig zu einem Ziel führt das von der Zielgruppe mittlerweile längst verlassen worden ist. (Siehe auch: agile Roadmaps)

  • Joe Crick: It Doesn’t Have to be Perfect

    Einige gute Gedanken zum Thema Legacy Code, nicht zuletzt deshalb weil sie nicht aus einer technischen sondern eher aus einer soziologischen Perspektive geschrieben wurden. Folgende Aspekte sind für Joe Crick im Umgang mit Legacy Code wichtig:
    • Respektiere das was er tut: er mag nicht den Standards entsprechen, aber die aus ihm bestehende Anwendung sichert Dein Einkommen.
    • Verstehe wie er entstanden ist: die Organisationsstruktur zur Zeit seiner Entstehung spiegelt sich im Code wieder (→ Conway's Law). Damals hat er vielleicht mehr Sinn ergeben als heute.
    • Lege realistische Standards an: die Aussage aus der Überschrift. Code muss nicht perfekt sein, es reicht wenn er gut ist. Beziehungsweise - gut genug für den Zweck den er erfüllen soll.
    • Sei massvoll in der Beurteilung: in den seltensten Fällen ist Legacy Code der unbrauchbare Mist als der er häufig beschimpft wird. Er mag buggy, kompliziert und umständlich sein, aber dann sollte man ihn auch nur so nennen.
    • Gehe gelassen mit ihm um: Kein Mensch ist perfekt, alle machen Fehler. Und umgekehrt und nicht alles ein Fehler was man selbst nicht versteht. Wer das akzeptiert kann besser mit den Hinterlassenschaften anderer umgehen.
    Gedanken wie diese sind praktisch immer hilfreich, und zwar nicht nur beim Schreiben von Software. Auch im Change- oder Prozessmanagement können sie von Nutzen sein, denn letztendlich ist auch die Struktur einer Firma nichts anderes als organisatorischer Legacy-Code.

  • Steve Blank: What Your Startup Needs to Know About Regulated Markets

    Im Grunde eine Überschrift die bereits alles aussagt. Auch wenn der Focus zu Beginn sehr stark auf den USA liegt sind die hier gemachten Überlegungen auch in jedem anderen stark gesetzlich regulierten Markt von Bedeutung - selbst dann wenn man nicht in einem Startup arbeitet.

Montag, 29. Oktober 2018

Der rotierende Scrum Master

FS
Bild: Pixabay/MoreLight - CC0-1.0
Ein Phänomen das man in manchen Unternehmen beobachten kann ist der "rotierende Scrum Master". Die Rolle ist in diesem Fall nicht fest mit einer Person besetzt sondern wird in jedem Sprint von einem anderen Teammitglied wahrgenommen. Für die Dauer dieser Zeit arbeitet diese Person nicht an der Produktentwicklung mit sondern unterstützt das Team und beseitigt Impediments. Da eine solche Konstellation fast immer kontrovers diskutiert wird, lohnt es sich, einen genaueren Blick darauf zu werfen.

Zunächst die naheliegendste Frage: ist eine Rotation im Rahmen der Methodik überhaupt zulässig? Die Antwort: implizit ja. Der Scrum Guide definiert zwar die drei Rollen des Product Owners, des Scrum Masters und des Teams, legt aber nicht fest, dass es immer die selbe Person ist die sie besetzen muss. So lange alle Rollen besetzt sind ist den Formalien genüge getan.

Es gibt auch gute Gründe für ein Wechseln der Rolle zwischen den Teammitgliedern. Dadurch dass sie früher oder später von jedem ausgeübt wird liegt die Verantwortung für Prozess und Methodik bei allen und nicht nur bei einem. Gleichzeitig steigt auch die Ausfallsicherheit - ein Urlaub oder eine Krankheit des Scrum Masters lässt keine Lücke entstehen, da alle anderen in der Rolle geübt sind und sie übernehmen können.

In vielen Fällen kommt noch dazu, dass sich kein Teammitglied findet, das dauerhaft seinen bisherigen Job aufgeben möchte. Selbst wenn die Sinnhaftigkeit eines Scrum Masters eingesehen und hochgehalten wird finden viele Menschen in der Produktentwicklung eine wesentlich grössere Erfüllung. Muss das nur vorübergehend aufgegeben werden kann das die Besetzung deutlich einfacher machen.

Auf der anderen Seite gibt es auch Gegenargumente. Das naheliegendste ist, dass die Beschäftigung mit Methodik, Moderation, Coachimg, etc. erstaunlich viel Zeit in Anspruch nehmen kann, und zwar nicht nur in der Durchführung sondern auch im Lernen, Weiterbilden, Reflektieren und Perfektionieren. Wird das nicht auch dann vorangetrieben wenn die Rolle gerade nicht ausgeübt wird  kommt es zu kurz um wirksam zu sein (und damit stellt sich auch die Frage nach der dafür verfügbaren Zeit).

Ebenfalls nicht zu vernachlässigen ist, dass durch eine Rotation Neutralität verloren geht. Wer bestimmte Entscheidungen der Produktstrategie oder -umsetzung (mit)verantwortet hat wird sich schwer tun Konflikte zu diesen Themen unbefangen zu moderieren. Schlimmstenfalls wird er selbst als Teil einer Konfliktpartei gesehen und nicht als Vermittler akzeptiert. Um das zu vermeiden ist eine hohe Konflikt- und Meetingkultur aller Beteiligten nötig.

Zuletzt ist es in grösseren Organisationen meistens so, dass die Einheiten und Personen ausserhalb des Scrum Teams sich einen festen Ansprechpartner wünschen. Ist dieser nicht gegeben kann ggf. das Beziehungs- und Vertrauensnetzwerk nicht entstehen, das zur schnellen und unkomplizierten Beseitigung von Impediments nötig ist. Auch das oft praktizierte Geben, Nehmen und Verrechnen von Hilfen und Gefälligkeiten wird schwerer.

Eine immer richtige Entscheidung für oder gegen einen rotierenden Scrum Master kann es aus den genannten Gründen nicht geben, wohl aber eine Entscheidungshilfe: diese Konstellation wird vor allem da funktionieren wo sowohl das Scrum Team als auch die umgebende Organisation Scrum samt des dazugehörenden Mindset sehr gut verstanden haben und es aus intrinsischer Motivation heraus befolgen. Da wo das (noch) nicht gegeben ist kann eine dauerhafte Rollenbesetzung mehr Sinn machen.

Donnerstag, 25. Oktober 2018

Backlog-Priorisierung

FS

Die Priorisierung noch zu erledigender Arbeit scheint auf den ersten Blick ein Thema zu sein in dem sich agile und klassische Vorgehensweisen kaum unterscheiden. Auch vor der Erfindung von Scrum und Co wurde schon überlegt welche Aufgaben wichtiger und welche unwichtiger sind. Auf den zweiten Blick tun sich dagegen Unterschiede auf, die vor allem mit einem Instrument in Verbindung stehen - dem Product Backlog.

Um zu verstehen warum diese Art der Priorisierung anders ist empfiehlt sich ein Blick darauf wie Priorisierung klassischerweise stattfindet. In den meisten Unternehmen bekommen Anforderungen entweder eine Wichtigkeitsklasse (z.B. Minor, Medium, Major, Blocker) oder eine die Bedeutung anzeigende Zahl zugewiesen (z.B. 1 = unwichtig bis 100 = extrem wichtig). Je höher diese Wichtigkeitsklasse, bzw. diese Zahl sind, desto höher die Priorität.

Was in der Theorie zunächst einfach und nachvollziehbar klingt erweist sich in der Realität in der Regel als unpraktikabel. Da jeder Stakeholder ein Interesse daran hat, dass seine Anforderungen zuerst umgesetzt werden, wird er sich um eine hohe Bewertung bemühen. Im Zweifel wird ihm diese auch zugestanden werden, da mit dieser Einstufung ja noch keine weiteren Zusagen verbunden sind. Es geht an dieser Stelle nur um die Wichtigkeit, noch nicht um die Machbarkeit.

Schon nach kurzem wird dieses Vorgehen dazu führen, dass eine hohe zwei- oder dreistellige Zahl an Anforderungen als Blocker, bzw. zwischen 90 und 100 eingeordnet wird. Ist dieser Punkt erreicht ist die Priorisierung wertlos geworden. Wenn alles super-wichtig ist, dann ist alles gleich (un)wichtig. Übliche Reflexe sind jetzt die Erweiterung der Skala (z.B. um einen Showstopper-Status oder um die Zahlen 101 bis 110), was aber bald auch wieder entwertet sein wird.

Die Einträge eines Product Backlog werden dieser Bedeutungs-Inflation normalerweise bewusst entzogen, indem auf Wichtigkeitsklassen einfach verzichtet wird. Die Priorität ergibt sich hier anders, nämlich durch die Natur des Backlogs selbst. Dieses ist keine Ansammlung von unterschiedlich wichtigen Teilmengen mehr (deren jeweilige Einzelteile unter sich gleichwertig sind), sondern etwas viel Einfacheres - eine sortierte Liste.

Was eine solche Liste besonders macht ist, dass auf ihr keine Punkte nebeneinander stehen können sondern nur untereinander. Aufgelistet eben. Es gibt also immer einen wichtigsten Eintrag, einen zweitwichtigsten, einen drittwichtigsten, etc. Und wo auch immer man eine neue Anforderung dazwischenschiebt, sie wird immer jeweils ober- und unterhalb einer anderen stehen und damit automatisch priorisiert sein.

Es bleibt die Frage - wenn es so einfach ist, warum macht es dann nicht jeder so? Die Antwort - weil ein als Liste sortiertes Backlog seinen Verwalter dazu zwingt, Konflikte sowohl früh als auch immer wieder auszutragen. Es ist mit diesem Vorgehen nicht mehr möglich, jeden wichtigen Stakeholder zufriedenzustellen indem man ihm die höchste Wichtigkeitsklasse gibt. Wenn seine Idee auf Position 43 von 120 liegt (und demnach nicht so schnell umgesetzt werden wird) dann sieht er das sofort und kann das eskalieren.

Um derartige Konflikte zu vermeiden wird häufig die klassische Art der Priorisierung bevorzugt. Die Auseinandersetzungen tauchen zwar auch hier auf, aber erst wesentlich später, wenn den Beteiligten langsam dämmert, dass die scheinbar hohe Priorität weitgehend ohne Aussagekraft ist. Manche Organisationen haben es zu erstaunlicher Meisterschaft darin gebracht, diesen Punkt immer weiter nach hinten zu verlagern, mit langen Phasen des Stillstands als Folge.

Zu lernen, dass das kein zielführender Weg ist, und dass das frühe (und konstruktive) Austragen von Konflikten zwar schmerzhaft aber letztendlich besser ist, ist Teil des zu agilen Transitionen gehörenden Kulturwandels. Der ist zwar mitunter unangenehm, bringt aber einen grossen Vorteil mit sich: man ist plötzlich in der Lage Priorisierungen durchzuführen, in einer Art die diesen Namen auch verdient.

Montag, 22. Oktober 2018

Deine Muda: Warten

FS
Bild: Wikimedia Commons / Siyuwj - CC BY-SA 3.0
Fünfter Teil der Deine Muda-Serie. Die vierte Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist das Warten. Ein interessanter Aspekt - auch das erzwungene Nichtstun kann demnach eine zu vermeidende Tätigkeit sein. Max Weber wäre begeistert.

Ähnlich wie in vielen anderen Zusammenhängen ist auch das Warten aus mehr als einem Grund problematisch. Zum einen weil es dazu führt, dass bestimmte Arbeiten später fertig werden, zum anderen wegen der Tätigkeiten die währdenddessen durchgeführt werden. Denn Nichtstun bedeutet in diesem Kontext nicht etwa völlige Untätigkeit, sondern lediglich die Untätigkeit in Bezug auf eine bestimmte Arbeit.

Zunächst aber zu den Verspätungen. Man kann es ohne grosse Erläuterungen verstehen: wenn ein Produktionsprozess immer wieder so lange angehalten werden muss, bis bestimmte Vor- oder Zuarbeiten erledigt sind, dann verlängert sich dadurch die Produktionsdauer. Wie im Fall fast aller anderen Mudas wird das Produktionsmaterial dadurch zeitweise dem Wirtschaftskreislauf entzogen. Es entsteht totes Kapital. Aber das ist noch nicht alles.

Als zweiter Effekt kommt es zu dem so genannten Cost of Delay, bzw. zu Verspätungskosten. Wäre der Produktionsprozess schon früher beendet gewesen, hätte man mit seinem Ergebnis bereits Geld verdienen können. Die Summe die einer Firma dadurch entgeht, dass das nicht möglich ist, ist mit dem Begriff des Cost of Delay gemeint.

Auch damit sind aber noch nicht alle negativen Effekte erwähnt. Was noch fehlt sind die weiter oben genannten Tätigkeiten die währdenddessen durchgeführt werden. Mit dem Warten ist nämlich das Warten des Produkts auf seine Fertigstellung gemeint, nicht etwa das Warten eines Angestellten auf Beschäftigung. Der beginnt in der Regel währenddessen bereits mit dem nächsten Arbeitspaket.

In der Praxis sieht das so aus, dass sobald an einer Arbeit kein Fortschritt mehr möglich ist eine zweite begonnen wird, sobald es auch an der nicht mehr weitergeht eine dritte, etc. Sobald die für das Weiterarbeiten an der ersten Aufgabe notwendige Zulieferung erfolgt ist werden die später begonnenen unterbrochen, es geht mit der ersten weiter, nach deren Abschluss wieder mit den späteren.

Wird auf diese Art und Weise vorgegangen treten aber zwangsläufig Probleme auf: zum einen das Multitasking mit seinen üblichen Begleiterscheinungen von Konzentrationsverlust und Umgewöhnungsaufwand, zum anderen Priorisierungskonflikte. Was ist jetzt wichtiger, die Wiederaufnahme der schon länger wartenden ersten Aufgabe oder das störungsfreie Weiterarbeiten an einer späteren? Auch diese Konflikte kosten Zeit und Geld.

In Summe sind die genannten Folgen von Wartephasen im Produktionsprozess so kostspielig, dass nach Möglichkeit versucht werden sollte sie zu vermeiden. Die einfachste Möglichkeit dazu ist die Bildung eines Crossfunktionales Teams. Wenn alle Tätigkeiten selbst erledigt werden können verschwindet mit der Abhängigkeit von anderen Gruppen die häufigste Ursache des Wartens.

Auch andere Ansätze sind möglich, etwa die bessere Abstimmung von Teams untereinander (Just in Time-Delivery) oder das Anhäufen von Vorarbeiten in einem ausreichenden Ausmass um später nicht in Leerlauf zu geraten (ein durchaus sinnvolles, aber häufig auf andere Art problematisches Vorgehen, das man sich gut überlegen sollte).

Was auf jeden Fall bewusst sein sollte: Bemühungen zur Vermeidung von Wartezeiten führen häufig zu anderen nicht gewinnbringenden Tätigkeiten (Transport, Lagerhaltung, etc.), deren Optimierung möglicherweise wieder zu neuen Wartezeiten führt. Der so entstehende Verbesserungsprozess ist dadurch nie abgeschlossen - was auch absolut Sinn macht.

Donnerstag, 18. Oktober 2018

Agile Workshops

FS
Bild: Pxhere / Rawpixel - CC0 1.0
Zu den Aufgaben die ich bei verschiedenen Kunden habe gehört das Halten von Schulungen und Workshops. Einführung in die Grundlagen agilen Arbeitens, Einführungen in Scrum oder Kanban, Product Ownership, Skalierung, Backlog Management, etc. Mitunter werde ich sogar nur für einzelne derartige Veranstaltungen gebucht. Mein Anspruch ist dabei, dass der Begriff Agile Workshop in mehr als einer Hinsicht zuteffend ist: in Bezug auf den Inhalt aber auch in Bezug auf die Durchführung.

Ein agiler Workshop im Sinn der Durchführung ist in meinem Verständnis gegeben wenn noch während seiner Laufzeit auf sich ändernde Wünsche und Fragen eingegangen werden kann. Ein Exkurs Richtung Lean Startup wird gewünscht? Ein Eingehen auf alternative Schätztechniken wie #Noestimates? Fallbeispiele für Agilität ausserhalb der IT? Alles machbar, und zwar alles sofort, aus der Veranstaltung heraus.

Dass das möglich ist liegt daran, dass ich meine Schulungs- und Workshop-Inhalte in Module eingeteilt habe. Ein Modul agile Basics, ein Modul Scrum, ein Modul User Stories & Story Points, etc. Jedes dieser Module habe ich schon mehrfach durchgeführt, so dass ich es schnell parat habe. Und (in dem Kontext noch wichtiger) sie sind so geschnitten, dass sich einzelne oder mehrere von ihnen hinzufügen, ersetzen oder in ihrer Reihenfolge vertauschen lassen.

Dieses Vorgehen bietet Vorteile für beide Seiten: die Teilnehmer können auch noch kurzfristig Themenwünsche äussern, die (sofern sie nicht zu exotisch sind) sofort erfüllt werden können, für mich bietet es die Möglichkeit hohe Flexibilität mit berechenbarer Durchführung zu verbinden. Und auch ein weiterer Punkt kommt noch dazu - wenn ich interne Scrum Master oder Agile Coaches ausbilde können sie einzelne Module erlernen und nach und nach in den Workshops übernehmen.

Ganz ohne Voraussetzungen geht das natürlich nicht. Die Module muss man parat haben und man muss in der Lage sein kurzfristig zwischen ihnen hin- und herzuschalten. Die Agenda sollte kurzfristig modifizierbar sein (ich benutze Post Its, die sich einfach umhängen und austauschen lassen). Nicht zuletzt würde ich immer von den zu statischen Powerpoint-Präsentationen abraten und stattdessen im Rahmen der Veranstaltung Flipcharts bemalen und beschreiben. Alles das muss man können.

Angesichts des deutlich gesteigerten Ausmasses an Flexibilität und Kundenorientierung sind das allerdings Mühen von denen ich überzeugt bin, dass man sie auf sich nehmen sollte wenn man agile Workshops (in beiden Begriffsbedeutungen) durchführen will. Denn eine agile Wissensvermittlung die selbst nicht agil ist - wäre das nicht ein Widerspruch in sich?

Montag, 15. Oktober 2018

Ein Bild sagt mehr als 1000 Worte (XXII)

FS
Für den nächsten, der Innovationsbemühungen abbügeln will indem er davor warnt, das Rad neu zu erfinden.


Donnerstag, 11. Oktober 2018

Wo Politik herkommt und wie man sie loswird

FS
Eine kurze Bemerkung zum Kontext: in Firmen und ähnlichen Organisationen versteht man unter Politik nicht Regierungen, Parlamente und Wahlen sondern die unnötige Verkomplizierung von Abläufen durch Machtspiele und Konflikte zwischen Personen und Gruppen. Mit dieser Information im Hinterkopf: Bühne frei für Katherine Kirk.

Montag, 8. Oktober 2018

Warum niemand zum Sprint Review kommt

FS
Bild: Pixabay / Magic Desk - CC0 1.0
Es ist eine traurige Geschichte die ich schon von vielen Scrum Teams gehört habe: der Sprint ist beendet, alle Anforderungen sind umgesetzt, alles ist in einem präsentationsfähigen Zustand - aber kein einziger Stakeholder erscheint zum Review Meeting. Nach zwei Wochen Arbeit ist das frustrierend, aber es geschieht selten ohne Grund. Folgende Ursachen habe ich bereits bei verschiedenen Teams erleben dürfen:

Es gibt keine Stakeholder

So einfach ist es manchmal. Wenn z.B. die aktuellen Entwicklungsziele die Kopfgeburt eines einzelnen Topmanagers sind, die dieser gegen den Willen aller Beteiligten durchgesetzt hat, dann ist es nicht verwunderlich wenn ausser ihm keiner erscheint.

Es wurden keine Features entwickelt, sondern Komponenten

Wenn das was entwickelt wurde nicht benutzbar und bewertbar ist, warum sollte dann jemand zum Review kommen wollen? Es gibt ja nichts worüber man reden könnte (und ganz nebenbei hat dieses Vorgehen auch nicht viel mit Scrum zu tun).

Es gab kein Sprintziel / keinen Fokus im Sprint


Wenn ein Sprint kein Ziel hat sondern stattdessen unterschiedliche Anforderungen hineingestopft werden stellen viele Stakeholder die Sinnfrage. Lohnt sich ein zweistündiges Meeting wirklich, wenn für jeden nur ein Feature dabei ist, das von Interesse ist? Eher nicht.

Es ist kein Review sondern eine Demonstration

Manche Teams führen kein Sprint Review durch sondern ein Demo-Meeting. Der Unterschied: Neuerungen werden nur vorgeführt und nicht diskutiert. Wird den Stakeholdern so die Möglichkeit zum Feedback geben genommen sinkt erfahrungsgemäss die Teilnahmebereitschaft.

Es gab keine Ankündigung

Da nicht jedes Thema für jeden gleich interessant ist kommen viele Stakeholder nicht zu jedem Review. Um sie zu aktivieren hilft es, wenn die Inhalte mit einigen Tagen Vorlauf kommuniziert werden, so dass klar ist ob sich das Erscheinen lohnt.

Die Vorführung der neuen Features ist konfus oder lustlos

Wer die Teilnehmer eines Meetings nicht ernstnimmt muss sich nicht wundern wenn sie wegbleiben. Und ein nicht vorbereitetes, unstrukturiertes oder widerwillig durchgeführtes Review ist ein Zeichen, dass dieses nicht ernst nehmen stattfindet.

Es gibt keine gemeinsamen Reviews

Ein Sonderfall für Projekte oder Produkte mit mehreren Teams. Wenn es den Anschein hat, dass zu viele Meetings stattfinden neigen, Stakeholder dazu nicht mehr alle zu besuchen. Die einzelnen Reviews zusammenzulegen kann dem entgegenwirken.

---

Natürlich gibt es noch viele weitere mögliche Gründe dafür, dass Sprint Reviews schlecht besucht sind, diese hier sind mir aber vergleichsweise häufig aufgefallen. Behebt man sie ist zumindest die Wahrscheinlichkeit, dass sich weitere Teilnehmer einfinden, deutlich höher.

Freitag, 5. Oktober 2018

Red Flag Laws

FS
Bild: Wikimedia Commons / Santeri Viinamäki - CC BY-SA 4.0
Zu den vermutlich skurrilsten gesetzlichen Regelungen der Technikgeschichte gehören die so genannten Red Flag Laws, die im späten 19. Jahrhundert in Grossbritannien und Teilen der USA erlassen wurden. In ihnen wurde geregelt, dass jedem motorisierten Fahrzeug eine Aufsichtsperson vorauslaufen und dabei eine rote Fahne schwenken musste. Das zu dieser Zeit gerade erst erfundene Auto, dessen Stärke ja gerade die Geschwindigkeit war, wurde damit praktisch unbrauchbar.

Dass diese Gesetze erlassen wurden hatte natürlich einen Grund: die Parlamente befürchteten, dass von motorisierten Fahrzeugen eine erhöhte Unfallgefahr ausgehen könnte. Anders als ein Pferd würden sie schliesslich nicht von sich aus vor einem Hindernis stehen bleiben. Als die Erfahrungen zeigten, dass diese Sorge unberechtigt war, war der Schaden bereits angerichtet - andere Länder hatten sich einen technischen und wirtschaftlichen Vorsprung erarbeitet.

Das Problem der Red Flag Laws ist, dass sie zwar auf den ersten Blick wie ein Anachronismus aus einer längst vergangenen Zeit wirken, auf den zweiten aber hochaktuell sind. Der Unterschied ist nur, dass es sich heute nicht mehr um Autos handelt, die aus Sorge vor Unkontrollierbarkeit überreguliert werden, sondern um andere Aspekte des technischen oder organisatorischen Fortschritts.

Gerade in den Konstellationen agiler Transitionen sind gut gemeinte aber in ihren Auswirkungen verheerende Regulierungen häufig. Ein Product Owner der alleine Produktentscheidungen treffen darf? Den kontrolliert man besser durch ein Lenkungsgremium. Automatisierte Tests und Deployments? Nur wenn jeder von ihnen durch einen Menschen manuell überprüft wurde. Selbstorganisierte Teams wählen ihre Tools selber aus? Ja, aber nur aus denen die vorher von einer zentralen Stelle zertifiziert wurden.

Die Folgen sind die gleichen wie damals im 19. Jahrhundert: zunächst fühlt sich die Veränderung besser (weil beherrschbarer) an, aber irgendwann dämmert die Erkenntnis, dass man sich ohne Not gerade die Potentiale verbaut hat wegen derer die neuen Methoden und Techniken überhaupt eingeführt wurden. Und währenddessen sind die Wettbewerber mit weniger Berührungsängsten schon längst vorbeigezogen und haben Marktanteile übernommen.

Nach Red Flag Laws im eigenen Unternehmen zu suchen und sie abzuschaffen kann ein schmerzhafter Prozess sein, da es fast immer bedeutet, dass man sich eingestehen muss, aus bestem Willen heraus Mist gebaut zu haben. Das nicht zu tun wäre aber noch schlimmer, was man sich an einem einfachen Beispiel vor Augen führen kann: wie wäre es wohl heute um Grossbritannien bestellt wenn noch immer vor jedem Auto ein Mensch mit eine einer roten Fahne herlaufen müsste?

Dienstag, 2. Oktober 2018

Eine Entscheidungshilfe für Scrum Master-Communities

FS
Was sich in den Unterlagen der vergangenen Jahre so findet. In diesem Fall eine Entscheidungshilfe für die Scrum Master-Community eines ehemaligen Kunden. Besagte Community hatte die Tendenz sich in ausufernden Debatten darüber zu verlieren, ob ein Probem, bzw. Impediment wichtig genug wäre um die gesammelten Kraft aller Scrum Master in Anspruch zu nehmen oder nicht. Um diese Diskussionen zu verkürzen entstand das folgende Bild:
Zu den einzelnen Verzweigungen. Bereits die erste ist weniger selbstverständlich als man denken sollte. Manche Probleme lassen sich eben gar nicht lösen, beispielsweise der Baustellen-Lärm vom Nachbargrundstück. Ist das der Fall, ist jede Diskussion vergebens und man kann sie einfach sein lassen. Sie bringt nichts. Auch an der zweiten Verzweigung halten sich manche Scrum Master länger auf als es Sinn macht. Wenn jemand anders ein Problem besser lösen kann als man selbst sollte man es vertrauensvoll dorthin übergeben, beispielsweise die Überprüfung der Eingänge auf Barrierefreiheit an den Gleichstellungs-Beauftragten. Nur wenn es niemanden gibt der besser geeignet ist sollte man selbst tätig werden.1

Selbst wenn ein Problem in den eigenen Einflussbereich fällt, gibt es aber noch eine weitere Frage zu beachten: betrifft es wirklich alle Teams oder nur einen Teil von ihnen? Ist das letzte der Fall sollte man davon absehen Regeln für alle Teams einzuführen, sonst würde einigen von ihnen eine Lösung aufgenötigt für die sie kein Problem haben - es wäre Überregulierung. Ein Beispiel dafür wäre die Qualitätssicherung von Anforderungen durch die Einführung einer Definition of Ready. Betroffene Teams können sich selbst eine geben, anderen brächte sie zwar Aufwand aber keinen Mehrwert.

Entscheidungshilfen wie diese scheinen auf den ersten Blick zwar banal zu sein, trotzdem kann es Sinn machen sie im Teamraum einer Scrum Master-Community gut sichtbar aufzuhängen. Auch die besten Scrum Master können mitunter Züge von Betriebsblindheit, Helfersyndrom und Selbstüberschätzung aufweisen und Group Think entwickeln. Gegen diese Phänomene ist die oben zu sehende Grafik zwar kein Allheilmittel, sie kann aber ein Anstoss zur Selbstreflektion und zu einer realistischeren Betrachtung der Umstände sein. Oft ist das schon genug um die Situation zu verbessern.


1Es sei denn, der besser Geeignete hat keine Zeit.

Samstag, 29. September 2018

Kommentierte Links (XXXXI)

FS
  • Markus Raitner: Die modernen Hofnarren

    Einerseits ist das was Markus Raitner hier schreibt absolut richtig - dadurch dass ein Scrum Master (bis zu einem gewissen Grad) von den Konventionen und sozialen Barrieren eines Unternehmens entbunden ist kann er Dinge ansprechen die von anderen nicht angesprochen werden können. Andererseits ist eine Konstellation in der das zutrifft hochgradig dysfunktional, bedeutet es doch, dass "normale Angestellte" eben nicht die Erlaubnis haben Kritik zu üben. Der Scrum Master-Hofnarr kann demnach zwar in einer Übergangsphase seine Berechtigung haben, als ständige Institution wäre er aber ein Anzeichen dafür, dass die agile Transition gescheitert ist.

  • Trish Khoo: Make a technical debt payment plan

  • Eine grossartige Idee! Wenn die finanziellen Schulden eine passende Inspiration für die Metapher der technischen Schulden sind, dann kann auch der Abbau technischer Schulden mit einem Begriff aus dem finanziellen Umfeld beschrieben werden. Ein Rückzahlungsplan wie man ihn für die Befreiung aus erdrückenden Verbindlichkeiten benötigt macht in der IT genau so viel Sinn wie bei der Haushaltsplanung: welche Schulden sind die drängendsten und dringensten, mit welchen Schritten kann ihr Abbau angegangen werden und wer wird sich dieser Schritte annehmen? Peter Zwegat wäre begeistert.

  • Krishna Kandala: Business agility for speed to market - Applying design & agile thinking to drive consumer value

    Der beste Weg in Richtung Zukunft ist die beständige Lieferung kleiner, funktionsfähiger, Mehrwert stiftender Neuerungen und Erweiterungen. Der Versuch in wenigen, grossen, seltenen Schritten riesige Fortschritte zu erzielen macht schwerfällig und vervielfacht das mit Fehlentscheidungen einhergende Risiko. Was in der IT Common Sense ist versucht Krishna Kandala auf die Business-Welt zu übertragen. Ein zentraler Punkt seiner Überlegungen: grosse Unternehmen haben in der Regel kein Problem mit der Entwicklung neuer Ideen, sie tun sich aber sehr schwer damit, daraus vermarktbare Produkte zu machen - und zwar weil sie ihre grossen Visionen nicht in kleine Incremente herunterbrechen können.

  • Mike Cohn: What Does It Mean to Be Potentially Releasable?

    Einer der wichtigsten Sätze im Scrum Guide ist: "The increment must be in useable condition regardless of whether the Product Owner decides to release it." Was für diesen Zustand nötig ist und was nicht ist Gegenstand umfassender und beständig wiederkehrender Debatten. Die Gedanken die sich Mike Cohn hier macht umfassen vieles davon und gehen an einer wichtigen Stelle noch einen Schritt weiter - was sollte man tun wenn man merkt, dass ein Increment nicht "potentially releasable" sein wird? Sein Ratschlag: die Arbeit daran unterbrechen, bzw. beenden. Interessant ist auch was er nicht empfiehlt: den Sprint-Abbruch.

  • Ron Jeffries: XP revisited

    Einmal mehr ein typischer Ron Jeffries-Text. Sehr lang, sehr gehaltvoll, sehr zu empfehlen. Im Mittelpunkt die Frage: wenn Extreme Programming heute neu erfunden, bzw. neu eingeführt werden würde - was wären seine Kernelemente?

Dienstag, 25. September 2018

Warum Agile/Scrum ohne Testautomatisierung nicht funktioniert (III)

FS
Bild: NASA - Public Domain
Mitunter bekommt man als Agile Coach die aberwitzigsten Probleme mit. Ein derartiger Fall ist mittlerweile schon etwas her aber immer noch bemerkenswert: er dreht sich um eine Anwendung eines grossen Konzerns, deren Entwicklung irgendwie agil werden sollte, wobei aber ein nicht ganz unwesentliches Hindernis im Weg stand - die Regressionstests wurden noch weitgehend manuell durchgeführt. Es waren viele. Sehr viele.

Es handelte sich um ein System mit mehreren über die Jahrzehnte zugekauften und integrierten Teilsystemen, die durch zahlreiche Schnittstellen verbunden waren. Insgesamt 75.000 Testfälle (!) mussten jedes mal durchgeklickt werden um sicherzustellen, dass neuentwickelte Features nicht versehentlich bestehende Anwendungsteile beschädigt hatten. Eine ungeheuerliche Zahl, deren Bewältigung nur möglich war weil Offshore-Testing in irgendeinem asiatischen Land mit niedrigen Löhnen betrieben wurde.

Die Durchführung eines solchen Regressionstestzyklus dauerte etwa ein Jahr, bei den letzten Malen waren dabei jeweils knapp 7000 kritische Bugs (→ funktionale Fehler ohne möglichen Workaround) entdeckt worden. Da nach dem Beheben dieser Bugs ein weiterer Regressionstestzyklus zu lange gedauert hätte wurden die Bugfixes gleichzeitig mit neuen Features eingecheckt, was natürlich Merge-Konflikte verursachte. Die Folge war das erneute Auftreten tausender Fehler, womit der Kreislauf von neuem begann.

Warum in diesem Fall nicht einmal im Entferntesten an agile Softwareentwicklung zu denken war ist offensichtlich: ein einziges, dazu noch Bug-verseuchtes, Grossrelease pro Jahr? Das ist weit, weit, weg von der Auslieferung nutzbarer Inkremente mehrfach pro Monat. Um weitgehend fehlerfreie Anwendungen auszuliefern hätte man sogar mindestens einen Regressionstestzyklus einer Bugfix-Welle abwarten müssen, in Summe hätte es dann zwei Jahre gedauert.

Wie man denn aus dieser Situation hauskommen könnte, war die Frage. Ein nachträgliches Automatisieren der Testfälle wäre wegen fehlendem Budget nicht möglich, ob es denn andere Wege gäbe agil zu arbeiten? Als das verneint wurde war relativ schnell klar, "dass Agil wohl nicht das Richtige für uns ist." Quod erat demonstrandum. Zwei Jahre später kam es zu einem zufälligen Treffen mit einem Kollegen des Testmanagers, der sich so geäussert hatte. Mittlerweile waren es keine 75.000 Testfälle mehr. Die Zahl war deutlich höher.

Freitag, 21. September 2018

Die agile Legion

FS
Dass die Agilität einen Grossteil ihrer Ursprünge in der Kriegsführung hat ist eine jener unangenehmen Wahrheiten die man gerne verschämt unter den Tisch fallen lässt. Und doch ist es so - von den Abhandlungen des Generals von Clausewitz bis zu den selbstorganisierten mongolischen Reiterhorden des Dschingis Khan zieht sich eine lange Spur erfolgreicher militärischer Anwendungen agiler Ansätze durch die Geschichte. Ein weiterer, noch länger zurückliegender betrifft eine der bekanntesten Armeen der aller Zeiten: die römischen Legionen. Anschaulich erklärt wird es in diesem Video:



Was durch Beispiele wie dieses klarer wird: Agilität ist keine Mode, kein Hype und kein Trend, sondern ein uralter (mindestens 2000 Jahre alter) Organisationsgrundsatz: dezentrale und anpassungsfähige Organisationen sind auf Dauer den zentralisierten, auf Planerfüllung ausgerichteten überlegen, und zwar selbst dann wenn sie zu Beginn noch in einer eher unterlegenen Position waren. Spätestens dann wenn "das Terrain unwegsam wird" bringen Grösse und Kraft alleine keinen Vorteil mehr.

Montag, 17. September 2018

It's all about People

FS
Ich habe Gitte vor einigen Jahren auf einem Agile Coach Camp kennengelernt und kann bestätigen: sie umarmt Menschen, auch solche die sie nicht kennt. Das dürfte im Zusammenhang damit stehen, dass sie Agilität sehr stark von der menschlichen Seite aus betrachtet. So wie in diesem Talk.

Donnerstag, 13. September 2018

Maximum Work in Progress

FS
Bild: Flickr / Alexander Baxevanis - CC BY 2.0
Ein häufiges Problem in Organisationen jeglicher Grösse ist das Untergehen in zu viel gleichzeitig begonnener Arbeit. Das Wechseln zwischen den verschiedenen Kontexten kostet Konzentration und begünstigt Verwechselungen und darauf folgende Fehlentscheidungen, die Menge paralleler Aufgaben sorgt dafür, das Übersichtlichkeit verloren geht und die Vielzahl wartender Stakeholder führt zu Konflikten und Meeting-Overhead. Derartige Zustände müssen verhindert werden, und zum Glück gibt es dafür auch einen Lösungsansatz.

Die Menge der übernommenen Aufgaben lässt sich in den Griff bekommen indem man sich selbst eine Obergrenze setzt (das ist sowohl für einzelne Personen als auch für ganze Teams möglich). Ist diese Grenze erreicht wird kein weiteres Arbeitspaket angenommen. Erst dann wenn eine der begonnenen Tätigkeiten abgeschlossen wird kann eine neue begonnen werden. Diese Obergrenze (das Maximum Work in Progress Limit) ist ebenso einfach wie wirksam - und fast nirgendwo gelingt es sie einzuhalten.

Angesichts des wunderbar einfach anmutenden Werkzeug des Maximum Work in Progress Limit gerät schnell in Vergessenheit, dass hinter gleichzeitigem Arbeiten an zahlreichen Aufgaben in der Regel keine Fahlrässigkeit steckt sondern Notwendigkeit. In arbeitsteilig geprägten Organisationen ist fast niemand mehr in der Lage eine Aufgabe alleine abzuschliessen, immer wieder muss auf Zulieferungen, Genehmigungen, Abnahmen oder Informationen gewartet werden. Manchmal stundenlang, manchmal wochenlang, manchmal noch länger. Um in dieser Zeit nicht untätig sein zu müssen fängt man eben mit der nächsten Tätigkeit an. Und der übernächsten. Und so weiter.

Wirksame Obergrenzen bedeuten demnach in der Regel nicht, dass man sich selber diszipliniert. Wirksame Obergrenzen bedeuten, dass man sich um vorgelagerte, nachgelagerte und parallele Prozesse kümmern muss. Erst wenn die so beschleunigt werden, dass man nicht mehr gezwungen ist auf sie zu warten kann man sich auf wenige gleichzeitige Tätigkeiten beschränken ohne dadurch immer wieder in Phasen der unfreiwilligen Untätigkeit zu geraten.

Um diese Beschleunigung umgebender Prozesse zu erreichen können je nach Kontext verschiedene Massnahmen sinnvoll sein. Die Aufstockung von Ressourcen, der Abbau von Vorschriften oder die Rücknahme lokaler Optimierungen können helfen, meistens können diese Massnahmen aber nicht selbst eingeleitet werden sondern nur von den jeweils betroffenen Einheiten. Mit Glück sind diese auch dazu bereit und in der Lage, mit Pech sind sie es nicht. Es bleibt dann nur noch ein Ausweg: selber machen.

Sowohl viele der vorgelagerten Schritte (Anforderungserhebung, Design, Abstimmung) als auch nachgelagerte Tätigkeiten (Test, Rollout) können von den meisten Entwicklungteams selber übernommen werden, wenn ihnen der nötige Freiraum und die nötigen Werkzeuge gegeben werden. Das genehmigt zu bekommen ist die eigentliche Herausforderung beim Versuch ein Maximum Work in Progress zu etablieren. Und die damit verbundenen Schwierigkeiten sind der Grund dafür, dass man wirksame Obergrenzen so selten finden kann.

Montag, 10. September 2018

Der Empfangstest

FS
Bild: Wikimedia Commons / Deniz Gültekin - CC BY-SA 3.0
Eines der grössten Probleme in der Produktentwicklung ist zu geringes oder zu spätes Nutzer-Feedback zu den entwickelten Features. Zahllose Produkte sind am Markt vorbeientwickelt worden und haben nichts als finanzielle Verluste und Demoralisierung der Entwicklungsteams erzeugt. Um all das zu vermeiden gibt es nur einen Weg: einem potentiellen Kunden möglicht früh eine erste Version vorlegen und ihn nach seiner Meinung fragen.

Der klassische Weg das zu tun ist die Beauftragung eines internen oder externen Partners, der dann in den Fussgängerzonen der Grossstädte Passanten anspricht und in einen Befragungsraum bittet. In Bezug auf Professionalität und Reichweite noch immer der beste Ansatz, allerdings mit dem Nachteil behaftet, dass damit ein relativ hoher Zeitaufwand verbunden ist. Die Marktforscher müssen gebrieft werden, die Ergebnisse konsolidiert werden, etc.

Ein schnellerer und direkterer Weg ist eine "interne Marktforschung" im eigenen Unternehmen. Vor allem in grösseren Firmen mit hunderten oder tausenden von Mitarbeitern können sich so schon erste Feedbacks zu Verständlichkeit, Usability und Nachfrage ergeben, die man in die weitere Planung einfliessen lassen kann. Damit ist aber auch das Risiko verbunden, dass Betriebsblindheit in das Feedback einfliesst, da die eigenen Mitarbeiter keinen unbefangenen Blick mehr haben.

Eine gute Massnahme um dem entgegenzuwirken ist die Auswahl von Gesprächspartnern aus thematisch möglichst weit entfernten Unternehmensteilen. Bestenfalls mit einer so grossen Distanz, dass ihnen nicht nur die Entwicklungsabteilung fremd ist sondern auch die branchenspezifische Fachsprache, die bisherigen Altprodukte und der Markt mit seinen Konkurrenzanbietern.

Sehr gute Erfahrungen haben wir bei einem Kunden mit dem Empfangspersonal der verschiedenen Gebäude gemacht (für diese Interviews setzte sich schnell der Begriff "Empfangstest" durch). Die dort arbeitenden Damen und Herren standen in ihrem täglichen Alltag so weit ausserhalb der Arbeit der Produktentwicklung, dass sie einen unvoreingenommeneren und neutraleren Blick hatten als alle anderen Kollegen des Unternehmens.

Sich auf die Suche nach solchen Mitarbeitern zu machen ist hochgradig sinnvoll wenn um der Geschwindigkeit willen die ersten Nutzerbefragungen intern durchgeführt werden sollen. In den meisten Firmen gibt es auch mehr von ihnen als man denkt, man muss nur die Augen offenhalten - zum Beispiel beim Betreten des Gebäudes.

Donnerstag, 6. September 2018

Untertanenkultur

FS
Bild: Public Domain Pictures - CC0 1.0
Zu den Demonstrationen von Rechtsradikalen und "besorgten Bürgern" die in den letzten Tagen in Chemnitz stattgefunden haben ist eigentlich schon alles gesagt worden (und Politik soll auch nicht das Thema dieser Website werden). Es gibt aber einen Aspekt der gesondert herausgehoben werden kann, weil er auch über die Politik hinaus eine Bedeutung hat: die von einem Teil der Demonstranten geäussterte unspezifische Erwartung, "irgendjemand" müsste sofort "irgendetwas" tun um die Gesamtsituation zu verbessern (ein Beispiel hier).

Hinter einer solchen Erwartung stehen mehrere verschiedene Grundeinstellungen. Zum einen die, dass derjenige der sich so äussert nicht selbst aktiv werden möchte. "Jemand anders soll tätig werden, nicht ich." Paradoxerweise ist das verbunden mit einem Gefühl der Dringlichkeit. "Es muss etwas passieren, und zwar jetzt." Zuletzt ein offenes Desinteresse an einer Beteiligung an der Lösungsfindung. "Was gemacht wird interessiert mich nicht, solange dadurch alles besser wird."

Diese Grundeinstellungen sind vor allem in grossen Organisationen wie Behörden oder Konzernen immer wieder anzutreffen. Die Ursache dafür (die auch die Verbindung zu den in der DDR großgewordenen "besorgten Bürgern" bildet) ist die private und/oder berufliche Sozialisation in hierarchischen, von Befehl und Gehorsam geprägten sozialen Systemen. Man spricht in diesem Zusammenhang von einer "Untertanenkultur", einem Begriff der eine nähere Betrachtung wert ist.

Geprägt wurde er von den beiden amerikanischen Politikwissenschaftlern Gabriel Almond und Sidney Verba in ihrem Werk "The Civic Culture". Basierend auf tausenden von Interviews in mehreren von einer Untertanenkultur geprägten Ländern konnten sie aufzeigen, dass diese auf vier Annahmen beruht:
  • Der einzelne Mensch ist schwach und nichts bewirken
  • Das Gesamtsystem ist stark und kann alles erreichen
  • Der Einfluss des Einzelnen auf die Hierarchie ist winzig
  • Der Einfluss der Hierarchie auf den Einzelnen ist gewaltig
Es ist erkennbar: wer ein Weltbild hat das auf diesen vier Annahmen beruht wird fast zwangsläufig die Erwartungshaltung entwickeln, dass "die da oben" von sich aus darauf kommen müssen, wie eine als problematisch wahrgenommene Situation verbessert werden kann. passiert das nicht wird es als Systemversagen wahrgenommen, was zu Frustration und Wut führen kann.

Um die Betroffenen aus dieser Wut und Frustration in ein konstruktives Miteinander zurückzuführen ist ein Kulturwandel nötig, der in diesem Modell durch eine Widerlegung der besagten Annahmen herbeigeführt werden kann. Den Menschen muss klar werden, dass sie Gestaltungsspielraum haben, dass ihre Ideen gehört werden und dass das Gesamtsystem auf diesen Input angewiesen ist um funktionieren zu können. Das sagt sich leicht, umzusetzen ist es schwer. Aber es lohnt sich.

Wenn dieser Wandel stattfindet kann aus der Untertanenkultur (und der Erwartung "irgendjemand anders" müsste "irgendwie" alle Probleme beseitigen) eine partizipierende Kultur werden, in der jeder von sich aus dazu beiträgt, dass permanent an Verbesserungen gearbeitet wird. Dadurch wird nicht nur das Gesamtsystem leistungsfähiger, es werden auch die ihm angehörenden Menschen zufriedener. Und "besorgte Bürger" spielen dann keine Rolle mehr.
Powered by Blogger.