Montag, 19. Februar 2018

That's what they said

FS
Bild: Flickr / J. D. Falk - CC BY-SA 2.0
Von Zeit zu Zeit werde ich bei meinen Kunden nach inspirierenden Gedanken, Aussagen oder Dokumenten agiler Vordenker und Unternehmer gefragt, von denen man sich für die eigenen Zielbilder inspirieren lassen kann. Die gibt es tatsächlich, hier sind einige die ich immer wieder nenne:

Jeff Bezos - Amazon: Letter to Shareholders, 1997

Dieser Brief an die Anteilseigner von Amazon beinhaltet mehrere Gedankenstänge, von denen aber einer im Vordergrund steht: auch und gerade gegenüber den Shareholdern wird betont, dass nicht kurzfristige Gewinnausschüttungen das Ziel sind sondern langfristige Entwicklungen. Obwohl kurzfristige Flexibilität und Agilität gewünscht ist soll sie auf das langfristige Ziel einzahlen. Genau das also was agiles Produktmanagement ist - beweglich bleiben um trotz aller Hindernisse immer wieder das Fernziel ansteuern zu können. Gleichzeitig wird herausgestrichen, dass diese Reise gerade erst beginnt, dass erst "Tag eins" ist, weshalb noch keine Zeit zum Ausruhen und zum Routinen entwickeln sein kann. Auch zwei Jahrzehnte später ist das noch immer der Ansatz nachdem dieses Unternehmen geführt wird.

Larry Page, Sergey Brin - Google: Code of Conduct, 2000

Oft als esoterisch belächelt steht in diesem Dokument die vermutlich prägnanteste Beschreibung einer positiven Unternehmenskultur: "Don't be evil". Auch wenn der Text weiter unten formaler wird und an einigen Stellen sehr ins Detail geht (z.B. bei der Frage wann man seinen Hund mitbringen darf) steht doch dieser erstaunlich einfache Satz über allem, mit der Aufforderung sich nicht nur an den einzelnen Formulierungen sondern am Großen Ganzen zu orientieren. Und falls ein Mitarbeiter das Gefühl haben sollte, dass irgendwo das "Don't be evil" nicht befolgt wird, wird eine aktive Widerspruchs- und Feedbackkultur ermutigt und eingefordert.


Reed Hastings et al. - Netflix: Culture Presentation, 2009

Die Facebook-Geschäftsführerin Sheryl Sandberg hat diese schlichte Powerpoint-Präsentation einmal als das wichtigste im Silicon Valley entstandene Dokument bezeichnet. Den Inhalt ihrer 125 Seiten hier zu beschreiben würde zu weit führen, da sie auf wirklich viele Faktoren eingeht, es lohnt sich aber auf jeden Fall sie zu lesen. Man bekommt eine Idee wie weit eine auf Freiheit, Verantwortung und Vertrauen beruhende Unternehmenskultur gehen kann. In vielen Bereichen weicht sie stark von dem ab was in anderen Unternehmen auch nur für möglich gehalten wird, und doch beschreibt sie nur was bei Netflix bereits funktioniert.

Elon Musk - Tesla: Communication Within Tesla, ca. 2010

Ein sehr spezifischer aber sehr wichtiger Aspekt einer Unternehmenskultur ist die Frage wer auf welchem Kanal mit wem kommuniziert. Die Antwort von Elon Musk ist: jeder mit jedem, und das möglichst direkt. Obwohl er das explizit von klassischen prozessgetriebenen Vorgehen abgrenzt nennt er nicht alle damit verbundenen Effekte und Voraussetzungen, die werden in dem verlinkten Artikel aber zum Teil nachgeliefert. Ein wichtiger Punkt der dort nicht genannt wird: um immer ansprechbar zu sein und andere ansprechen zu können muss man dafür offene Zeitfenster einplanen, sonst ist es nicht ernst gemeint.

Mark Zuckerberg - Facebook: Founder’s Letter, 2012

Zu Beginn noch sehr ins Allgemeine gehend steht im unteren Teil dieses Briefes das, was nach allem was man hört tatsächlich die bei Facebook vorherrschende Einstellung ist. "The Hacker Way" bedeutet, dass Ideen möglichst schnell und in vielen kleinen Schritten umgesetzt werden und dass sie niemals fertig, niemals alternativlos und niemals von Anfang an klar sind. Was sich beim ersten Überfliegen noch nicht so besonders anhört enthält radikale Konsequenzen, wie z.B. die, dass auch Manager in der Lage sein müssen Code zu schreiben. In der Tat ein sehr naheliegender Weg um zu verhindern, dass die Fachabteilung die IT-Produktentwicklung nicht versteht.

---

Vermutlich würden sich noch weitere derartige Texte finden lassen, die hier nehme ich weil fast jeder die dahinterstehenden Firmen kennt. Und die Reaktion von (Change-)Managern nach dem Lesen ist ein guter Indikator dafür wieviel Veränderung in einem Unternehmen wirklich möglich ist.

Donnerstag, 15. Februar 2018

Story Points, nicht Requirement Points

FS
Bild: Freegreatpicture / Max Pixel - CC0 1.0
Es gibt im agilen Umfeld Themen die immer weitere Informationen preisgeben, je mehr man sich in sie vertieft. Story Points gehören auf jeden Fall dazu, mit ihnen kann man wesentlich mehr machen als es auf den ersten Blick scheint. Bevor es darum geht aber zunächst zum Grundsätzlichen: Story Points sind eine neutrale Schätzgröße, mit der man den Umsetzungsaufwand von Anforderungen schätzen kann ohne berücksichtigen zu müssen wer genau die Umsetzung vornehmen wird. Mehr dazu hier. Es bleibt allerdings eine Frage - warum dann der wunderliche Name? Wäre "Requirement Points" nicht passender?

Der Grund für die Benennung liegt darin, dass mit Story Points ursprünglich User Stories geschätzt wurden. Ein kurzer Exkurs: User Stories sind Anforderungen in einfacher Sprache, die (End)Anwender, Use Case und Business Value in einem Satz benennen. Mehr dazu hier. Diese exklusive Verwendung gibt es heute kaum noch, mit Story Points werden nicht mehr nur User Stories geschätzt sondern alle anderen Anforderungen genauso. Manche Teams nennen auch einfach jede Anforderung User Story, allerdings ist das dann nicht mehr das was damit beabsichtigt ist.

Um Missverständnissen vorzubeugen, Story Points als generische Schätzeinheit für alle Anforderungen zu verwenden ist nicht per se schlecht. Trotzdem kann es Sinn machen ihre Benutzung auf User Stories zu beschränken. Denn: wenn der (End)Benutzer derjenige ist für den Software gebaut wird, und wenn alles was er damit tun kann ein Use Case ist der sich mit User Stories abbilden lässt, dann kann (und sollte) man bei allem was keine User Story ist die Sinnfrage stellen.

Natürlich verfolgen auch "Nicht-User Stories" einen Zweck. Code wird bereinigt, Lastfähigkeit hergestellt, Architektur wird geradegezogen, Tests werden automatisiert und halbfertige Funktionen werden komplettiert. Der Punkt ist nur der - das kann man auch gleich machen, als Teil einer User Story die benutzbare Funktionalität liefert. Diese Tätigkeiten auf die lange Bank zu schieben ist nichts weiter als das Anhäufen organisatorischer Schulden, wodurch alles länger dauert und teurer wird.

Wenn also alles was dem Anwender Nutzen bringt als User Story formuliert werden kann, und wenn praktisch alle nichtfunktionalen Anforderungen in diesen User Stories unterkommen können, dann kann man auch sagen: User Stories sind das was Mehrwert liefern, der gesamte Rest ist Waste. Unsinnige Arbeit - oder die Folge unsinniger Arbeit.

Die Anwendung von Story Points nur auf User Stories bedeutet in diesem Fall, dass deren Durchschnittsmenge pro Sprint, die Velocity, nur Mehrwert erzeugende Arbeit anzeigt und den Rest ignoriert. Für Teams kann das sehr wertvoll sein. Ihre Velocity zeigt nicht mehr womit sie Zeit verbracht haben (🡢 Output) sondern womit sie Wert generiert haben (🡢 Outcome). Und mit dieser Erkenntnis können sie daran arbeiten den Output zu senken und den Outcome zu erhöhen.

Die Negativseite dieses Ansatzes ist natürlich, dass in Teams mit vielen "Nicht-User Stories" die Velocity nicht mehr beim Planen hilft. Allerdings - dort wo es viele organisatorische Schulden gibt ist Planung ohnehin nur eingeschränkt möglich, man bleibt zu häufig in den Spätfolgen der eigenen Versäumnisse hängen.

Montag, 12. Februar 2018

Fraktale Skalierung (Scrum@Scale)

FS
Bild: Wikimedia Commons / Richard Bartz - CC BY-SA 2.5
Die einfachsten und häufigsten Arten der Zusammenarbeit mehrerer Scrum Teams sind das so genannte Scrum of Scrums-Meeting (SoS) zur regelmässigen Absprache und die Einrichtung von Meta-Teams, in denen Delegierte der Einzelteams an übergreifenden Zielen arbeiten. Wie die Zusammenarbeit in SoS und Meta-Teams genau aussieht schwankt von Fall zu Fall, genau wie die Frage wie sie in die umgebende Organisation eingebettet werden. Jeff Sutherland (einer der Gründer von Scrum) versucht zwar seit einiger Zeit unter dem Namen "Scrum@Scale" die Begriffsverwendung zu strukturieren, allerdings ohne daraus ein schriftliches Regelwerk zu machen. Bis jetzt.

Vor wenigen Tagen hat Scrum Inc. (Sutherlands Firma) erstmals einen Scrum@Scale-Guide veröffentlicht, in dem die Begriffe klarer definiert werden als bisher. Der ist zwar kein offizieller Teil von Scrum, genau wie das Nexus-Framework des anderen Scrum-Gründers Ken Schwaber hat er aber allein durch seinen Urheber eine gewisse Autorität. Und mit der definiert er Folgendes:

Separate Skalierung für Scrum Master und Product Owner

Das Scrum of Scrums wird nicht mehr nur als Meeting verstanden sondern als Organisationsform, in der die Scrum Master der Teams gemeinsam an der Beseitigung organisatorischer Blocker und Hindernisse arbeiten. In großen Organisationen kann es mehrere davon geben, die sich dann wiederum in einem "Scrum of Scrums of Scrums" (SoSoS) koordinieren. Gespiegelt dazu gibt es eine vergleichbare Organisation der Product Owner, die MetaScrum-Teams (die auch auf weiteren Ebenen so heißen, Meta-MetaScrum-Teams gibt es nicht). Die jeweils höchste Skalierungsebene heisst "Executive Meta Scrum" für die POs und "Executive Action Team" für die Scrum Master. Diesen beiden Teams können ggf. die selben Personen angehören.

Fraktaler Aufbau

Auf jeder Ebene sind die Scrums of Scrums und MetaScrums als Scrum Teams organisiert, mit Sprints, Backlogs, Scrum-Events, Scrum Mastern und Product Ownern. Diese Rollen können von Mitgliedern der beteiligten Teams übernommen werden, ggf. aber auch Vollzeitstellen sein. Bei den POs wird hier der Begriff des Chief Product Owner (CPO) übernommen, allerdings mit unklaren Kompetenzen: er soll den POs keine User Stories vorgeben, aber trotzdem ein übergreifendes Backlog verantworten und priorisieren. Um eine Verwirrung um den Begriff "Scrum of Scrums" zu vermeiden bezeichnet er nur noch die Teams, die Meetings werden in "Scaled Daily Scrum" umbenannt.

Querschnittsteams

So genannte "Knowledge & Infrastructure Teams" können gebildet werden wenn es von bestimmten Spezialisten nicht genug gibt um sie in jedes Team zu setzen. Sie sollen weiterhin in ihren eigentlichen Scrum Teams bleiben, bilden aber zusätzlich dazu ein "virtuelles Scrum Team", das Aufgaben für die gesamte Organisation wahrnimmt.

Jedes Team ist ein Scrum Team, auch ausserhalb der Produktentwicklung

In einzelnen Fällen kann es Spezialisierungen geben die so stark von den Tätigkeiten der anderen Teams abweichen, dass sie nicht in die oben genannten Strukturen integriert werden können. Als Beispiele werden Customer Relations, Legal, Compliance und HR genannt. Auch diese Teams sollen nach Scrum organisiert sein.

---

So weit, so gut ...

Was man diesem Ansatz lassen muss ist, dass er unternehmensweites Scrum konsequenter umsetzt als jeder andere. Gleichzeitig lässt er aber auch bewusst Lücken: das Verhältnis von Product Owner und Chief Product Owner ist nicht genau geklärt, die Entstehung übergreifender Architekturen, Coding- und Dokumentationsstandards wird nicht angesprochen und die Mehrfachbelastung durch Mitarbeit in mehreren Ebenen wird nicht thematisiert. Die empfohlene Lösung für derartige Punkte ist ein so genanntes "Referenzmodell", mit dem jede Organisation ihren eigenen Weg definieren und für sich verbindlich machen soll. Es wäre spannend zu sehen wie diese Fragen in der täglichen Zusammenarbeit einer Scrum@Scale-Implementierung gelöst werden.

Donnerstag, 8. Februar 2018

Pinball in Progress

FS
Bild: Wikimedia Commons / Michael Moore - CC BY-SA 3.0
Die besten Inspirationen kommen oft unerwartet. Die letzten Tage habe ich auf einem Kanban-Workshop mit Klaus Leopold verbracht und dabei einen anderen Teilnehmer kennengelernt der größte Schwierigkeiten hatte sein Kanban-System zu modellieren. Der Grund: starke Abhängigkeiten zu anderen Teams (sowohl fachlich als auch technisch) sowie eine übergriffige und erratische Unternehmenskultur sorgen dafür, dass in seinem Arbeitsalltag ständig unvorhersehbare Störungen auftreten und sich kein stabiler Arbeitsstrom herausbilden kann. Auf dem Board lässt sich deswegen lediglich eine große "In Progress"-Spalte erstellen, deren Arbeit sich fast jeden Tag anders gestaltet.

Die Beschreibung dieser Situation erinnerte mich stark an die im Inneren eines Pinball-Automaten. Auch in dem gibt es einen Eingang und einen Ausgang durch die Objekte (in diesem Fall Kugeln) das System betreten und verlassen. Aber: zwischen Ein- und Ausgang gibt es verschiedene blockierende Elemente, von denen die durchlaufenden Objekte abprallen können. Passiert das verändern sie auf unkontrollierbare Weise ihren Kurs und sind nur mit Mühe wieder in die richtige Richtung zu lenken. Genau derartige Bedingungen machten das Modellieren des Systems derartig schwierig. Nun zur Inspiration: könnte man die Analogie dafür nutzen ein Board im Pinball-Stil zu designen? Ein spontaner Erstentwurf sieht so aus:


Wie man sieht: aus der Work in Progress-Spalte wurde die "Pinball in Progress-Spalte", die mit Flippern (unten), schmalem Ausgang (oben) und Abprall-Körpern (rund und dreieckig) wie das Innere eines Pinball-Automaten gestaltet ist. Die Arbeitspakete (Post Its) fliessen durch den "Automaten" durch. So weit, so gut, nur - wozu das Ganze? Aus zwei Gründen. Zum einen wäre das ungewöhnliche Board-Design durch seine Andersartigkeit ein Aufhänger für Gespräche. Ähnlich wie im Fall des Zombie-Cage würde es für Aufmerksamkeit, Konversation und Problembewusstsein sorgen. Zum anderen würde das Kanban-Board gleichzeitig zu einem Impediment-Board. Die Abprallkörper symbolisieren schliesslich nichts anderes als organisatorische Impediments. Und da sie sich by Design bereits im In Progress-Bereich befinden kann gleich an ihrer Behebung gearbeitet werden. Die Anzahl dieser Elemente zeigt damit auch die Störanfälligkeit des Systems an.

Ist noch nicht ganz ausgereift, hat aber Potential. Jetzt muss ich nur noch ein Team überreden so etwas aufzubauen. Konstellationen in denen so etwas Sinn bringen könnte gibt es ja leider zur Genüge.

Montag, 5. Februar 2018

Continuous Delivery Excuses Debunked

FS
Eine schöne Übersicht über Ausreden und deren Widerlegungen zum Thema Continuous Delivery. Wer die einleitende Erläuterung was Continuous Delivery ist überspringen will kann ab Minute 13.50 einsteigen.

Mittwoch, 31. Januar 2018

Kommentierte Links (XXXIII)

FS
  • Thomas Ferris Nicolaisen: How Silos Grow

    Vermutlich muss man das was hier beschrieben wird einmal miterlebt haben um seine Tragweite erfassen zu können. Bei verschiedenen Kunden habe ich Zeuge sein dürfen wie als "Startup im Konzern" gegründete Einheiten vom langen Arm der Bürokratie eingeholt wurden, aber dieser Fall ist noch einmal spezieller: ein Startup bildet aus sich heraus und gewissermassen gegen seinen eigenen Willen jene organisatorischen Silos, die die Gefahr von Bürokratisierung von Verlangsamung mit sich bringen. Verbunden mit Verweisen auf agile Grundlangen, Analysen und Lösungsansätzen ist das einer der besten Artikel zu dem Thema die ich seit einiger Zeit gelesen habe.

  • Farnham Street: Complexity Bias - Why We Prefer Complicated to Simple

  • Warum werden wir agil? Weil alles komplex wird. So weit, so gut. Aber warum wird alles komplex? Die für manche überraschende Antwort: weil wir häufig Komplexität gegenüber Einfachheit bevorzugen. Das es dafür mehrere Gründe gibt ist dann wieder weniger überraschend (wäre es sonst noch komplex?), macht es aber schwieriger zu erklären. Diesen Versuch hier finde ich recht gut gelungen, wobei er sich vor allem auf die Ebene der Einzelpersonen konzentriert. In Organisationen ist das nochmal (wer hätte es gedacht) komplexer. Vielleicht schreibe ich meine Gedanken dazu irgendwann auf, sobald ich sie sortiert habe.

  • FAZ: Wir basteln uns ein Büro

    Dass auch die neue Gestaltung von Büroflächen zu einer agilen Transition dazugehört wird immer mehr akzeptiert, wie diese Umbauten in der Realität durchgeführt werden wird dagegen viel zu wenig durchdacht. Im Normalfall werden lediglich Baumassnahmen geplant, verkündet und umgesetzt - häufig mit dysfunktionalen Arbeitsumgebungen als Folge. Alexander von Erdély zeigt auf wie man es besser machen kann, unter anderem durch Vermeidung von unnötiger Arbeitsplatzverknappung, durch Einbindung der Mitarbeiter und durch die Bereitschaft die Umbau- und Sitzpläne feedbackbasiert auch in späteren Phasen anzupassen. .

  • Spiegel Online: Thüringer Tricks

    Ein Thema das indirekt mit dem letzten zu tun hat. Was Florian Diekmann hier aus Südthüringen berichtet steht weiten Teilen von Deutschland in den nächsten Jahren bevor: Fachkräftemangel. Um dem entgegenzuwirken setzen die Arbeitgeber dort auf bessere Arbeitsbedingungen, aber auch auf Mitbestimmung, Augenhöhe und respektvollen Umgang miteinander. Mit anderen Worten - man arbeitet dort an einer besseren Unternehmenskultur. Dass das als Unterscheidungsmerkmal zwischen Mittelständlern und Konzernen gesehen wird sagt viel aus, denn noch immer ist in großen Organisationen ein eher kafkaesker Umgang miteinander die Realität.

  • Barry Overeem: A Summary of the 10 Scrum Myths

    Eine Zusammenfassung einer Artikelserie der letzten Wochen. Zehn häufige Falschannahmen über Scrum werden erklärt und widerlegt. Sowohl in der Zusammenfassung als auch in den detaillierteren Einzelartikeln lesenswert. Die Serie ist auch bereits weitergegangen, mal sehen wie viele "Scrum Myths" noch kommen.

Montag, 29. Januar 2018

Weniger ist mehr

FS

Eine Tendenz die bei neu gestarteten agilen Transitionsvorhaben häufig zu beobachten ist, ist die Konzentration auf das Erschaffen von Neuem. Neue Rollen, neue Prozesse, neue Regeln, neue Visionen, neue Skalierungsframeworks, neue Tools, neue Hierarchien, neue Karrierepfade, etc., etc. Das ist auch nicht notwendigerweise falsch, es ist aber meistens ein bewusst oder unbewusst durchgeführter Versuch um das größte Problem herumzunavigieren: die organisatorischen Altlasten.

Dass eine Organisation sich überhaupt verändern möchte liegt in der Regel daran, dass sie die Herausforderungen der Gegenwart nicht mehr bewältigen kann, und das wiederum liegt fast nie an zu wenig Strukturierung und fast immer an zu viel davon. Wer in solchen Strukturen arbeitet kennt die Beispiele: selbst kleinere Ausgaben müssen über den Tisch des Bereichleiters, ein Zugriff auf bestimmte Entwicklungs- oder Testumgebungen muss schriftlich beantragt werden, jede noch so kleine neue Software ist vom Betriebsrat zu prüfen bevor sie benutzt wird. Die Liste ließe sich endlos fortsetzen.

Wenn jetzt zusätzlich zu all dem noch neue Rollen, Regeln und Prozesse eingeführt werden, dann führt das in den meisten Fällen nicht zu schnelleren und flexibleren Prozessen. Im besten Fall ändert sich nichts, im schlimmsten Fall wird sogar alles noch langsamer. Wenn dann argumentiert wird, "dass das alles nichts bringt" ist nicht abzustreiten, dass darin eine Wahrheit liegt - eine derartig durchgeführte Transition sollte hinterfragt und in vielen Fällen besser abgebrochen werden.

Ein wesentlich besserer Ansatz ist es, als erstes einen anderen Weg zu gehen, nichts Neues einzuführen und stattdessen bestehende Regeln abzuschaffen. Das ist natürlich schwierig und schmerzhaft, weil es mit langjährigen Gewohnheiten bricht und weil viele mittlere Manager darauf bestehen werden, dass gerade die von ihnen verantwortete Genehmigung unglaublich wichtig für Qualität, Transparenz, Effizienz oder Effektivität wäre. Aber diese Anstrengungen lohnen sich.

Auch hier machen Beispiele alles anschaulich: Wenn die Testabteilung nicht mehr das Monopol auf die Qualitätssicherung hat kann jedes Team sie selber durchführen und muss nicht mehr um Test-Ressourcen kämpfen und auf sie warten. Wenn nicht mehr jedes kleine Monitoring-Tool durch einen Genehmigungsprozess muss lassen sich verschiedene von ihnen schnell ausprobieren, um so das beste zu finden. Und wenn nicht mehr jeder Kleinbetrag freigegeben werden muss sinken häufig sogar die Kosten, die vorher im Wesentlichen durch die Verwaltungsabläufe entstanden sind.

Das an dieser Stelle folgende Gegenargument ist so alt wie die Bürokratie selbst: "Aber dann macht ja jeder was er will!". Und es ist gut wenn es kommt, denn ausgehend von ihm kann man jetzt über Selbstorganisation und Autonomie reden. Die sollten nämlich als nächstes entstehen, wenn die Transition ernst gemeint ist.

Donnerstag, 25. Januar 2018

Denn sie wissen nicht, wen sie rekrutieren (III)

FS
Bild: Rawpixel - CC0 1.0
Stellen wir uns folgende Konstellation vor: ein professioneller Sportverein, zum Beispiel Bayern München, muss in dem hochgradig wettbewerbsintensiven Umfeld einer Topliga bestehen. Um dazu in der Lage zu sein benötigt er Spitzenpersonal - auf jeder Position Spieler von internationaler Klasse, einen Trainer der idealerweise schon durch Titel bewiesen hat, dass er Mannschaften zum Erfolg führen kann, dazu Spezialisten wie Masseure, Platzwarte und weitere. Um diese Spitzenkräfte zu bekommen beschäftigt jeder große Verein Scouting- und Talentförderungseinheiten, in denen ausgewiesene Fachleute dafür sorgen, dass nur das beste Personal engagiert wird.

Übertragen wir es auf die IT: ein großes Technologieunternehmen, das in einem extrem volatilen und disruptiven Marktumfeld unterwegs ist, muss versuchen mit der nationalen und internationalen Konkurrenz mitzuhalten. Um dazu in der Lage zu sein benötigt es Spitzenpersonal - Entwickler, Tester, Produktmanager, UX-Designer und Scrum Master. Um diese Spitzenkräfte zu bekommen beschäftigt es ... Scouting- und Talentförderungseinheiten? Im Idealfall ja, in der Realität leider nur zum Teil. Sehr häufig wird die Personalsuche an externe Dienstleister ausgelagert, und an der Stelle beginnen die Probleme.

Auf welche haarsträubende Weise Personalvermittler und Headhunter häufig vorgehen habe ich schon mehrfach aufgeschrieben, heute soll es darum um eine andere und naheliegende Frage gehen: Warum geben viele Firmen diese extrem wichtige Aufgabe an so offensichtlich überforderte Dienstleister weiter? Aus meiner Erfahrung sehr häufig aus zwei Gründen - um Kosten zu sparen und um Verantwortung (und Schuld) zu externalisieren.

Das (scheinbare) Kostenargument hat seinen Ursprung im Zerfall vieler Unternehmen in unterschiedliche organisatorische Silos, die auch nach unterschiedlichen Zielen gesteuert werden. Ich kenne Personalabteilungen in denen es als wichtigstes Erfolgskriterium gilt wenn der Scouting- und Rekrutierungsprozess möglichst billig ist. Die offensichtliche Folge: es werden Aufträge an Billig-Anbieter vergeben, die billiges Personal beschäftigen, welches in Zeiten des Fachkräftemangels fast zwangsläufig unqualifiziert sein muss.

Die Externalisierung von Verantwortung und Schuld dagegen geht auf die Firmenkultur zurück. Wenn eine Kontroll- und Bestrafungskultur vorherrscht führt das automatisch dazu, dass bereits von Anfang an alle Arbeit so organisiert wird, dass man im Zweifel einem anderen die Schuld geben kann. Externe Dienstleister sind da ein dankbarer Sündenbock: sie sind in den Schuldzuweisungsrunden nicht dabei (können sich also nicht verteidigen) und man kann sich leicht von ihnen trennen.

In Kombination sorgen diese beiden Faktoren für zwei Ergebnisse. Zum einen werden die HR-Abteilungen intern gelobt und belohnt, denn sie können die Kosten niedrig halten und sich als durchsetzungsstark profilieren indem sie von Zeit zu Zeit einen Dienstleister zum Sündenbock machen und vom Hof jagen. Zum anderen führt der qualitativ geringwertige Rekrutierungsprozess zu Fehlbesetzungen mitsamt der erwartbaren negativen Auswirkungen auf Qualität und Effektivität, die dann aber ein anderes organisatorisches Silo ausbaden muss. Mit anderen Worten: dort wo die Probleme entstehen werden die Mitarbeiter dafür belohnt, dass sie nichts ändern, dort wo die Probleme ihre Auswirkungen haben gibt es nicht die Möglichkeit die verursachenden Prozesse zu verbessern.

Soweit die Problemanalyse, was aber wäre die Lösung? Verkürzt gesagt: die Auflösung organisatorischer Silos, die Beendigung von lokaler Optimierung auf Kosten anderer Firmenteile und die Abschaffung der kontroll- und bestrafungszentrierten Firmenkultur. Das würde zwar viel bringen, wäre aber anstrengend und langwierig. Und darum lassen viele Firmen lieber alles so wie es ist und fluchen dafür regelmässig über die eigenen Leute.
Powered by Blogger.