Kommentierte Links (XCII)

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.

Stefan Kühl: Die paradoxe Tragik erfolgreicher Unternehmen

Auf den ersten Blick ist die Aussage dieses Artikels widersinnig: Unternehmen die in der Vergangenheit bereits erfolgreich Veränderungen hinter sich gebracht haben sollen bei neuen Veränderungen eher unflexibel sein? Bei näherer Betrachtung ergibt diese These von Stefan Kühl aber Sinn. Eine Veränderung erfolgreich durchlaufen zu haben bedeutet fast immer, dass die mit dem Umbruch verbundene Phase der Unklarheit und Instabilität in eine neue Stabilität überführt werden konnte. Und wenn die sich gefestigt hat verschwindet damit auch die Flexibilität. Um diese zu erhalten müsste auch weiterhin eine ständige Anpassung und Veränderung stattfinden - auch eine Veränderung von Teilen dessen was gerade erst eingeführt wurde. Das aber würde dazu führen, dass dieser schon wieder anzupassende Wandel nicht mehr als gelungen gilt. So kommt es zur scheinbaren Widersinnigkeit: wer ständige Veränderung nicht hinter sich lässt gilt als nicht erfolgreich, wodurch Unternehmen die sich erfolgreich verändert haben sich mit der nächsten Veränderung schwertun werden.

Jurgen Appelo: Consider your options for reteaming

Mit seinem Unfix-Model hat Jurgen Appelo dem Thema des (Dynamic) Reteaming einen neuen Anstoss gegeben, der er hier nochmal verstärkt. Sein Ratschlag ist, sich vor einem grösseren Reteaming zu überlegen welche Ausgangs- und Zielstruktur die Teams haben, bzw. haben sollen. Anhand einer Anordnung auf den beiden Achsen Statisch/Dynamisch und Generalistisch/Spezialisiert kommt er zu vier Typen: All-round (Statisch+Generalistisch), Focused (Statisch+Spezialisiert), Ad-hoc (Dynamisch+Generalistisch) und Flexibel (Dynamisch+Spezialisiert). Was über diese Einteilung hinaus interessant ist sind seine Beispiele aus Unternehmen in denen es verschiedene dieser Team-Typen gibt, die dort verschiedene, dem jeweiligen Typ entsprechende Aufgaben wahrnehmen.

Dina Smith: Stop Feeling Guilty About Delegating

Dieser Text von Dina Smith richtet sich eigentlich an Manager, kann aber auch für Mitglieder selbstorganisierter Teams wertvoll sein. In ihm wird das Thema der Delegation, also des Abgebens von Tätigkeiten oder Verantwortung an andere, aus einer ungewöhnlichen Perspektive betrachtet: der eines Menschen der sich unwohl fühlt wenn er Aufgaben an andere abgibt die er (vermeintlich) auch selbst erledigen könnte. Das ist nicht nur für derartige Personen hilfreich (denen vermittelt wird, dass das Delegieren häufig die bessere Option ist als das selber machen), es hilft auch den anderen dabei einen nicht-delegierenden Kollegen mit anderen Augen zu sehen. Der Grund dafür ist nämlich nicht immer der Wunsch Kontrolle, Herrschaftswissen oder Ähnliches anzuhäufen, häufig ist es auch die Sorge andere zu überlasten oder zu verstimmen. Mit dieser Sicht im Hinterkopf in Gespräche über Delegation zu gehen kann zu anderen und besseren Ergebnissen führen als sonst.

Dmytro Yarmak: From agile coach to the military officer - breaking stereotypes about leadership in the army

Da ich versuche auf Feedback einzugehen ist der erste hier stehende Link nachträglich durch einen anderen ersetzt worden. Ursprünglich hatte ich hier einen interaktiven, lehrreichen Twitter-Thread verlinkt, da er aber ohne Twitter-Account nicht gelesen werden kann verlinke ich stattdessen einen besser zugänglichen, bemerkenswerten Artikel von Dmytro Yarmak. In ihm bringt er zwei Welten zusammen die auf den ersten Blick so gar nicht zusammenzupassen scheinen - die eines Agile Coach und die eines Offiziers der ukrainischen Armee im Abwehrkapf gegen den russischen Angriffskrieg. Wenn das was er dort beschreibt auch nur in Ansätzen repräsentativ ist, ist diese Armee in bemerkenswertem Ausmass offen für moderne Führungstechniken.

David Brooks: The Immortal Awfulness of Open Plan Workplaces

Wer hier schon länger mitliest weiss, dass ich gegenüber Grossraumbüros eher kritisch bin. In meiner Erfahrung kommt es fast nie zu den Vorteilen die man sich von ihnen versprochen hat (einzige Ausnahme sind die Einsparungen von Mietkosten), dafür treten reihenweise Nachteile auf. Auch David Brooks ist dieser Überzeugung, die er allerdings mit zahlreichen Quellen untermauert. Wer auf der Suche nach Argumenten gegen diese Art der Bürogestaltung ist kann auf die Links in seinem Artikel klicken und wird dort fündig.

Beyond Budgeting

Bild: Pixabay / StevePB - Lizenz

Die agile Produktentwicklung hat Vieles nachhaltig verändert: den Umgang mit Abnehmern und Kunden, die Durchführung der Qualitätssicherung, die handwerklichen Praktiken der Softwareentwicklung und vieles mehr. Ein zentraler Bereich der Unternehmensführung ist allerdings eher unberührt geblieben - der Budgetierungsprozess. Glücklicherweise gibt es aber hier einen kompatiblen, zeitgleich entstandenen Ansatz, der diese Lücke füllen kann. Die Rede ist von Beyond Budgeting.

Ähnlich wieim Fall von #NoEstimates steht hinter Beyond Budgeting eine überzeugte (und in verschiedenen Firmen hoch erfolgreiche) Community, nach aussen sorgt die etwas unglückliche Namensgebung aber dafür, dass es oft gar nicht erst zu einer näheren Beschäftigung mit diesem Ansatz kommt. Dabei soll hier keineswegs der Budgetierungsprozess abgeschafft werden, er soll erhalten bleiben, nur eben deutlich verbessert.

Dieser Verbesserungsbedarf wird aus verschiedenen problematischen Aspekten der klassischen Budgetierung abgeleitet. Dazu gehört vor allem die Fixierung auf die Planung für jeweils das nächste Kalenderjahr, die am Anfang zu langfristig und am Ende zu kurzfristig ist, aber auch weitere übliche Praktiken, etwa die in dieser Jahresplanung oft enthaltene Vermischung von Prognosen und Zielen oder die Kopplung von Gehaltsbestandteilen an aus diesen Jahreszielen abgeleitete persönliche Ziele.

Über diese Budgetierungs-nahen Grundlagen hinaus sind nach und nach weitere Kritikpunkte an häufigen Elementen des traditionellen Budget-Managements in Beyond Budgeting aufgenommen worden, etwa an dem Nicht-Weitergeben von Informationen in die Belegschaft, an zu detaillierter Regulierung von Arbeitsprozessen, an zu bürokratischen Reporting-Strukturen und an der Optimierung auf interne Effizienz statt auf Nutzen für den Endkunden.

Bei der Antwort auf die Frage wie all das besser organisiert werden könnte bleibt Beyond Budgeting absichtlich unklar, da zu konkrete Empfehlungen in vielen Einzelfällen nicht passen würden, zumindest wurden als Richtlinie aber zwölf leitende Prinzipien verfasst:

1. Purpose
   Engage and inspire people around bold and noble causes; not around short-term financial targets
2. Values
   Govern through shared values and sound judgement; not through detailed rules and regulations
3. Transparency
   Make information open for self-regulation, innovation, learning and control; don’t restrict it
4. Organisation
   Cultivate a strong sense of belonging and organise around accountable teams; avoid hierarchical control and bureaucracy
5. Autonomy
   Trust people with freedom to act; don’t punish everyone if someone should abuse it
6. Customers
   Connect everyone’s work with customer needs; avoid conflicts of interest
7. Rhythm
   Organise management processes dynamically around business rhythms and events; not around the calendar year only
8. Targets
   Set directional, ambitious and relative goals; avoid fixed and cascaded targets
9. Plans and forecasts
   Make planning and forecasting lean and unbiased processes; not rigid and political exercises
10. Resource allocation
    Foster a cost conscious mind-set and make resources available as needed; not through detailed annual budget allocations
11. Performance evaluation
    Evaluate performance holistically and with peer feedback for learning and development; not based on measurement only and not for rewards only
12. Rewards
    Reward shared success against competition; not against fixed performance contracts

Um die Idee greifbarer zu machen gibt es mittlerweile neben diesen Leitlinien aber auch verschiedene Good Practices, die in verschiedenen Büchern zu diesem Thema nachzulesen sind.

Die naheliegende erste Praktik ist eine rollierende Planung anstelle einer Kalenderjahr-basierten. Das kann in der Realität so aussehen, dass zwar fünf Quartale im Voraus geplant wird, dass diese Planungen aber nach jedem Quartal überprüft und angepasst werden. Dadurch entfernt sich die Umsetzung nie länger als drei Monate von der Planung, gleichzeitig wird vermieden, dass der Planungsvorlauf zu Jahresende nur noch wenige Wochen beträgt.

Ebenfalls häufig ist die Entkoppelung von Prognose und Zielsetzung. In den Prognosen für den jeweiligen Planungszeitraum wird nur berücksichtigt was wahrscheinlich ist, das was wünschenswert ist (die Ziele) wird in einem zweiten, getrennten Dokument festgehalten. Das gilt auch dann (und sogar ganz besonders dann) wenn die wahrscheinlichen Zahlen unschön oder sogar bedrohlich sind. Sie zu verändern nur weil andere Zahlen schöner wären ändert schliesslich die Sachlage nicht.

Auch bei den Zielen (sowohl bei Geschäftszielen als auch bei Zielen von Personen oder Personen-Gruppen) ist eine kontinuierliche Setzung und Nachverfogung besser als eine Orientierung am Jahresrhythmus. Das bedeutet nicht zwingend, dass sie nur für kürzere Umsetzungszeiträume gesetzt werden, z.B. für Monate oder Quartale. Sie können auch für längere Zeiträume gesetzt werden, müssen dann aber in kurzen Zyklen immer wieder überprüft und an aktuelle Entwicklungen angepasst werden.

Auch bei der Art der Zielsetzung bevorzugt Beyond Budgeting eigene Wege. Statt zahlengebundener Ziele (z.B. Gewinn-Volumen oder Anzahl an Geschäftsabschlüssen) findet man eher relative Ziele, also solche, deren Zielsetzung es ist besser zu sein als eine Vergleichsgruppe. Das kann bedeuten, dass eine ganze Firma sich das Ziel setzt besser zu sein als der Marktdurchschnitt, es kann aber z.B. auch bedeuten, dass eines von 50 Vertriebsteams sich das Ziel setzt zu den besten 10 zu gehören.

Neben diesen sind zahllose weitere Praktiken möglich, die von Unternehmen zu Unternehmen unterschiedlich sein können. Auch die Entwicklung eigener Ideen ist möglich, solange sie den oben genannten Prinzipien nicht wiedersprechen. Und da sich die Communities von Beyond Budgeting und agiler Produktentwicklung in den letzten Jahren angenähert haben umfasst das auch mögliche Kombinationen von beidem (auch dazu gibt es in verschiedenen Büchern Beispiele).

Für jeden der in seiner Organisation die agile Transition ganzheitlich vorantreiben will ist Beyond Budgeting daher ein sehr zu empfehlender Ansatz. Und wenn die Namensgebung als zu kontrovers wahrgenommen werden sollte - man kann es auch agile Budgetierung nennen, wichtig ist, dass die dahinter stehenden Ideen umgesetzt werden, nicht der Name.

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.

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.

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.

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.

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.¹ 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,² 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.

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

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.