Kommentierte Links (LXXXIII)
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 vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" aber trotzdem lesenswerten Texte aus dem letzten Jahr.
"Ich wollte doch nur helfen" dürfte die häufigste Entschuldigung von Managern sein wenn ihre Untergebenen sich über übergriffiges Micromanagement beschweren. Man kann davon ausgehen, dass das in den meisten Fällen tatsächlich die zugrundeliegende Motivation ist, trotzdem liegt oft am Ende das Vertrauensverhältnis in Trümmern. Wie eine Konstellation aussieht in der eine Hilfestellung auch als eine solche empfunden wird arbeiten Colin M. Fisher, Teresa M. Amabile und Julianna Pillemer anhand von Fallstudien heraus: demjenigen dem geholfen wird muss klar sein, dass er alleine nicht weiterkommt, es muss bereits vor dem Hilfsangebot
psychologische Sicherheit vorhanden sein und die Hilfe muss sich an der Verfügbarkeit und Aufnahmebereitschaft desjenigen dem geholfen wird ausrichten.
Zu den grössten Herausforderungen vor denen agil arbeitende Organisationen stehen gehört die Entwicklung eines beruflichen Karriere-Modells. Klassische Karrierepfade stehen durch ihre Linearität und ihre Einbettung in organisatorische Silos im Widerspruch zum agilen Zielbild, die häufig anzutreffende "agile Alternative" einer Fachkarriere ohne feste Abteilungs-Zuordnung macht es dagegen schwer Weiterentwicklungen zu erkennen (und zu belohnen). Das von Emily Webber entwickelte Modell von
Citizens Advice versucht beides möglich zu machen, mit einem Ansatz der die klassischen Junior/Mid-Weight/Senior-Pfade beibehält, es aber möglich macht mehrere parallel zu verfolgen und zwischen ihnen zu wechseln (
hier ein Erfahrungsbericht der Einführung). Eine schöne Inspiration für ähnliche Versuche.
In der allgemeinen Wahrnehmung ist die IT etwas noch immer Neues, Junges und Modernes. Was bei dieser (oberflächlichen) Betrachtung allerdings untergeht ist, dass auch dieser scheinbar moderne Zweig der Technik bereits mehr als ein halbes Jahrhundert alt ist. Diese lange Geschichte führt dazu, dass in den einstigen Pionier-Branchen (Telekommunikation, Banken, Versicherungen) mittlerweile Generationenkonflikte stattfinden, und zwar sowohl zwischen älteren und jüngeren Mitarbeitern als auch zwischen älteren und neueren Technologien. Am Beispiel eines fiktiven Systemadministrators erzählt Simon Pitt davon wie dieser Konflikt ausgetragen wird und die Arbeitswelt verändert.
Es ist eine Erkenntnis die weitreichende Auswirkungen darauf hat wie Menschen Problemlösungen angehen sollten und darauf wie die Wirksamkeit dieser Lösungsbemühungen bewertet werden sollte: das menschliche Gehirn scheint eine natürliche Tendenz zu haben Problemlösungsstrategien darauf aufzubauen, dass dem problembehafteten Objekt etwas
hinzugefügt wird - Features, Kontextinformationen, Restriktionen, Benutzergruppen, etc. Das findet selbst dann statt, wenn die gegenteilige Vorgehensweise, also das
Weglassen sinvoller wäre. Diana Kwon fasst in diesem Text zusammen wie Forscher der Universität von Virginia diese Erkenntnis gewonnen haben, wer die Studie im Original lesen will
findet sie hier.
Seit Henrik Kniberg die
Tribe-Organisation von
Spotify bekannt gemacht hat ist die Wortwahl mit der über agile Skalierung gesprochen wird eine andere, bis zu dem Punkt, dass man das Gefühl haben kann mit einer Gruppe Ethnologen zu reden. Naheliegenderweise könnte man denken, dass auch einige echte Vertreter dieser Berufsgruppe in den Diskurs einbezogen werden sollten, doch das ist noch nicht passiert - bis jetzt. Gaëtan Belbeoc'h hat ein Jahr Feldforschung unter Eingeborenenvölkern am Amazonas betrieben und zusammengefasst welche Parallelen es zwischen ihrer Selbstorganisation und der in agilen Teams gibt. Spoiler: es sind einige.
Ein eher technisches Thema.
Pull Requests (Anfragen an einen anderen Entwickler neuen Code zu begutachten und freizugeben) sind in vielen Firmen verpflichtender Teil des Software-Entwicklungsprozesses und werden oft als State of the Art angesehen. Jessica Kerr hat da eine andere Meinung. Tatsächlich kann man die Probleme die sie beschreibt häufig beobachten: (zu lange) auf Freigabe wartende Arbeitspakete, Kontext-Switching zwischen eigener Arbeit und dem Reviewen von anderem Code, dadurch gestörte Konzentration, zwischenmenschliche Konflikte und vieles mehr können zu Ineffizienz, nachlassendem Engagement und schlechterem Betriebsklima führen. Die von ihr vorgeschlagene Alternative ist ein Klassiker unter den agilen Praktiken:
Pair- und Mob-Programming.
Apropos Pair Programming. Auch diese Praktiken sind mittlerweile zum Gegenstand wissenschaftlicher Untersuchungen geworden, in diesem Fall in der Psychologie. In einem leicht nach Science Fiction klingenden Experiment wurden Softwareentwickler während der Durchführung von Solo-, Pair- und Mob-Programming an ein Gerät zur Messung von Gehirnaktivitäten angeschlossen. Die Ergebnisse: während Ruhezustände vor allem im Solo-Programming vorkamen führten Pair- und Mob-Programming zu höherer Konzentration und geringerem Schwierigkeitsempfinden. Die durchführenden Forscher geben selbst an, dass die Ergebnisse vor allem ein Anstoss zu weiterer Forschung sind, interessant sind sie aber auf jeden Fall.
Obwohl sich dieser Artikel von Ellen Cushing vor allem auf Slack bezieht lassen sich seine zentralen Punkte auch auf vergleichbare Dienste übertragen, z.B. auf HipChat oder MS Teams. Neben einer Optik und Bedienbarkeit die sich stark an Social Networks anlehnt und damit für eine niedrige Eingangshürde sorgt nennt sie vor allem die Dezentralität, Hierarchiefreiheit und allgemeine Zugänglichkeit. Abgeleitet daraus erkennt sie eine sehr starke Demokratisierung und Egalisierung der Kommunikation in allen Unternehmen die diese Programme bei sich einsetzen. Ein klarer Fall von "Function follows Form", den jeder bestätigen kann der schon einmal mit Slack & Co gearbeitet hat.
