Donnerstag, 22. September 2022

Organisatorische Kontaktinfektion

Bild: Unsplash / Rishabh Dharmani - Lizenz

Zu den interessanteren Artikeln der letzten Zeit gehört Kontaktinfektionen - Wie sich Organisationen einst über die Welt verbreiteten des Soziologie-Professors Stefan Kühl. Seine Kernaussage ist, dass sich Organisationen (Religionen, Wirtschaftsunternehmen, NGOs etc.) an den Orten in die sie neu expandieren Strukturen suchen, schaffen oder unterstützen, die den eigenen entsprechen. Auf diese Weise kommt es mit der Zeit zur Verbreitung ähnlicher Organisationstypen auf der ganzen Welt.


Diese "Infektion" der neu erschlossenen Orte mit Organisationsstrukuren die der eigenen ähnlich sind ist dabei von einer rationalen Überlegung angetrieben: die expandierende Organisation (bzw. deren neu gegründeter lokaler Ableger) möchte mit der neuen Umgebung kommunizieren. Da das aber am einfachsten mit gleich aufgebauten Organisationen möglich ist, werden diese gegenüber den anderen, inkompatiblen, bevorzugt und gefördert


Wenn man davon ausgeht, dass es sich dabei um ein verbreitetes Muster handelt, ist es möglich die Einführung agiler Arbeitsweisen unter einem neuen Blickwinkel zu betrachten. Sowohl die klassische als auch die neue (agile) Organisationsweise unterliegen den selben Mechanismen wie alle anderen auch. Das heisst, dass sie im Fall eines Kontakts versuchen die jeweils andere Seite mit den eigenen Strukturen zu infizieren, um danach besser mit ihr kommunizieren zu können.


Die Kontaktinfektion der agilen durch die klassische Organisation findet vor allem durch den Versuch statt, dort hierarchisch höherstehende Funktions- oder Entscheidungsträger zu identifizieren oder zu etablieren, die dann zu präferierten Ansprechpartnern werden. Die Herausbildung der in den ursprünglichen agilen Frameworks nicht vorgesehenen Chief Product Owner, Release Train Engineers, Tribe Leads und ähnlichen Rollen ist eine Folge davon.


Auf der anderen Seite besteht die Kontaktinfektion der klassischen durch die agile Organisation darin, möglichst dezentrale und umsetzungsnahe Kommunikationsschnittstellen zu finden oder zu einzurichten. Der klassische Fall ist die Etablierung eines (in einem Umsetzungsteam verankerten) Product Owners, aber auch andere sind möglich, z.B. der Onsite Customer, der einen direkten Austausch zwischen Anwendern und Anwendungsentwicklern möglich macht.


Wenn aber beide Seiten bei Kontakt versuchen sich mit den jeweils eigenen Organisationsmustern zu infizieren ist ein Konflikt hochwahrscheinlich. Sowohl ein bisher selbstorganisiertes Team, das sich durch eine neue Koordinations-Rolle bevormundet fühlt, als auch ein bisher wichtiger Manager, der sich durch Absprachen auf der Umsetzungsebene übergangen fühlt, können durch die Verteidigung ihrer bisherigen Positionen aus die Kontaktinfektion zu einer Konflikteskalation machen.


Um bei der Analogie zu bleiben - wenn eine Organisationseinheit das Gefühl hat, durch die Infektion in ihrer Funktionsfähigkeit eingeschränkt zu werden, wird sie ihr "Immunsystem" aktivieren. In der Realität sieht das so aus, dass alles was mit dieser Art von Veränderungen in Verbindung gebracht wird isoliert und abgestossen wird - sowohl bei der Durchführung als auch beim Zurücknehmen von agilen Transformationen ein häufig zu beobachtendes Muster.


Will man das vermeiden hilft es sich noch einmal vor Augen zu führen, dass die organisatorische Kontaktinfektion einen zutiefst rationalen Ursprung hat - den Wunsch möglichst reibungslos kommunizieren zu können. Hier kann eine Lösungsfindung einsetzen: wenn es gelingt die Kommunikation zu ermöglichen ohne auf der jeweils anderen Seite Strukturen verändern zu müssen ist eine Infektion der Gegenseite nicht mehr nötig.


Natürlich wird auch das immer wieder Kompromisse und Verhandlungen erfordern, ein einfacher Weg ist es also nicht. Anders als im Fall einer Kontaktinfektion kann der Austausch hier aber auf Augenhöhe stattfinden, wodurch ein Grossteil des Konfliktpotentials entschärft wird.

Montag, 19. September 2022

Formale und informelle Organisation

Bild: Flickr / Justin Lynham - CC BY-NC 2.0

Wenn wir über die Ablauf-Organisation einer Firma oder Behörde reden, also über die Zuordnung, die Reihenfolge und die Regeln von Arbeitsvorgängen, dann ist es fast in jedem Fall so, dass es gleich zwei davon gibt. Zum einen die formale Organisation, die irgendwann mal offiziell beschlossen und in der offiziellen Dokumentation festgehalten wurde, zum anderen die informelle Organisation, die selbstorganisiert entstanden ist, nur inoffiziell besteht und die formale ergänzt und überlagert.


Dass diese informelle Organisation praktisch überall besteht ist durch die Unzulänglichkeiten oder Akzeptanzprobleme der jeweiligen formalen Organisation begründet. Manche Vorgaben sind nur schwer oder gar nicht umsetzbar, andere sind unnötig aufwändig, bei wieder anderen wurde nie kommuniziert welchem Zweck sie überhaupt dienen, nochmal andere dienen Zielen der oberen Hierarchie-Ebenen, die von den unteren nicht geteilt werden (z.B. einer Detail-Kontrolle oder einem Spar-Zwang).


Informelle Organisationen gleichen das aus indem sie durch inoffizielle Absprachen dafür sorgen, dass offizielle Prozess-Schritte (oder sogar ganze Prozesse) umgangen, übersprungen oder nur scheinbar erledigt werden, wodurch die Ergebnisse in der Regel schneller und einfacher zu Stande kommen. Das kann dort stattfinden wo die offiziellen Regelungen Lücken haben (was meistens zulässig ist), es kann aber auch offizielle Regeln verletzen, was hochproblematisch sein kann.


Um ein Beispiel zu nennen: bei einem Kunden war der formale Prozess zur Erteilung eines Systemzugriffs der, dass eine Aufnahme in eine Benutzergruppe beantragt werden musste, was dann von schlecht geschulten Angestellten eines externen Dienstleisters spät (und oft falsch) umgesetzt wurde. Der informelle Prozess war der, dass Kollegen mit Admin-Berechtigungen den individuellen Zugriff direkt im System ermöglichten, wobei die Benutzergruppen ignoriert wurden.


Ein anderes ist die "kreative Budgetierung" eines anderen Kunden. Am Ende jedes Quartals waren noch Restposten der genehmigten Budgets übrig, gleichzeitig gab es immer irgendwo anders eine Finanz-Lücke. Eine Umwidmung hätte einen bürokratischen Prozess mit ungewissem Ausgang erfordert. Um dieses Geld nicht zu verlieren (und um es zeitnah ausgeben zu können) wurde es offiziell wie geplant verwendet, inoffiziell aber von den Bereichsleitern zusammengeworfen und für andere Zwecke genutzt.


Sowohl die Vorteile als auch die Nachteile der informellen Organisation werden an diesen Beispielen deutlich: die inoffiziellen Prozesse sind deutlich schneller und flexibler als die offiziellen, ohne sie würde es immer wieder Phasen des Stillstandes geben. Gleichzeitig führen die Informalität und die mit ihr verbundene Intransparenz aber dazu, dass Berechtigungs-Vergabe, bzw. Budget-Verwendung nicht mehr ganzheitlich überblickt werden können.


Um die Vorteile sowohl der forlamen als auch der informellen Organisation zu behalten und gleichzeitig die Nachteile zu vermeiden kann es Sinn machen beide in Grenzen zu halten oder zurückzuschneiden. Dort wo es um Gesetze, Sicherheit oder globale Handlungsfähigkeit geht sollte auf den formalen Regeln bestanden werden, an allen anderen Stellen kann es dagegen Sinn machen der informellen Selbstregulierung zu vertrauen und auf offizielle (Detail-)Vorgaben zu verzichten.


Sowohl um sicherzustellen, dass gegen die verbleibenden Teile der formalen Organisation nicht verstossen wird, als auch um zu verhindern, dass ihre Ziele an anderer Stelle von der informellen Organisation nicht unterlaufen werden, ist eines wichtig: allen sollte klar sein warum es richtig und wichtig ist sich an die offiziellen Vorgaben zu halten. Das erfordert, dass sie gut (und im Zweifel mehrfach) erklärt werden. Passiert das kann es zu einer guten Balance von formaler und informeller Organisation kommen.


Ach ja, eines noch zum Schluss - ab und zu kommt jemand auf die Idee, dass man doch die informelle Organisation komplett abschaffen könnte und alle sich von jetzt an nur noch an die formale Organisation halten. Viel Spass beim Versuch das umzusetzen. Klappen wird es zwar nicht, aufregend und lehrreich wird es aber auf jeden Fall.

Donnerstag, 15. September 2022

Wie man die Sabotage agiler Transformationen verhindert

Ich gestehe, ich habe den Titel dieses Vortrages umgedreht. Fred George hat ihm eigentlich den Titel Sabotaging an Agile Transformation gegeben, da er aber auch beschreibt warum es dazu kommt und wie man dem Ganzen begegnen kann ist der positive Titel passender (wenn auch weniger Klickbait-geeignet).



Trotz vieler interessanter Impulse ist dieser Vortrag aber auch einer, den man ganz bewusst als individuelle Meinungsäusserung sehen sollte. Beispielsweise ist die Sicht auf die Rollen des Change Agent oder des Scrum Master erkennbar von individuellen negativen Erfahrungen geprägt. Sehenswert ist er trotzdem, man sollte sich nur vor einer Eins-zu-Eins-Übertragung auf die eigene Situation hüten.

Montag, 12. September 2022

Der Voldemort-Prozess

Bild: Wikimedia Commons / Kevin Dooley - CC BY 2.0

Zu den verschiedenen Spleens die sich in den letzten Jahrzehnten rund um die agile Produktentwicklung gebildet haben gehört auch die Überzeugung keine Prozesse zu brauchen. Vom agile Meetup um die Ecke bis zum Thought Leader aus Kalifornien (hier ein aktuelles Beispiel für letzteres) wird man immer wieder mit der Aussage konfrontiert, dass Prozesse etwas Schlechtes wären und so weit wie möglich zurückgedrängt werden müssten um produktiv arbeiten zu können.


Erklärbar ist das durch die Ursprungsgeschichte der agilen Bewegung. Nach einer ersten Phase, in der sie ein weitgehend unbemerktes Nischendasein führte, wurde sie lange Zeit von Managern als ein dysfunktionales oder wunderliches Konzept gesehen, das durch Regulierung "repariert" werden müsste (siehe auch hier). Die Abneigung gehen Standardisierungen oder Strukturierungen jeglicher Art kann als Gegenreaktion darauf verstanden werden.


Das Problem: ganz ohne Prozesse zu arbeiten ist schwierig bis unmöglich. Irgendwie muss man sich darauf einigen wann und wie Interaktionen stattfinden, wo Informationen abgelegt werden, auf welchen Kanälen man erreichbar ist, etc. Das muss nicht zwingend in einem telefonbuchdicken Prozess-Handbuch enden, es gibt auch schlanke, flexible und einfach anpassbare Formate, Prozesse bleiben es aber trotzdem (siehe auch hier).


Wenn jetzt aber aus der erwähnten grundsätzlichen Ablehnungshaltung heraus ein schriftliches Festhalten von Prozessen durchgehend nicht stattfindet führt das eben nicht dazu, dass sie verschwinden - stattdessen werden sie ins Inoffizielle und Implizite verschoben. Es ist zwar weiter so, dass vor dem Produktions-Realease ein Vier-Augen-Prinzip gilt, oder dass nicht alle zur selben Zeit Urlaub nehmen können, nur nachlesen kann man das nirgendwo.


Da das aber dem Anspruch widerspricht auf Prozesse zu verzichten wird manchmal sogar kategorisch abgestritten, dass sie überhaupt existieren und befolgt werden. Selbst bei wiederkehrenden Mustern wird unterstellt, dass es sich lediglich um situative Entscheidungen handelt ("Wir überlegen jedesmal was gerade Sinn machen könnte"). Angelehnt an die literarische Figur des Voldemort (He-Who-Must-Not-Be-Named) werden sie zu Voldemort-Prozessen,  die da sind aber einfach nicht thematisiert werden.


Dort wo es so weit gekommen ist werden fast zwangsläufig Probleme entstehen. Zunächst dadurch, dass die zwar existierenden aber nicht festgehaltenen und angesprochenen Prozesse nicht kommuniziert werden können. Sei es im Fall neuer Teammitglieder, die ein berechtigten Interesse am Arbeitsmodus haben, oder im Fall von Stakeholdern, die wissen wollen wen sie wie ansprechen können ohne Störungen zu verursachen - sie werden den "Process-That-Must-Not-Be-Named" nicht erfahren.


Mindestens genauso weitreichend ist aber auch die Wirkung nach Innen. Wenn bestehende Prozesse nicht mehr angesprochen werden können, dann ist es kaum noch möglich sie zu begutachten und bei Bedarf zu optimieren. Beziehungsweise: um das wieder zu können ist zuerst das schmerzhafte Zugeständnis erforderlich, sich aus Dogmatismus in eine kontraproduktive Tabuisierung verrannt zu haben (siehe auch hier). Das ist zwar unangenehm, oft aber auch dringend nötig.


Zuletzt eine Einordnung: sind die Voldemort-Prozesse in agilen Teams wirklich ein verbreitetes Phänomen, oder sind das eher Extremfälle? Wie so häufig - es kommt darauf an. Eine komplette Verleugnung aller Prozesse ist sehr selten, alleine schon weil sie z.T. von aussen vorgegeben werden. Bei teaminternen Prozessen ist die Verbreitung dagegen deutlich grösser, wer bewusst darauf achtet wird vermutlich mehr davon vorfinden als er zunächst denkt.

Donnerstag, 8. September 2022

Der häufigste Fehler bei einer Kanban-Einführung

Bild: Unsplash / Eden Constantino - Lizenz

Bei der Einführung von Kanban gibt es so einiges auf das man achten sollte. Zum einen Dinge die man tun sollte (einige davon finden sich hier) aber solche bei denen es besser wäre wenn man sie lässt. Nach über einem Jahrzehnt Erfahrung glaube ich, dass ich mittlerweile genug anekdotische Evidenz für eine starke Aussage gesammelt habe: unter allen möglichen Fehlern gibt es einen der mit weitem Abstand am häufigsten auftritt (und auf dem Foto in diesem Beitrag ist er zu sehen).


Die Rede ist davon, dass in einem ersten Schritt alle Mitglieder der sich umstellenden Einheit alles was sie machen auf physische Post-Its oder in digitale Kacheln schreiben und die dann auf ein Board mit den Spalten To Do, in Progress und Done platzieren.1 Die Absicht dahinter ist auch gut, es soll visualisiert werden woran gearbeitet wird und wie hier der Fortschritt ist. In den meisten Fällen ist das Ergebnis aber das genaue Gegenteil.


Warum das so ist: fast alle Tätigkeiten in klassisch arbeitenden Organisationen beziehen sich nur auf einen kleinen Teil einer langen Be- oder Verarbeitungskette. Vorne wird geplant und konzipiert, in der Mitte gebaut, entwickelt oder getestet, am Ende finden Betrieb, Verkauf oder Kundenbetreuung statt. Nur in Summe ergeben alle der aufeinanderfolgenden Schritte Sinn, für sich genommen wirkt jeder einzelne von ihnen generisch und hat wenig Aussagekraft (und viel zu viele sind es auch).


Beispiele gefällig? Vorne könnte "Marktanalyse" stehen oder "Konzept schreiben". In der Mitte könnte es "Eingabemaske im Frontend erweitern" sein oder "Software auf die Hardware aufspielen". Am Ende finden sich schliesslich "Auslieferung" oder "Übergabe an den Kundenservice". Oft sind sie noch generischer, z.B. "Test" oder "Entwicklung", jeweils mit Ticket-Nummer. Genau so sind übliche Arbeitspakete eben geschnitten, damit sie von einzelnen Fachkräften schnell erledigt werden können.



Wenn wir uns jetzt ein mit solchen Aufgaben gefülltes Board vorstellen wird das Problem offensichtlich: Tätigkeiten die eigentlich sequentiell stattfinden hängen ohne die richtige Reihenfolge über- oder nebeneinander in einer der drei Spalten To Do, in Progress und Done. Es wird nur noch klar mit welchen Riesenmengen an Detailschritten die Kollegen gerade beschäftigt sind, wie diese zusammenhängen und aufeinander aufbauen ist völlig intransparent. Das ist nicht im Sinn der Kanban-Idee.


Alleine das wäre bereits ausreichend problematisch, in der Regel geht es aber sogar noch darüber hinaus. Häufig arbeiten Teams an mehr als einem Feature-Set, Produkt oder Service parallel, die Folge davon ist, dass die dazugehörigen Einzelaufgaben auf dem gemeinsamen Board nicht klar voneinander abgrenzbar nebeneinanderhängen. Zu welchem dieser Aufgaben-Pakete eine Aufgabe wie "Integrationstest" dann gehört ist fast nur noch für den Bearbeiter nachvollziehbar.


Wie es besser geht: bevor damit begonnen wird Post-Its oder Tickets zu erstellen sollte zuerst die Abfolge der jeweiligen Arbeitsschritte explizit gemacht und visuell festgehalten werden. In einem Fall den ich in einer Einheit miterlebt habe, die kleinteilige Erweiterungen einer Altanwendung machte, hatten wir z.B. nach einem ersten Workshop die folgenden Schritte identifiziert (vereinfachte Darstellung, in Wirklichkeit war es ein kleines bisschen komplizierter):



Auf Basis einer solchen Darstellung kann dann das Board erstellt werden, mit einer Entsprechung von jeweils einem Arbeitsschritt zu einer Spalte. Und ja, in diesem Fall würde das bedeuten, dass das Board acht Spalten hat, wenn die jeweils in die jeweiligen Unterspalten Doing und Done unterteilt werden sogar sechzehn. Das kann sich zuerst nach (zu) viel anfühlen, es ist aber nichts anderes als die Realität, die nun mal irgendwie so entstanden ist.


Selbst wenn man Kanban-Systeme (meiner Meinung nach) nicht zu früh komplizieren sollte ist in den meisten Fällen noch eine weitere Ergänzung sinnvoll: die Regel, dass Arbeitspakete die zu einem gemeinsamen Feature-Set, Produkt oder Service gehören kenntlich gemacht werden sollten, etwa durch eine gemeinsame Farbe oder eine gemeinsame Zeile. Dann (aber auch wirklich erst dann) sollte mit dem Schreiben der Post-Its oder Tickets begonnen werden.



Wie an diesem Beispiel zu sehen ist,2 kann die ganze Art wie Aufgaben geschnitten werden jetzt eine andere sein. Statt Detailaufgaben werden ganze Features beschrieben, deren genauer Arbeitsfortschritt sich aus der Spalte ergibt in der sie hängen. Das ist deutliche informativer. Und auch weitere Informationen fallen sofort ins Auge, die sonst schwerer erkennbar sein würden: in Feature-Set A gibt es einen Nachzügler, Feature-Set B hängt anscheinend in der Genehmigung fest.


Natürlich ist der Weg zu einem solchen Kanban-System deutlich anspruchsvoller als das einfache Aufhängen eines To Do, in Progress, Done-Boards voller Detailaufgaben. Daher scheuen viele Teams diesen Weg (oder kennen ihn gar nicht). Es sollte aber klar sein - wer sich auf die (scheinbar) einfache Lösung beschränkt wird bestenfalls die einfachste der möglichen Kanban-Varianten haben: irgendetwas Sichtbares. Wirklich besser wird dadurch kaum etwas werden.



1Diesem ersten Schritt müssen natürlich weitere folgen, die aber auf diesem ersten aufsetzen.
2Es sind natürlich auch viele andere möglich, die besser als To Do - in Progress - Done sind.

Montag, 5. September 2022

Innere Kündigung und Quiet Quitting

Bild: Unsplash / Bram Naus - Lizenz

Dass es Konzepte aus der deutschen Management- und Organisationswissenschaft in andere Sprachen schaffen ist mittlerweile selten geworden, es kommt aber noch immer vor. Das jüngste Beispiel dafür ist sogar aus den Filterblasen der Akademiker und Berater ausgebrochen und wird in den sozialen Medien intensiv diskutiert. Die Rede ist von der Inneren Kündigung, bzw. ihrer englischen Übersetzung, dem Quiet Quitting. Aber was verbirgt sich hinter diesem Begriff und wo kommt er her?


Namensgeber der Inneren Kündigung ist Reinhard Höhn, der Begründer des Harzburger Modells. Er definierte sie (u. a. in seinem Buch Die innere Kündigung im Unternehmen - Ursache, Folgen, Gegenmaßnahmen) als eine Arbeitseinstellung, bei der Eigeninitiative und Leistungsbereitschaft auf ein absolutes Minimum reduziert werden, da der Mitarbeiter aufgehört hat in seiner Tätigkeit Freude oder Erfüllung zu finden.


Die entscheidende Ursache ist für Höhn das Verhältnis zu den Kollegen in der Firma. Sobald dieses von fehlender Anerkennung, schlechter Zusammenarbeit, fehlender Kommunikation und ähnlichen Faktoren geprägt ist steigt das Risiko, dass es zu einem Rückzug in die Passivität kommt. Derartige Beziehungsprobleme können überall auftreten - sowohl gleichrangige Mitglieder der eigenen Abteilung als auch Vorgesetzte oder Untergebene können in die Innere Kündigung treiben.


Während das noch sofort eingängig ist sind andere Zusammenhänge erst bei genauerer Betrachtung zu erkennen. Für Höhn gehörte dazu vor allem ein im Unternehmen verbreiteter Pessimismus. Sobald (berechtigt oder unberechtigt) die Meinung vorherrscht, dass alle Anstrengungen wirkungslos und alle Verbesserungsversuche zum Scheitern verurteilt sind kommt es auch hier zu Inneren Kündigung (da kollektiver Pessimismus durch soziale Interaktion entsteht ist auch das ein Beziehungsproblem).


Die offensichtliche Folge ist, dass der Firma die Arbeitskraft und Kreativität des innerlich Kündigenden entzogen werden. So lange es sich um Einzelfälle handelt hat das "nur" sozialen Unfrieden zur Folge, da es zu einer ungleichen Arbeitsverteilung kommt. Wenn grosse Teile der Belegschaft in die Passivität abrutschen können die Auswirkungen schwerer sein, bis zu dem was Höhn "Kreativitätskonkurs" nennt - die Organisation kann dann nicht mehr mit neuen oder schwierigen Herausforderungen umgehen.


In das Englische wurde der Begriff ursprünglich als Employee Disengagement übernommen, war in dieser Form aber weitgehend auf die Betriebs- und Personalwirtschaft beschränkt. Das wesentlich griffigere Quiet Quitting entstand dagegen erst 2022 als Reaktion auf die "Hustle Culture" vieler amerikanischer Unternehmen, d.h. die Anforderung zu ständiger Erreichbarkeit und zu Überstunden bereit zu sein. In vielen Berichten wird Quiet Quitting als Abwehrmassnahme gegen diese Kultur beschrieben.


Sowohl daraus als auch aus den Untersuchungen von Reinhard Höhn lässt sich das Selbe mitnehmen: Unternehmen die ihre Angestellten gut behandeln und darauf achten, dass diese auch untereinander eine gute Arbeitskultur entwickeln müssen sich wegen Innerer Kündigung / Quiet Quitting keine Sorgen machen. Die anderen schon - aber die sind daran selber schuld.

Mittwoch, 31. August 2022

Kommentierte Links (XCI)

Bild: Pixabay / Buffik - Lizenz
Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Ebenezer Ikonne: In Praise of Mandates

"Ein Lob der Vorschriften", in etwa so könnte man den Titel dieses Artikels von Ebenezer Ikonne übersetzen. Angesichts der Neigung vieler Agilisten, alle von aussen kommenden Vorgaben kategorisch abzulehnen, eine hochgradig kontroverse Aussage - aber auch eine die hier nachvollziehbar begründet wird. Vorschriften können dabei helfen Unklarheiten und Mehrdeutigkeiten zu vermeiden, sie können Handlungsspielräume definieren und Qualitätssicherungsmassnahmen verpflichtend machen. Auch die Eigenschaften guter Vorschriften arbeitet Ikonne heraus: sie müssen einfach verständlich und umsetzbar sein, für den der sich an sie halten muss müssen sie Sinn ergeben, sie dürfen nicht in Widerspruch zu anderen Vorschriften stehen und ein Nichtbefolgen muss mit (wie auch immer gearteten) Folgen verbunden sein. Derartige Vorschriften sollten dann auch wieder mit agilem Arbeiten kompatibel sein.
[Btw: eine kritischere Sicht gibt es bei Jason Yip: Cross-pollination over imposed standards]

Kent Beck: Better/Sooner/Cheaper/More

Im (IT-)Projektmanagement gibt es das alte Sprichwort, dass es die drei Ziel-Dimensionen Gut, Schnell und Billig gibt, von denen man aber maximal zwei gleichzeitig erreichen kann. Kent Beck, der Erfinder der Extreme Programming-Frameworks (XP), fügt noch eine vierte hinzu, die Menge des gelieferten Mehrwerts. In seinen Worten ergeben sich so die Dimensionen Better, Sooner, Cheaper und More. Seine Überzeugung: wenn Extreme Programming richtig umgesetzt wird ist es sogar möglich, immer drei dieser vier zu erreichen, wobei die erste, Better, in jedem Fall dabei ist (über sie hat er noch einen zweiten, weiterführenden Artikel geschrieben). Das klingt zwar gewagt, kommt aber eben auch von jemandem der in grossen Firmen wie Chrysler und Facebook bewiesen hat, dass er weiss wie man agile Produktentwicklung erfolgreich umsetzt.

Itamar Gilad: How To Learn From FAANG

Apropos grosse Firmen. Eigentlich sollte man immer sehr vorsichtig sein wenn versucht wird aus den Arbeitsweisen bekannter Unternehmen Handlungsempfehlungen abzuleiten, an die man sich halten muss um auch erfolgreich zu sein. Das was Itamar Gilad hier aus den FAANG-Konzernen (Facebook, Apple, Amazon, Netflix, Google) zusammengetragen hat geht aber über das blosse Kopieren von Praktiken wie Tribes oder OKRs hinaus. Er konzentriert sich eher auf grundlegende Prinzipien, wie z.B. die, dass technikferne Personen keine Entscheidungen zu technischen Produkten treffen sollten, oder dass Produkte immer von (teil-)autonomen, crossfunktionalen Teams entwickelt werden sollten (und nicht von auslastungs-optimierten Komponententeams). Das ist tatsächlich zur Nachahmung empfohlen.

Tobias Haar: Selbstständige Scrum-Entwickler wohl ohne Sozialversicherungspflicht

Dieses Urteil hat das Potential die deutsche Software-Industrie deutlich in Richtung Agilität zu verschieben. Zum Hintergrund: um mögliche Fälle von Scheinselbstständigkeit von vornherein auszuschliessen werden in vielen Unternehmen externe Entwickler von einem Grossteil der Meetings, Informationen und Tools ausgeschlossen. Gemischte interne/externe Scrum Teams sind dadurch dort de facto unmöglich, was sowohl für Firmen als auch für Freelancer ein echtes Problem ist. Das Landessozialgericht Baden-Württemberg hat nun geurteilt, dass externe Entwickler in Scrum Teams aufgrund der dort gegebenen Selbstorganisation nicht weisungsgebunden und damit nicht scheinselbstständig sein können. Sollten weitere Gerichte dem folgen wären gemischte Teams wieder in allen Unternehmen möglich. Und für alle Fans der Juristerei: hier ist der Originaltext des Urteils.

John Coleman: Talking about Sizing and Forecasting in Scrum

Auch diesesmal führt der letzte kommentierte Link zu einem Longread. Mit dem Themenkomplex des Schätzens, Kleinschneidens und Prognostizierens hat sich John Coleman ein Thema ausgesucht zu dem es viele verschiedene Meinungen, Werkzeuge und Erfahrungswerte gibt, die er zusammenfasst und einordnet. Den Königsweg kann natürlich auch er nicht aufzeigen, nach dem Lesen seines Artikels ist man aber sehr gut über den aktuellen Stand informiert und wird vieles gelernt oder aufgefrischt haben was auch im eigenen Team nützlich sein kann.

Montag, 29. August 2022

Agile Demenz

Bild: Pixabay / Saiyed Hirfan - Lizenz

Es gibt eine Erfahrung, die so ziemlich jeder Scrum Master oder Agile Coach schon einmal gemacht haben dürfte: Die initialen Schulungen sind schon lange vorbei, im Arbeitsrhythmus des Teams oder Projekts ist eine gewisse Routine eingekehrt, es gibt auch keine grundlegenden Akzeptanzprobleme des methodischen Vorgehens - aber plötzlich hat ein Grossteil der Kollegen in den Entwicklungsteams das agile Methodenwissen weitgend vergessen und fährt deswegen wichtige Prozesse vor die Wand.


Dieses Phänomen, in Fachdiskussionen oft flapsig als "agile Demenz" bezeichnet, wirkt zwar nach aussen wie ein wiedererkennbares und sich wiederholendes Muster, tatsächlich können dahinter aber sehr unterschiedliche Ursachen stehen (von denen ggf. auch mehrere gleichzeitig vorhanden sein können). Je nachdem welche das sind können dementsprechend unterschiedliche Gegenmassnahmen die jeweils vielversprechendsten sein.


Ein häufiger Grund dafür, dass methodische Aspekte in Vergessenheit geraten ist eine zu hohe Kompliziertheit. Das kann man immer wieder bei SAFe mit seinen zahlreichen Rollen und Prozessen beobachten, aber auch Kanban-Systeme mit zu vielen Policies und Scrum-Umsetzungen mit einer zu kleinteiligen Definition of Done gehören z.B. dazu. In solchen Fällen kann eine Verschlankung des Regelwerks ein guter Weg sein, um eine bessere Erinnerbarkeit herbeizuführen.


Eine verwandte Ursache ist gegeben wenn die Methodik zwar für sich genommen einen überschaubaren Umfang hat, in Relation zur zu lösenden Herausforderung aber unproportional aufwändig ist. Das kommt z.B. dann immer wieder vor, wenn in stabilen, nicht-komplexen Umgebungen nach Scrum (o.Ä.) gearbeitet wird. Für die Beteiligten fühlt sich das schnell wie Bürokratie an, mit der man sich lieber nicht gedanklich befassen will. Auch hier ist Reduktion ratsam.


Ein anderer Grund kann der hohe Anteil an Fach-Vokabular sein, das vor allem für Menschen mit geringen Englischkenntnissen verwirrend sein kann. Die naheliegende Gegenmassnahme wäre die Verwendung von deutschen Worten und einfacher Sprache, die allerdings mit Vorsicht eingesetzt werden sollte. Zwar mag sie intern einiges verständlicher machen, die Kommunikation mit Geschäftspartnern oder das Verständnis von Fachliteratur können aber darunter leiden.


Immer wieder anzutreffen ist die Situation, in der das Methodenverständnis durch eine dauerhaft zu hohe kognitive Belastung verschwindet. Dort wo herausfordernde Fachlichkeit, hochvernetzte Technik und Zeitdruck zusammenkommen ist es nur menschlich, dass (ggf. unbewusst) versucht wird durch das Ausblenden von Themengebieten diese Überlastung zurückzufahren. Die Lösung kann hier nur sein, die Belastung der Menschen zurückzufahren, sonst kann mehr verlorengehen als nur Methodenwissen.


Abgeleitet davon kann schliesslich noch eine weitere Konstellation vorkommen: wenn versucht wird die kognitive Gesamt-Belastung dadurch gering zu halten, dass die Beschäftigung mit Prozess- und Methodenthemen komplett zum Scrum Master oder Agile Coach geschoben wird, dann können diese dadurch im Arbeitsalltag der anderen so wenig präsent sein, dass es hochwahrscheinlich ist, dass sie in Vergessenheit geraten. Dieses "Wegschieben" ist daher eine eher schlechte Idee.


Alleine das Nebeneinanderhalten der letzten beiden Fälle zeigt, dass die Identifizierung von Gründen für die "agile Demenz" zwar möglich ist, einfache Gegenmassnahmen aber der Vielschichtigkeit der Situation aber kaum gerecht werden. Wie so oft im Umfeld des agilen Arbeitens wird daher auch hier kein Weg an ständigem Inspect & Adapt vorbeiführen, um durch ständige Optimierungen dafür zu sorgen, dass die Arbeitsmethodik von allen Beteiligten erinnert und verstanden wird.