Samstag, 31. Dezember 2016

Kommentierte Links (XX)

Grafik: Pixabay / Geralt - Lizenz
Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen zeitweise vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" Texte aus dem letzten Jahr.


  • Steve Denning: Explaining Agile

    "Erklär doch mal mit einfachen Worten was dieses Agile sein soll". Wer sich bei solchen Fragen bisher nicht richtig artikulieren konnte wird bei Seve Denning fündig. Er definiert drei Grundprinzipien die in allen agilen Ansätzen auftauchen:
    1. The Law Of The Small Team: Kleine, crossfunktionale, autonom agierende Einheiten mit eigener Verantwortung für Produkte und Prozesse.
    2. The Law Of The Customer: Absolute Konzentration auf das, was dem Kunden einen Mehrwert bringt und Verzicht auf alles andere.
    3. The Law Of The Network: Aufbrechen von hierarchischen Ebenen, Abteilungsgrenzen und technischen/fachlichen Silos.
    Die meisten mir bekannten Organisationen die sich als agil bezeichnen folgen übrigens nur dem ersten Gesetz, was sich in erkennbaren Problemen niederschlägt. "Ein bisschen agil sein" geht nicht.

  • Ron Jeffries: Do you want Crappy Agile?

    Müsste man Ron Jeffries einem literarischen Genre zuordnen, es wäre definitiv der Rant, die wütende, humoristisch angehauchte Schimpftirade. In diesem Fall hat er sich die Metriken (Messwerte, KPIs, etc) vorgenommen, mit denen viele Unternehmen versuchen die Produktivität, Effektivität oder Agilität ihrer Produktentwicklung zu messen. Der Titel lässt es ahnen, er hält nicht besonders viel davon, zumindest dann nicht wenn es übergeordnete Organisationsebenen sind die hinter der Datenerhebung stecken. Diese Versuche richten seiner (und meiner) Meinung nach mehr Schaden als Nutzen an, wie er an den Beispielen von dreiundzwanzig verschiedenen Metriken klar macht. Anders sieht es dagegen aus wenn es ein Entwicklungsteam selbst ist, das sich mit Hilfe von gesammelten Daten verbessern will. Das ist ein richtiger Ansatz, solange er nicht von den höheren Ebenen gekapert wird.

  • Charles Duhigg: What Google Learned From Its Quest to Build the Perfect Team

    In mehreren Unternehmen habe ich bereits miterleben müssen, wie hochgradig dysfunktionale Teams zusammengestellt wurden, weil nur auf die Qualifikation der Teammitglieder geachtet wurde und nicht auf ihre soziale Kompatibilität. Auf der anderen Seite lieferten Teams mit im Einzelnen schlechter qualifizierten Mitgliedern sehr gute Ergebnisse, wenn diese gut miteinander harmonierten. Das Aristoteles-Projekt von Google hat diese Erkenntnis jetzt auf eine breitere Datenbasis gestellt und bestätigt. Um diese Kompatibilität sicherzustellen wird versucht die nötigen Rahmenbedingungen zu schaffen, indem um die Teams herum psychologische Safe Zones errichtet werden. Dass dieses vor allem dadurch erreicht werden soll, dass die Mitglieder miteinander regelmässig über ihre Gefühle reden sollen sehe ich zwiespältig, aber die Grund-Idee ist richtig.

  • Albina Popova: When story points misfire (Part 2, Part 3)

  • Auf dem Global Scrum Gathering in München habe ich einen Vortrag von Albina Popova gehört, der auf diesen drei Artikeln beruhte. Selbstkritisch hat sie selbst angemerkt, dass die Art wie sie und ihr Team mit Storypoints und Estimations umgegangen sind suboptimal war. Da Storypoints allerdings kein direkter Bestandteil von Scrum sind ist es legitim gewesen auf eine Korrektur zu verzichten und stattdessen etwas anderes zu probieren, in diesem Fall den #NoEstimates-Ansatz. Den zu bewerten würde hier den Rahmen sprengen, auf jeden Fall ist das Ganze aber eine interessante und lesenswerte Fallstudie geworden.

  • Jonathan Smart: Agile Manifesto Values add on for large enterprises

  • Zugegeben, das hier ist gar kein verpasster Artikel der letzten Monate sondern einer von vorletzter Woche. Da es aber diesesmal keine Dezember-Ausgabe der kommentierten Links gibt steht er jetzt hier. Jonathan Smarts Agile Manifesto Values add on for large enterprises sieht so aus.
    • Delighting Customers First over Shareholder Returns First
    • Focusing on delighting customers first leads to shareholder returns
    • Enterprise-wide Agility over Agile for Software Development Only
    • Optimise for flow, learning and feedback, along the whole value stream
    • Empowered Product Teams over Command & Control Role Based Work Passing
    • Long lived multi-disciplinary teams with high Alignment, Autonomy and Safety aligned to value stream
    • Achieving Big Through Small over Achieving Big Through Big
    • Small teams, hypothesis driven investment, optimise for flow, for better outcomes faster
    In seinem Artikel führt er näher aus was er damit meint. Lesenswert nicht nur wegen der Erklärungen sondern auch wegen der vielen weiterführenden Links.

  • Jason Little: The Change Before the Change (Edit: Link ist mittlerweile tot)

    Auch Jason Little geht auf das Thema der hinter Agile und Scrum stehenden Werte ein. An einem Beispiel aus einem seiner Kundeneinsätze zeigt er auf wie ein falsches Mindset des Managements eine agile Transition von Anfang an so unterminierte, dass sie praktisch zum Scheitern verurteilt war. Mir gefällt bei ihm die differenzierte Betrachtung - das Management handelt nicht so weil es böse oder unfähig ist sondern weil es selbst in Strukturen gefangen ist die über lange Zeit gewachsen sind und nur nach und nach abgebaut werden können.

  • Michael Küsters: SAFe impressions

    In meiner "agilen Filterblase" ist SAFe etwas von Grund auf Schlimmes. Der Tenor ist, dass es sich um eine pseudo-agile, hierarchische, schwerfällige und restriktive Methode handelt, die nur von Managern gemocht wird die eigentlich lieber nach Wasserfall arbeiten würden. Ich muss gestehen, dass auch ich skeptisch war (und bin), allerdings hat es mich immer gestört, dass sich kaum einer der lautstarken Kritiker näher mit dem Thema beschäftigt hat. Michael Küsters hat das im letzten Halbjahr ausführlich getan. Auch nach dem Lesen seiner insgesamt zwölf Artikel zu dem Thema kann man noch skeptisch sein, uninformiert ist man jedenfalls nicht mehr.

Montag, 26. Dezember 2016

Ein Bild sagt mehr als 1000 Worte (XV)

Donnerstag, 22. Dezember 2016

Ich packe meinen Koffer

Bild: Publicdomainpictures/George Hodan (1, 2, 3) - CC0 1.0
So kann es auch kommen: diese Woche habe ich von dem Scrum Master den ich gerade coache etwas gelernt, nämlich eine Übung die sich gut in Retrospektiven und Management-Workshops einsetzen lässt. Eine eingängige noch dazu, sie beruht auf einem Spiel das in Deutschland so gut wie jeder als Kind gespielt haben dürfte: Ich packe meinen Koffer.

In der Kinderversion geht das Spiel so, dass man der Reihe nach vom Packen eines Koffers erzählt und bei jeder Person einen einzupackenden Gegenstand hinzufügt. Ich packe meinen Koffer und nehme ein Paar Schuhe mit. Ich packe meinen Koffer und nehme ein Paar Schuhe und eine Sonnenbrille mit. Ich packe meinen Koffer und nehme ein Paar Schuhe, eine Sonnenbrille und ein Handtuch mit. Und so weiter. Wer als erstes einen der bereits genannten Gegenstände vergisst hat verloren.

In der Erwachsenenversion steht statt des zu packenden Koffers ein bürokratischer Prozess im Mittelpunkt, beispielsweise ein Produktionsrelease. Für ein Produktionsrelease führe ich einen Code Freeze durch. Für ein Produktionsrelease führe ich einen Code Freeze durch und führe alle Regressionstests aus. Für ein Produktionsrelease führe ich einen Code Freeze durch, führe alle Regressionstests aus und dokumentiere ihre Ergebnisse im Quality Center. Für ein Produktionsrelease führe ich einen Code Freeze durch, führe alle Regressionstests aus, dokumentiere ihre Ergebnisse im Quality Center und lade Screenshots jedes einzelnen Arbeitsschrittes hoch. Für ein Produktionsrelease führe ich einen Code Freeze durch, führe alle Regressionstests aus, dokumentiere ihre Ergebnisse im Quality Center, lade Screenshots jedes einzelnen Arbeitsschrittes hoch und bitte das Testmanagement um die QA-Freigabe. Und so weiter und so weiter.

Das Ziel ist bei dieser Version des Spiels nicht, dass der Satz so lang wird, dass jemand einen Teil vergisst (selbst wenn das vorkommen mag). Das Ziel ist vielmehr, allen Beteiligten klar zu machen wie umfangreich und ausufernd manche Prozessketten geworden sind. Das alleine kann schon einen Mehrwert (Erkenntnisgewinn) bringen, wobei sich der noch steigern lässt. Wenn irgendwann der ganze Bürokratievorgang an der Wand steht kann man nämlich hingehen und einzelne Teile davon streichen, und zwar so lange bis alles weg ist was nicht wirklich notwendig ist. Die durchgestrichenen Passagen auch in der echten Welt abzuschaffen kann dann der Arbeitsauftrag sein mit dem alle das Meeting verlassen.

Montag, 19. Dezember 2016

Akkordarbeit (und warum sie in der IT nicht funktioniert)

Bild: Pixabay/Selenajain - Lizenz
Der Artikel Büroarbeit wird zur Akkordarbeit aus der Süddeutschen Zeitung ist in den letzten Tagen recht intensiv in meiner Timeline diskutiert worden. Der Titel ist selbsterklärend und das Thema nicht falsch, die Kombination von Detailkontrolle und Akkordarbeit sollte man kritisch sehen und nur vorsichtig einsetzen. Problematisch wird dieser Artikel dadurch, dass er agile Softwareentwicklungs-Methoden in diesen bedenklichen Trend mit einschließt. Er versucht zwar zu differenzieren (und ist damit schon einen Schritt weiter als der Spiegel letztes Jahr), rutscht aber immer wieder in die Haltung zurück, dass überschaubare Aufgaben und transparenter Arbeitsfortschritt etwas schlechtes sind.

Ohne den Text komplett aufdröseln zu wollen (sein Verfasser Alexander Hagelüken hat darin auch Zutreffendes aufgeschrieben) möchte ich mich auf den zuletzt genannten Punkt konzentrieren, da ich glaube, dass er auf einer falschen Annahme beruht. Auf der nämlich, dass es überhaupt möglich ist Arbeitsprozesse in der Software-Entwicklung so zu zerlegen und kontrollierbar zu machen, dass Akkordarbeit durchführbar wird. Nach über 10 Jahren in dieser Branche bezweifele ich das sehr.

Zunächst ist die grundlegende Eingangsvoraussetzung nicht gegeben: um Arbeit in fest definierte Arbeitspakete zu zerlegen und diese zu verteilen müsste man bereits im voraus wissen welche Arbeit in der nächsten Zeit anfällt. Um das wiederum zu wissen müsste man sie schon mindestens einmal durchgeführt haben, um irgendeinen Anhaltspunkt für Schätzungen und Optimierungen zu haben. In der Fabrikproduktion geht das, man kann auf diesem Weg die Herstellung eines Autos immer effizienter machen. In der Softwareproduktion ist das entweder sinnlos oder unmöglich: wenn das neue und das alte Produkt genau gleich sind übernimmt man einfach mit Copy & Paste den gesamten Code, wenn sie nicht gleich sind bringen die Erfahrungen der Vergangenheit nur vage Anhaltspunkte. Man baut dann einen Prototypen, mit allen damit verbundenen Unwägbarkeiten.

Das bedeutet natürlich nicht, dass Firmen nicht trotzdem versuchen würden Akkordarbeit einzuführen. Die Arbeit wird im voraus in Pakete verteilt, ihnen wird eine Zeitschätzung angehängt und sie werden auf die Mitarbeiter verteilt. Entweder erweist sich die Schätzung dann schnell als unrealistisch oder es zeigt sich, dass weitere Arbeiten zu erledigen sind die am Anfang nicht bedacht wurden. Die übliche Reaktion darauf ist, dass die Mitarbeiter zu Überstunden angetrieben werden um den Zeitplan zu halten. Die reagieren ebenfalls, indem sie dort Arbeit einsparen wo der Vorgesetzte es nicht sehen kann. Es wird weniger in Clean Code, saubere Architektur und gründliches Testen investiert, kleinere Defects werden nicht gemeldet, auszubauende Komponenten werden nicht entfernt sondern nur auskommentiert. Natürlich führt das in der Zukunft zu Mehrarbeit, wodurch insgesamt der Effekt entsteht, dass höherer Arbeitsdruck die Leistungsfähigkeit nicht etwa steigert sondern sogar senkt.

In fast allen Software entwicklenden Unternehmen in denen ich bisher gewesen bin galt Akkordarbeit aufgrund dieses Phänomens als etwas kontraproduktives. Selbst wenn das Management sie gerne gehabt hätte war jedem klar, dass sie in der Realität nicht umsetzbar sein würde. Und an der Stelle wurden die in kurzen Abschnitten präsentierte Zwischenergebnisse, die für agiles Arbeiten unverzichtbar sind, auch wieder unproblematisch: natürlich kam regelmässig die Frage auf ob das nicht schneller gehen würde, ohne den dazu notwendigen Hebel ließ sich dieser Fortschritt aber nicht erzwingen. Um den Bogen zurück zum Beginn zu schlagen: ja, Akkordarbeit in Büros ist ein Problem. Aber: nein, Akkordarbeit in der (agilen) Softwareentwicklung ist keines.

Das alles heisst übrigens nicht, dass man in agilen Methoden nicht mit Deadlines planen kann. Dafür gibt es andere Ansätze, die aber ein Thema für sich sind.

Donnerstag, 15. Dezember 2016

Code Ownership (II)

Bild: Pixabay / Lorenzocafaro - Lizenz
Dass Code Ownership schlecht ist ist klar. Wenn nur ein einziger Entwickler den Code bearbeiten darf besteht ein großes Risiko sobald er krank wird oder kündigt. Der neue Code Owner muss sich einarbeiten bevor er weiterentwickeln kann, dadurch geht Zeit verloren und dadurch Produktivität und Geld. Schlimmstenfalls muss unverständlicher Code komplett neu geschrieben werden. Wenn ein Entwickler Anspruch auf Code Ownership erhebt sollte es daher die Aufgabe von jedem anderen Mitarbeiter sein zu widersprechen. Was aber wenn dieser Anspruch gar nicht erhoben wird und Code Ownership trotzdem entsteht? Gibt es diese Situation überhaupt? Ja, es gibt sie.

Ein Beispiel dafür kann sein, dass Teile einer Anwendung in einer eher unbekannten, obskuren oder schlecht angesehenen Programmiersprache verfasst werden, etwa in Clojure, Whitespace oder Coffeescript. Die meisten Entwickler werden von sich aus darauf verzichten sich damit zu befassen, wodurch die verbleibenden automatisch zu Code Ownern werden, die im Zweifel nur schwer zu ersetzen sind. Für diese Situation gäbe es verschiedene Lösungen: man kann festlegen, dass nur Sprachen benutzt werden sollen die von einer ausreichenden Zahl von Entwicklern verstanden werden, man kann andere in neuen Sprachen schulen oder man kann vorgeben in welchen Sprachen programmiert werden soll.

Ein anderer Fall liegt vor wenn alte Anwendungen nicht mehr weiterentwickelt sondern nur noch von den an der Entstehung beteiligten "am Leben erhalten werden". Neue Entwickler müssen sich damit gar nicht mehr befassen, da "das ohnehin irgendwann abgeschafft wird". Wenn dieses "Irgendwann" sich dann unerwartet lange zieht kann die Verrentung der älteren Mitarbeiter zum Problem werden: ausser ihnen kennt niemand mehr den alten Code, der auch keinen modernen Standards mehr entspricht. Ein aktuelles Beispiel solcher "Alters-Code Ownership" ist die Flugsicherungs-Software am Flughafen Paris Orly. Die Lösung hierfür ist Common Sense - niemand sollte Systeme benutzen die zwanzig Jahre und älter sind.

Zuletzt kann es auch "sozial bedingte Code Ownership" geben. Wenn ein Entwickler für die anderen so unangenehm ist, dass sie die Zusammenarbeit mit ihm meiden (sei es wegen schlechtem Benehmen, schlechter Körperhygiene oder sonstigen Gründen), dann kann es vorkommen dass er beabsichtigt oder unbeabsichtigt Code schreibt den nur er selbst lesen kann. Ein vergleichbares Phänomen tritt auf wenn einer von den anderen ausgegrenzt oder gemobbt wird und er deswegen alleine arbeiten muss oder will. In der Behebung ist das der vermutlich schwierigste Typ, da nicht jeder Mensch bereit oder in der Lage ist sein Verhalten zu ändern. Lösungen hierfür könnten Mediation sein, Coaching, moderiertes Feedback oder im schlimmsten Fall disziplinarische Maßnahmen.

In jedem dieser Fälle ist es wichtig, dass erkannt wird, dass die jeweilige Situation Code Ownership zur Folge hat, mit allen bekannten Folgen. Selbst wenn die Situation bisher aus irgendeinem Grund nicht thematisiert wurde - spätestens jetzt sollte das geschehen, da sonst unkalkulierbare Geschäftsrisiken entstehen können.

Montag, 12. Dezember 2016

Die Wasserfall-Populisten

Bild: Wikimedia Commons/Nathan Keirn - CC BY-SA 2.0
Wie immer geht es auch heute um agile Methoden und um Change Management, abweichend von der Norm aber eingeleitet durch einen Exkurs in die Politik.

Das Jahr 2016 dürfte rückblickend als das Jahr der Populisten in die Geschichte eingehen. Die AfD in Deutschland, die FPÖ in Österreich, die UKIP in England, die M5S in Italien und die Trump-Kampagne in Amerika waren bei den Wahlen ausserordentlich erfolgreich. Warum das so ist wird kontrovers diskutiert, eine allgemein akzeptierte Erklärung dafür gibt es aber noch nicht. Einer der interessanteren Ansätze kommt von Michael Seemann, der im Herbst einen Artikel veröffentlichte in dem er die populistischen Bewegungen als Reaktion auf das Entstehen einer neuen Sozialen Klasse deutete:
"Es gibt heute eine globalisierte Klasse der Informationsarbeiter, der die meisten von uns angehören und die viel homogener und mächtiger ist, als sie denkt. Es sind gut gebildete, tendenziell eher junge Menschen, die sich kulturell zunehmend global orientieren."
Seemann sieht in dieser Klasse eine Gruppe die sich verstreut über Landesgrenzen und politische Lager erstreckt und ihre Gemeinsamkeit darin findet, dass sie neue (fortschrittliche) Normen und Standards aufstellt, während sie gleichzeitig die traditionellen gesellschaftlichen Kategorien als überkommen und rückständig ablehnt. Da das offen und sogar offensiv stattfindet kollidiert es mit den Haltungen der eher konservativen Menschen. Noch einmal Seemann:
Und das merken die anderen, die kulturell Abgehängten. Sie merken, dass uns ihre Welt zu klein geworden ist, dass wir uns moralisch überlegen fühlen und dass wir nach größerem streben. Vor allem merken sie, dass wir dabei erfolgreich sind, dass wir auf diesem Weg die Standards definieren, die nach und nach auch an sie selbst angelegt werden.
Gegen dieses Bedeutung verlieren und abgehängt werden rebellieren die Menschen. Sie wollen nicht, dass es dazu kommt, stattdessen soll es wieder so sicher und überschaubar werden wie frührer. Wenn ein Populist ihnen das verspricht wird er gewählt. Und an dieser Stelle können wir den Bogen zurück zur IT schlagen.

Dreissig Jahre nach dem New New Product Development Game und fünfzehn Jahre nach dem agilen Manifest sind agile Methoden zwar noch nicht überall umgesetzt, es gilt aber bis hinauf in die Management-Ebenen als ausgemacht, dass ihnen die Zukunft gehört. Fast jeder will agil sein, will nach Scrum arbeiten, will "so sein wie Google und Netflix", redet von Backlogs, Standups, Disruption und flachen Hierarchien. Wer weiterhin Releases bauen, Lead Developer werden oder Lastenhefte abarbeiten will gilt in vielen Unternehmen als gestrig, verschnarcht und potentiell verzichtbar.

Das klingt übertrieben? Ist es aber nicht. Mittlere Manager müssen sich anhören, dass sie im Grunde Störfaktoren sind (z.B. hier) Mitarbeiter werden plötzlich in Großraumbüros verfrachtet, selbst wenn sie sich über die Jahre an das Arbeiten in stillen Einzelzimmern gewöhnt haben, manuellen Testern wird die berufliche Existenzberechtigung abgesprochen, älteren Entwicklern wird ins Gesicht gesagt, dass ihre Erfahrung nicht viel wert ist, Architekten und Testverantwortlichen wird angekündigt, dass sie bald zu normalen Teammitgliedern degradiert werden. Allen wird klargemacht: wenn die agile Transition zu ihnen kommt wird sie von den alten Hierarchien und Karrierepfaden nicht viel übriglassen.

Die Parallelen zur politischen Debatte sind offensichtlich: die agilen Entwickler und Manager bilden die neue Länder- und branchenübergreifende Klasse, der zugeschrieben wird die Zukunft zu verkörpern, den "traditionellen" Fachkräfte wird das Gefühl vermittelt langsam aber unaufhaltsam abgehängt zu werden. Auch die Rolle des populistischen Verführers lässt sich schnell finden: Es ist der Manager, Berater oder Betriebsrat, der verkündet, dass man zum alten Wasserfall-Vorgehen zurückkehren und trotzdem wettbewerbsfähig bleiben könnte. Dass das mit den heutigen Rahmenbedingungen immer schwerer wird (und z.T. bereits jetzt nicht mehr möglich ist) wird dabei ignoriert. Stattdessen wird genau das geboten was den Populismus ausmacht: eine (scheinbar) einfache Lösung für ein komplexes Problem.

Einen Ausweg aus dieser Situation zu finden ist in der IT genauso schwierig wie in der Politik. Wer sich einmal auf die populistische Versuchung eingelassen hat ist nur noch schwer zu erreichen, igelt sich in seinem Weltbild ein, verdrängt alles was nicht dazu passt und misstraut jedem der etwas anderes sagt. Verständlich, die Erkenntnis, dass der eigene Status und Karrierepfad gerade von einer schöpferischen Zerstörung demoliert werden ist etwas was man gerne verdrängen möchte.

An dieser Stelle enden allerdings die Gemeinsamkeiten von Software-Entwicklung und Politik. Man kann nicht einfach einen Donald Trump zum IT-Präsidenten wählen oder per IT-Exit aus der agilen Transition der Branche austreten. Beziehungsweise: man kann schon, wird dann aber das Schicksal von Nokia, Kodak und MySpace teilen. Das behutsam zu vermitteln und den "einfachen Weg zurück" als Populismus zu enttarnen ist im Moment eine zentrale Change Management-Aufgabe.

Donnerstag, 8. Dezember 2016

The Future of Software Engineering

Eine gute Zusammenfassung von Mary Poppendieks Artikeln The New Technology Stack, Integration Does. Not. Scale und The Two Sides of Teams, vorgetragen von ihr selbst auf der Goto-Konferenz. Und selbst wenn ich bei Zukunftsvorhersagen immer sehr vorsichtig bin - es ist sehr wahrscheinlich, dass es genau so kommen wird (und kommen muss) wie sie es beschreibt.

m

Montag, 5. Dezember 2016

Denn sie wissen nicht, wen sie rekrutieren (II)

Bild: Pixabay/Adabara - Lizenz
Drüben bei Personalmarketing 2null geht es im Augenblick unter anderem darum, dass Stellen oft unbesetzt bleiben, weil Personaler und Vermittler sich bekloppte irreführende Stellenbezeichnungen ausdenken, mit denen dann keiner etwas anfangen kann. Aus eigener Erfahrung kann ich das bestätigen, denn was ich bei Ausschreibungen im Scrum-Umfeld mitbekommen habe war zum Teil haarsträubend.

Beispiel 1:

Eine Firma führt agile Vorgehensweisen bei sich ein und macht zunächst einmal etwas sehr Vernünftiges: den Teams wird freigestellt mit welcher Methode sie arbeiten wollen. Scrum, Kanban, sogar kleinere und exotische Methoden, alles ist erlaubt. Einzige Bedingung ist, dass es jemanden gibt der sicherstellt, dass die jeweilige Methode verstanden und angewandt wird. Da der Begriff des Scrum Masters ausserhalb von Scrum nicht passt wird diese Rolle unternehmensweit in "Agile Master" umbenannt. Jetzt geht es an die Besetzung und noch eine sinnvolle Entscheidung wird getroffen: die Leute auf diesen Positionen sollen Berufserfahrung mitbringen. Was macht die Personalabteilung? Genau, sie erstellt Stellenprofile in denen steht "notwendige Einstellungsvoraussetzung: mehrjährige Berufserfahrung als Agile Master". Da dieser Titel aber ausserhalb dieses Unternehmens nicht existiert findet sich niemand den man einstellen kann.

Beispiel 2:

Eine Anfrage einer Personalberatung kommt herein, für die Stelle eines "Consultant oder Senior Consultant". Zu den Aufgaben gehören "Analyse der Methoden", "Benchmarking", "Gestaltung der Prozesse", "Erhebung von Daten" und "Gewährleistung der Konformität". Um welche Methoden, Prozesse, Benchmarks und Daten es geht wird nicht erläutert. Kurze Zeit später folgt ein Anruf: ob man die Ausschreibung bekommen hätte und interessiert wäre. Nach einem kurzen Gespäch klärt sich warum die Anfrage so nichtssagend war - der freundliche Personalberater hat das "Fach-Chinesisch" des Kunden entfernt, damit der Text "lesbarer" wird. So wurde aus dem "Senior Scrum Master/Senior Product Owner" der "Senior Consultant", aus der "Analyse der passenden agilen Methoden" wurde die "Analyse der Methoden", etc, etc. Mit anderen Worten - es wurde alles entfernt was einen Scrum-affinen Menschen ansprechen würde.

Beispiel 3:

Um sich "von der Masse abzusetzen" beschließt eine Personalabteilung, dass die Rollen umbenannt werden, damit sie "mehr hip" und "mehr fancy" erscheinen. Aus dem Software-Entwickler wird der "Agile Development Expert", aus dem Scrum Master der "Process Evangelist" und aus dem Product Owner der "Delivery Champion". In die Welt geschickt wird das dann mit übertrieben euphorischen Formulierungen wie "Booste die Performance Deiner Crew als Process Evangelist (m/w) bei _____". Völlig überraschend gibt es kaum Rückläufer. Auf den Hinweis, dass das an den völlig weltfremden Formulierungen liegen könnte reagieren die Verantwortlichen beleidigt. Da hätte man sich doch erkennbar Mühe gegeben und dann wäre es auch wieder nicht recht. Man solle doch bitte nicht so destruktiv sein.

Diese drei Geschichten haben sich tatsächlich zugetragen, und es sind leider keine Einzelfälle. Das aus meiner Sicht Erschütternde daran war, dass selbst sachliche und konstruktive Hinweise komplett abgebügelt wurden. Ich habe die Geschichten nicht weiter verfolgt und bin mir nicht sicher ob die Stellen jemals besetzt wurden, auf jeden Fall hat man es sich aber bei der Personalsuche unnötig schwer gemacht.


PS: Um etwas Kontext zu geben - in der Zeit gibt eine Personalvermittlerin einen Einblick in ihre Sicht der Dinge.