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.

Mittwoch, 30. November 2016

Kommentierte Links (XIX)

Grafik: Pixabay / Geralt - Lizenz
  • Shane Drumm: 100 Powerful Agile Techniques to Conquer All Projects

    Eine wirklich lange Liste, aber eine auf der sich viel Gutes wiederfindet. Ich habe über die Hälfte dieser Techniken bereits selber angewandt, ohne dass mir selber bewusst gewesen wäre wie viele es mittlerweile geworden sind. Und unter den Sachen die ich noch nicht gemacht habe sind sicher einige die ich beizeiten ausprobieren werde.

  • Roland Losch: Audi will das Fließband abschaffen

  • Der Artikel kam knapp zu spät, gerade zwei Tage vorher musste ich einem interessierten Gesprächspartner gestehen, dass ich kein deutsches Unternehmen der Automobilindustrie kenne, das Hardware (Autos) agil herstellt. Jetzt kenne ich eines und finde die Geschichte sehr interessant. Auch aus der eigenen Historie heraus, denn das Problem mit den potentiell unendlich vielen Konfigurationsmöglichkeiten eines Autos habe ich auf einem Projekt selber miterleben dürfen. Und natürlich ist die Einführung des fließbandlosen Arbeitens auch ein Softwareprojekt, nur durch IT-Unterstützung wird sich sicherstellen lassen, dass ein Auto während seiner Montage die richtigen Stationen in der richtigen Reihenfolge erreicht.

  • Paula Scheidt: Ić bin kein Schweizer

    Ein gutes, bzw. erschreckendes Beispiel dafür, welche Auswirkungen es haben kann wenn eine Software nicht anpassbar oder erweiterbar ist. Das Eidgenössische Justiz- und Polizeidepartement der Schweiz benutzt eine Software namens Infostar, welche auf der ISO-Norm 8859-15 beruht. Und die kann diakritische Zeichen lediglich bis zu einer Menge von 191 Symbolen speichern. Die weiteren fallen weg. Konkret bedeutet das, dass bei einer Einbürgerung ein Herr Håkon Øven aus Norwegen die Schreibweise seines Namens behalten darf, eine Frau Ćirila Mađar aus Bosnien aber zu einer Cirila Madar werden muss. Die Lösung, ein Umstieg von 8859-15 auf UTF-8 (den international üblichen Standard, der alle Zeichen darstellen kann) wäre technisch möglich, aber aufwändig und damit zu teuer. Wäre die Software modular aufgebaut gäbe es dieses Problem vermutlich nicht.

  • Christian Dähn: Wie man ein chaotisches Team organisiert

    Eine häufige Fragestellung: wie organisiert man Personen oder Teams mit unbeständigen und sich häufig ändernden Aufgaben so, dass Transparenz gewährleistet wird und man sogar einen gewissen Grad an Planbarkeit erhält? Das münchner Büro von it-agile hat dafür einen interessanten Lösungsansatz entwickelt, der auf einer Visualisierung mit Lego-Steinen beruht. Unabhängig davon ob man das jetzt damit oder mit anderen Mitteln macht - die Idee hat ihren Charme. Ich frage mich nur was passiert wenn die Kinder eines Kollegen mit ins Büro kommen und die Lego-Steine entdecken.

Montag, 28. November 2016

Automatisierung

Bild: Wikimedia Commons/BMW-Werk Leipzig - CC-BY-SA-2.0
Nochmal zu den Voraussetzungen für eine gelungene Einführung von Scrum/Agile. Digitalisierung hatten wir schon, was braucht man noch? Automatisierung zum Beispiel. Auch hier blicke ich manchmal in große Augen wenn ich das erwähne. Automatisierung, ist das nicht etwas für den Maschinenbau? Aber wir produzieren doch Software! Ja, genau. Und auch da kann man Abläufe automatisieren.

Zu den großen Hindernissen gehören in der agilen Softwareentwicklung langwierige manuelle Prozesse. Ich habe bereits in mehreren Firmen erlebt, dass das Deployen von neuer Software auf höhere Entwicklungs- oder Testumgebungen Tage oder sogar Wochen dauerte (einen Großteil davon nahm das Warten darauf ein, dass die Personen die das als einzige konnten oder durften Zeit hatten). Nochmal wesentlich länger kann die Durchführung manueller Regressionstests dauern, der "Rekord" den ich in dieser Beziehung beobachtet habe waren drei Monate - solange dauerte es bis das Testteam alles durchgeklickt hatte. Auch die in manchen Branchen notwendige Dokumentation der Einhaltung von Vorschriften kann sich ziehen, ich erinnere mich an ein Projekt in dem mehr als zehn Prozent der Arbeitszeit dafür verwendet wurden.

Warum das mit agilen Methoden nicht vereinbar ist dürfte klar sein: wer in kurzen Abständen fertige Funktionen liefern will kann es sich nicht leisten tage-, wochen- oder sogar monatelang zu warten bis irgendwelche manuell durchgeführten Tätigkeiten beendet sind. Die einzige Lösung dafür ist dann eben die Automatisierung. Automatisierte Deployments brauchen nur noch Minuten, automatisierte Testsuites je nach Anteil der UI-Tests maximal Stunden und selbst Dokumentationen kann man automatisieren. Wer seine Aufgaben täglich in Tools wie Jira oder HP ALM aktualisiert (in wenigen Minuten machbar) kann deren Report-Bereiche gleich als Dokumentation nutzen, ohne dass zusätzliche Arbeit anfällt. Ist das alles etabliert sind selbst einwöchige Sprints kein organisatorisches Problem mehr. Und warum macht es dann nicht jeder?

Dass in vielen Firmen (noch) auf die Automatisierung verzichtet wird hat mehrere Gründe. Fehlende Kenntnis der technischen Möglichkeiten ist einer, Technik-Skepsis ein anderer (ja, die gibt es seltsamerweise auch in der IT-Industrie), am häufigsten ist aber das (scheinbare) Kostenargument. Für Erstellung und Betrieb der Automatisierungs-Programme müsste man ja personelle Ressourcen bereitstellen, für die einfach kein Geld da wäre. Alles viel zu teuer. Einer näheren Betrachtung hält das allerdings nicht stand, im Gegenteil: durch die Automatisierung der Abläufe werden Arbeitskräfte freigesetzt, die sich jetzt eben nicht mehr durch manuelle Kleinarbeit quälen müssen. Und selbst wenn von diesen freigewordenen Kapazitäten ein Teil für die genannten Aufgaben wieder draufgeht - in Summe steht bei gleichem Personalaufwand ein größerer Anteil der Arbeitskraft für die Produktentwicklung zur Verfügung.

Automatisierung macht Softwareentwicklung also nicht nur schneller, es macht sie auch billiger.

Donnerstag, 24. November 2016

Code Ownership und Bus-Faktor

Code Snippet: creativecommons.org - CC BY 4.0
Um es mit den Worten eines befreundeten Scrum Masters zu sagen: "Wenn man nicht ab und zu über Code spricht sollte man auch nicht über Scrum sprechen." In diesem Sinn - sprechen wir über Code, in diesem Fall konkret über Code Ownership. Was das ist, was es sein kann und was es nicht sein sollte.

Code Ownership bedeutet, dass ein Entwickler "Besitzansprüche" auf einen Teil des Quelltextes erhebt. Dieses allerdings nicht in dem Sinn, dass er der Eigentümer ist, sondern eher dahingehend, dass er der Einzige ist, der diesen Abschnitt bearbeiten darf. Gründe dafür gibt es verschiedene: den Glauben alleine schneller oder besser zu sein, den Unwillen mit anderen zusammenzuarbeiten, den Wunsch unersetzbar zu sein oder den Versuch fehlerhafte Arbeit vor anderen zu verbergen. Aber lassen wir die negativen Deutungen weg und gehen wir vom besten Fall aus - da ist jemand der wirklich so viel besser ist als die anderen, dass er Code schreibt, der so genial ist, dass nur er ihn versteht.1 Ist Code Ownership in diesem Fall eine gute Idee? Nein, auch dann nicht.

Selbst wenn es (scheinbar) eine gute Idee ist, dass bestimmte Code-Abschnitte nur von einer bestimmten Person bearbeitet werden dürfen, geht jedes Projekt und jede Firma die sich darauf einlässt ein unkalkulierbares Risiko ein. Denn wenn diese eine Person ausfällt hat die gesamte Organisation ein Problem, schließlich ist dann niemand in der Lage ihre Aufgaben zu übernehmen. Man spricht in diesem Zusammenhang vom so genannten Bus-Faktor, der definiert wie viele Mitarbeiter ausfallen (von einem Bus angefahren werden) müssen um alle Arbeit zum Stillstand zu bringen. Im Fall von angewandter Code Ownership liegt dieser Faktor bei 1: wenn ein einziger Code Owner ausfällt blockiert das im Zweifel alle anderen. Arbeitsfortschritte gibt es nicht mehr, Agilität schon gar nicht.

Um dieses Risiko zu beseitigen bleibt letztendlich nur eine Möglichkeit: Code Ownership darf es nicht geben, bzw. nur in Form ihres Gegenteils, der "shared Code Ownership": Jeder Entwickler darf jeden Teil des Codes bearbeiten, und nicht nur das - jeder sollte sich irgendwann einmal mit jedem Teil des Codes beschäftigt haben. Nur dann hält sich das Ausfallrisiko in Grenzen. Der in diesem Fall ideale Bus-Faktor ist genau so hoch wie die Teamgröße. Erst wenn jeder einzelne von einem Bus angefahren wurde (was sehr unwahrscheinlich ist) kann die Arbeit nicht mehr weitergehen.

In Scrum, Extreme Programming und ähnlichen Methoden ist es aus diesem Grund best Practice, dass gemeinsam an Programmieraufgaben gearbeitet wird. Für die konkrete Umsetzung gibt es dabei mehrere Möglichkeiten: Pair Programming, Code Reviews oder die Verteilung der Unteraufgaben einer User Story auf mehrere Personen sind die üblichsten. Die Teams mit derartigen Ideen bekannt zu machen sollte Bestandteil jeder Einführung agiler Entwicklungsmethoden sein.


1Natürlich ist das ein schlechtes Beispiel, denn unverständlicher Code ist nur selten genial

Montag, 21. November 2016

Instant Implementation Hour


"Kannst Du mal eben diese Kleinigkeit hier erledigen?" Sätze die so anfangen sind in nahezu jedem agilen Projekt oder Unternehmen ein Problem. Auf der einen Seite sagen wir nicht ohne Grund, dass neue Arbeit nur über das Sprint Planning oder das Replenishment Meeting in die Teams gebracht werden sollte. Wird sie immer sofort eingebracht sind die Entwickler permanenten Unterbrechungen und Kontext Switches ausgesetzt, worunter ihre Konzentration leidet (und damit auch die Qualität ihrer Arbeit). Auf der anderen Seite ist es aber auch nur schwer einzusehen, warum Kleinstaufgaben wie die Korrektur von Rechtschreibfehlern oder das Setzen von Links tagelang oder sogar wochenlang warten sollen. Man muss also versuchen eine Lösung zu finden die beide Seiten zufriedenstellt.

Eine Lösung die ich letzte Woche bei einem Unternehmen gesehen habe ist die "Instant Implementation Hour". Jeden Mittag schickt jedes Team einen Vertreter zu einem kurzen Standup-Meeting, auf dem Stakeholder ihre kleineren Anliegen vorstellen können. Wenn sie wirklich klein sind (d.h. in weniger als einer Stunde beendet werden können) kommen sie auf ein Board und werden sofort erledigt. Aufgaben die als zu groß oder zu unklar erkannt werden müssen wieder mitgenommen werden und gehen den üblichen Weg über die Backlogs und Planungsmeetings.

Mir hat diese Instant Implementation Hour spontan gefallen. Da die eine Stunde im voraus planbar ist wird niemend plötzlich aus seiner Arbeit herausgerissen, da aus jedem Team nur ein Vertreter diese Stunde einplanen muss können die anderen an ihren Aufgaben weiterarbeiten und da das Meeting an einem zentralen Ort stattfindet stört es die anderen nicht in ihrer Konzentration. Gleichzeitig wird sichergestellt, dass kleine Aufgaben nicht unnötig lange warten müssen. Nicht zu unterschätzen ist ausserdem, dass Fachabteilungen und Stakeholder auf diese Weise an die agile Meetingkultur herangeführt werden.

Werde ich bei Bedarf/Gelegenheit auch bei meinen Kunden einführen.

Donnerstag, 17. November 2016

Survivor Bias

Bild: Pexels / Oliver Sjöström - Lizenz
"Bei Spotify macht man das auch so." "Die Methode haben wir von Zalando übernommen." "Das ist das gleiche Vorgehen wie bei Netflix." "Wir machen das so wie Google." Sprüche wie diese habe ich über die Jahre bei vielen verschiedenen Firmen hören dürfen wenn mir Scrum-Anpassungen, Skalierungsframeworks oder Ähnliches erklärt wurden. Auf den ersten Blick erscheint es auch einfach und naheliegend: suche nach Beispielen für eine gelungene agile Transition, sieh Dir an wie es dort gemacht wurde, mach es genauso - voila, alles funktioniert. Oder doch nicht, denn etwas entscheidendes wird dabei vergessen.

Der Blick auf Spotify, Google, Netflix und Zalando verzerrt die Wahrnehmung, denn sie haben eine Gemeinsamkeit die so offensichtlich ist, dass sie schon wieder übersehen wird: sie haben überlebt und sind erfolgreich. Die dahinterliegende Bedeutung wird klar wenn man sich andere Unternehmen ansieht die nicht so glücklich waren, geschlossen wurden oder vor sich hinkrebsen - in ihnen findet man mitunter genau die gleichen Teamaufteilungen, Organisationsprinzipien und Skalierungsansätze wieder. Man sieht: nur an denen allein kann der Erfolg nicht liegen.

In mehreren Einsätzen in großen Projekten/Abteilungen (5 - 30 Teams) habe ich die Erfahrung gemacht, dass gerade im skalierten Umfeld viel "historisch gewachsen" ist. Firmenstrukturen oder Firmenkulturen sorgen dafür, dass ein und die selbe Lösung in einem Fall hervorragend funktionieren, in einem anderen aber zu Stillstand oder Chaos führen kann. Gute Ansätze können durch eine ungeschickte Einführung so diskreditiert sein, dass sie nicht mehr einsetzbar sind, andere, eher suboptimale können in bestimmten Konstellationen gute Ergebnisse bringen. All das kann man von aussen nicht sehen.

Für ein differenziertes Bild sollte man aus diesem Grund nicht nur fragen "Welche Methoden von erfolgreichen Unternehmen können wir auch bei uns einsetzen?", man sollte auch fragen in welchen Kontexten diese Methoden eingebettet waren und ob es andere Situationen gab in denen sie nicht funktioniert haben. Unterlässt man das und konzentriert sich nur auf die Erfolgsfälle ist die Wahrnehmung verzerrt - und basierend auf verzerrten Wahrnehmungen sollte man besser keine Methoden, Prozesse oder Frameworks einführen.

Montag, 14. November 2016

Agilität, dort wo man sie nicht vermutet

Bild: Wikimedia Commons/Alter Fritz - CC BY-SA 3.0
Ich habe meine berufliche Laufbahn in einer der vermutlich unagilsten Umgebungen begonnen die man sich vorstellen kann: in einer deutschen Behörde. Ich konnte dort einiges von dem miterleben was große Organisationen so ineffizient macht - starre Hierarchien, ungleich verteilte Arbeitsbelastung, organisatorische Silos, derartige Sachen. Der offensichtlichste Missstand von allen war allerdings ein anderer: die unglaubliche Langsamkeit vieler Kommunikationswege.

Obwohl es natürlich Computer und Telefone an jedem Platz gab wurden wichtige Informationen nach wie vor über Laufmappen verteilt, Papierumschläge auf denen der nächste, der übernächste und z.T. weitere Empfänger bereits vermerkt waren. Beim jeweils nächsten Empfänger angekommen landeten sie auf einem Aktenstapel und wurden nach und nach abgearbeitet, was dauern konnte. Ich erinnere mich an einen Vermerk der nach Monaten zurückkam, mit nichts weiterem als der Notiz "Veraltet, bitte aktualisieren".

Inmitten dieser klischeehaften Vorgänge gab es aber auch Lichtblicke. Sachbearbeiter die einfach alle Beteiligten an einem Vorhaben in ihr Büro einluden um die Angelegenheit direkt zu besprechen, Vorgesetzte die bis zum Praktikanten alle Untergebenen gleich behandelten, Kollegen die sich regelmässig darüber austauschten wie man besser zusammenarbeiten könnte. Ich hatte das große Glück vor allem mit solchen Menschen zusammenarbeiten zu dürfen.

Niemand hätte damals von flachen Hierarchien, von Retrospektiven oder Iterationen gesprochen, letztendlich war das was wir gemacht haben aber nichts anderes. Natürlich, vieles hätte man besser machen können, aber verglichen mit anderen Behörden und Großunternehmen die ich seitdem kennenlernen durfte war das was ich dort miterlebt habe schon sehr gut.

Ich versuche mir diese Phase meiner Vergangenheit von Zeit zu Zeit ins Gedächtnis zu rufen, da sie mich an zwei wichtige Dinge erinnert. Erstens: Agilität kann auch dort vorhanden sein wo man sie nicht vermutet, und Zweitens: sie kann auch existieren ohne dass die standardisierten Begriffe der englischsprachigen Frameworks genutzt werden. Wer das berücksichtigt kann agile Transitionen wesentlich schneller vorantreiben als jemand der puristisch auf der reinen Lehre beharren will.

Donnerstag, 10. November 2016

Change Fatigue

Bild: Wikimedia Commons/Arthur Goss - Public Domain
Zu den größten Hindernissen die im Change Management zu überwinden sind, gehört die kaum ins Deutsche übersetzbare Change Fatigue. Hinter ihr verbirgt sich ein Zustand der Ermüdung, Erschöpfung, Desillusion und Ablehnung gegenüber jeglichen Änderungs-, oder Verbesserungsversuchen, meistens verbunden mit Aussagen wie "Bringt doch alles nichts" oder "Haben wir schon versucht, hat nichts gebracht." Wenn man diese Change Fatigue antrifft, kann man zum Einen sicher sein, dass noch viel Arbeit vor einem liegt, zum Anderen weiß man aber auch ziemlich sicher, dass hier in der Vergangenheit einiges schiefgelaufen ist. Diese Einstellung ist nämlich so gut wie immer das Ergebnis langfristiger Fehlentwicklungen.

Die häufigste Ursache sind in relativ kurzen Abständen vorkommende Strategie- oder Methodenwechsel. Wenn etwa in den letzten fünfzehn Jahren nacheinander Lean Management, Six Sigma, PMP, Kanban und Projektbasierte Matrix-Organisation eingeführt wurden, kann man sicher sein, dass z.B. eine Scrum-Einführung für die Mitarbeiter nur wie die nächste Sau erscheint, die durch das Dorf getrieben wird. Möglicherweise ist die neu einzuführende Methode in der jüngeren Vergangenheit auch schon eingeführt und wieder durch eine andere ersetzt worden, wodurch sie bereits als "verbrannt" gilt.

Selbst wenn dieser ständige Methodenwechsel an sich schon kontraproduktiv und ermüdend ist - eine Steigerung ist möglich. Dann nämlich, wenn er jedes mal mit Erwartungen und künstlich erzeugten Emotionen überladen wird. Gunther Dueck hat es in der Überschrift eines seiner Artikel auf den Punkt gebracht: Grundlose Begeisterung ist Pflicht. Nicht nur der häufig überzogene Pathos der Kickoff-Veranstaltungen ist dabei ein Problem, sondern vor allem die dadurch erzeugte Fallhöhe. Je euphorischer die Ankündigung, dass diesesmal wirklich alles besser wird, desto größer die darauf folgende Enttäuschung, wenn alles beim Alten bleibt.

Noch schlimmer ist es, wenn die Methoden nicht nur bereits "durch das Dorf getrieben" sondern ausserdem missbraucht worden sind, um die Angestellten zu gängeln. Scrum bietet durch seine Transparenz die Möglichkeit zu Micromanagement und Blaming, Lean Startup kann in wahllosen Aktionismus ausarten und Kanban in Akkordarbeit. Wer derartige Erfahrungen bereits hinter sich hat, wird zurecht misstrauisch sein, wenn die Methodenkiste ein weiteres mal aufgemacht wird.

Ich rate in solchen Fällen zu einem mehrstufigen Vorgehen. Als erster Schritt sollten die gescheiterten Methodeneinführungen der Vergangenheit analysiert und die dabei gemachten Fehler festgehalten werden. Das ist für die Beteiligten ein schmerzhafter und unangenehmer Prozess, allerdings meistens der einzige Weg um den Mitarbeitern zu zeigen, dass man aus der Vergangenheit gelernt hat. Aufbauend darauf kann man versichern (und regelmässig überprüfen), dass sich diese Fehler nicht wiederholen.

Der darauf aufbauende zweite Schritt besteht aus dem Verzicht auf eine pompöse Einführungsveranstaltung zugunsten vieler kleiner Schritte. Wer in kurzen Abständen erreichbare Verbesserungen ankündigt und transparent macht ob und wann sie erreicht wurden, erzeugt damit mehr Vertrauen als mit einer weiteren Tschakka!-Veranstaltung. Das heisst nicht, dass es keine langfristigen Visionen geben sollte, es bedeutet aber, dass nicht mehr behauptet wird sie in kurzer Zeit erreichen zu können, wenn man sich denn nur anstrengt.

Als dritter Schritt sollte regelmässig (z.B. monatlich) das Feedback der betroffenen Mitarbeiter eingeholt werden. Haben sie das Gefühl, dass sich die Lage tatsächlich verbessert? Wie zufrieden sind sie mit ihrer Situation? Haben sie das Gefühl, ernstgenommen und mitgenommen zu werden? Im Normalfall ergibt sich aus diesem Feedback, dass die Neuerungen auf den unteren Ebenen zu Unsicherheit, Mehrarbeit und gegebenenfalls sogar Verschlechterungen führen, also dem Gegenteil dessen was eigentlich erreicht werden sollte.

Der vierte Schritt muss jetzt darin bestehen, den ersten Reflexen zu wiederstehen. Diese sind entweder ein frustriertes Zurückrollen aller Veränderungen ("hat ja nichts gebracht"), oder ein weitgehendes Ignorieren der Mitarbeiter-Stimmen ("weil die undankbar sind und ihnen nicht klar ist, dass man doch alles nur zu ihrem Besten tut"). Stattdessen sollte mit den vier Schritten von vorne begonnen werden: Fehleranalyse, kleine Verbesserungsmassnahmen, Feedback einholen und Vorgehen anpassen. Das bedeutet zwar kurzfristige Mehrarbeit, ist aber die beste Möglichkeit um Vertrauen aufzubauen und dem Change Fatigue-Phänomen zu entkommen.

Montag, 7. November 2016

Wie man Teams leistungsfähig macht

Zur Abwechselung mal wieder ein Video. Dieses hier ist besonders empfehlenswert für jeden der irgendeine Art von Weisungsbefugnis oder Personalverantwortung hat, es fasst gut zusammen was man tun oder lassen sollte wenn man ein leistungsfähiges Team haben will. Spoiler: es geht um Offenheit, Transparenz, Toleranz und Menschlichkeit.

Donnerstag, 3. November 2016

Ein Bild sagt mehr als 1000 Worte (XIV)

Bild: Geek & Poke - CC BY 3.0

Montag, 31. Oktober 2016

Kommentierte Links (XVIII)

Grafik: Pixabay / Geralt - Lizenz
  • Jason Little: Is Your Organization Ready for Agile Change? (Edit: Link ist mittlerweile tot)

  • Ich bin mittlerweile ein Fan von Jason Littles Blog, so ziemlich alles was er schreibt könnte ich unterschreiben. Wenn er darüber hinaus noch sinnvolle Werkzeuge vorstellt - umso besser. Die in diesem Beitrag vorgestellten Umfragen habe ich in ähnlicher Form bereits an anderer Stelle gesehen, was ich noch nicht eingesetzt habe sind die Perspective Maps, für die es dort zwei schöne Beispiele gibt. Die Idee dahinter ist, die Sichtweisen verschiedener Gruppen (Teams, Management, Stakeholder, etc) zu erheben und festzuhalten wo sie voneinander abweichen oder sogar gegenläufig sind. Das visualisierte Ergebnis kann dann an einer zentralen Stelle aufgehängt werden, an der es nicht mehr übersehen werden kann. Das ist Transparenz!

  • Melissa Perri: Stop Blaming the User

    Was Melissa Perry da schreibt ist leider eine viel zu häufige Realität. Software (und Hardware) ist oft so benutzerunfreundlich, dass es ohne Vorwissen oder Hilfe nicht mehr möglich ist sie korrekt zu bedienen. Das hat fast nie mit Bosheit oder Unfähigkeit zu tun, sondern fast immer mit "Sachzwängen". Um Geld und Zeit zu sparen werden neue Funktionen nicht richtig entwickelt sondern notdürftig irgendwo an bestehende Prozesse und Oberflächen drangeklemmt, mit den entsprechenden negativen Folgen für Usability und User Experience. Richtig bedenklich wird das aber erst, wenn Unternehmen oder Entwicklungsteams die Schuld für die daraus entstehenden Akzeptanzprobleme auf den Benutzer schieben wollen. Mit Perris Worten: "If the user doesn’t understand something, they are just stupid. If the user won’t tell us what they want, they are difficult. If they are calling to complain, they are ungrateful." Bei der Entwicklung von Anwendungen für die eigenen Mitarbeiter kann dieses User Blaming dazu führen, dass die Betroffenen in die innere Kündigung abtauchen, bei externen Anwendungen können schlechte Presse und Verluste von Marktanteilen die Folge sein. Das Abstellen dieser (vermeintlichen) Sachzwänge sollte daher immer höchste Priorität haben. Apropos:

  • Tom Bartel: Refactoring For Non-Coders

    Einfache Erklärungen wie diese hier von Tom Bartels sind extrem wichtig, und zwar aus einem banalen Grund: zu den technikfernen "Non-Coders" gehört in vielen Unternehmen auch das Management, das die Refactoring-Aufwände verstehen, genehmigen und einplanen muss. Für jemanden der von einer Anwendung nur die Benutzeroberfläche kennt können Refactorings leicht den Eindruck erwecken, hier würde nur "der Code hübscher gemacht". Wenn nur begrenzte Ressourcen verfügbar sind gehört das dann zum Ersten was gestrichen wird (das sind die "Sachzwänge" aus dem letzten Abschnitt). Die Folge: schlecht wartbare, bedienbare und erweiterbare Anwendungen. Mit plastischen Methaphern wie dieser hier können die Auswirkungen von fehlendem Refactoring vermittelt werden.

  • Mike Perrow: 5 tough questions about scaled agile you'll need answers for

    SAFe ist vermutlich das umstrittenste unter den großen agilen Frameworks, für viele ist es sogar ein Antipattern, das durch die Hintertür Wasserfall-Elemente wiedereinführt. Sein Erfinder Dean Leffingwell hat allerdings einen Punkt wenn er festhält, dass Scrum oder Agile in großen Firmen Fragen aufwerfen, die man beantworten können sollte:
    1. Wie kann sichergestellt werden, dass alle Teams das gleiche Ziel im Blick haben und darauf hinarbeiten?
    2. Wie kann verhindert werden, dass die Teams unterschiedliche (schlimmstenfalls inkompatible) Wege in Architektur, Benutzerführung und Design gehen?
    3. Wie funktioniert langfristige (Budget)Planung in einem skalierten agilen Umfeld?
    4. Wie lässt sich berechnen, welchen Geschäftswert die getätigten Ausgaben einbringen werden?
    5. Warum ist eine permanente Anpassung von Anwendung und Anforderungen billiger als das schnelle Fertigstellen und Abliefern klarer Aufträge?
    Ob SAFe die richtigen Antworten auf diese Fragen liefert ist umstritten, zumindest sind sie aber für klassische Management verständlich. Und in einem Punkt hat Leffingwell definitiv recht: wer diese Fragen nicht beantworten kann wird schnell als unseriös gelten und nicht mehr ernstgenommen werden.

  • Harald Schlüter: Eine Fallstudie zur Einführung von Kanban

  • Diese Fallstudie von Harald Schlüter ist gleich in zweifacher Weise interessant: zum einen aufgrund ihres Inhalts, zum anderen aber aufgrund der visuellen Aufbereitung. Auch wenn man bei der Veranstaltung nicht dabei war geben die Flipchart-Blätter einen sehr guten Einblick darüber wie die Einführung strukturiert und durchgeführt wurde..

Donnerstag, 27. Oktober 2016

Digitalisierung

Grafik: Pixabay / Geralt - Lizenz

Wenn meine Kunden mich nach den Voraussetzungen für eine gelungene Einführung von Scrum/Agile fragen nenne ich (neben anderen) immer die Digitalisierung von Daten und Prozessen. Das überrascht dann den einen oder anderen (was wiederum mich überrascht1). Bei genauerer Betrachtung stellt sich oft heraus, dass noch weite Teile des Unternehmens in der Welt der physischen Datenhaltung verblieben sind. Aber warum ist das ein Problem? Aus mehreren Gründen.

Zunächst sind nicht digitalisierte Informationen nur schwer verfügbar. Wenn man sich nicht gerade am Standort des physischen Archivs befindet muss man den Archivar oder die Sekretärin anrufen, sie auf die Suche schicken und hoffen, dass sie das Richtige finden. Und selbst wenn das gelungen ist gehen die Probleme weiter. Entweder man muss auf die Zustellung warten oder man lässt alles einscannen und hat dann ein riesiges, nicht durchsuchbares PDF (oder noch schlimmer: einen Ordner voll JPGs). Handelt es sich bei derartig schwer zugänglichen Dokumenten um wichtige Informationen (Lizenzverträge, Zuständigkeitsabgrenzungen, Stakeholderverzeichnisse, etc.) kann es sein, dass ihre späte Verfügbarkeit den Beginn der Arbeiten stark verzögert, bzw. bereits getane Arbeit obsolet werden lässt.

Dazu kommt, dass physische Daten oft nur mit Mühe zu aktualisieren sind. In einem Unternehmen habe ich erlebt, dass die Mitarbeiter ihr Feedback zu einer neuen Software auf Papier schreiben und in BVW-Briefkästen einwerfen mussten. Alleine das Entziffern und Abtippen dauerte ewig. In einem anderen Fall druckte der Kundendienst die Feedback-Emails der Kunden aus und heftete sie in Aktenordnern ab (!). Infolgedessen traten wieder die im letzten Abschnitt beschriebenen Probleme auf. Mit einem solchen Vorgehen ist es nahezu unmöglich die Rückmeldungen der Benutzer zeitnah in die Weiterentwicklung einfließen zu lassen.

Einen Sonderfall bilden halbherzige oder Teil-Digitalisierungen. Auch hier Beispiele aus der Praxis: In einer Behörde lag der von einer Agentur erstellte Corporate Identity-Leitfaden zwar digital vor, allerdings nur gebrannt auf CDs, die (natürlich) in Aktenordnern im Archiv lagen. In einem anderen Unternehmen waren Produktdaten zwar in einer Access-Datenbank erfasst, die allerdings keine Schnittstelle zu den Webanwendungen hatte, die diese Daten benötigten. Eine Gruppe von Werkstudenten machte nichts anderes als die beiden Systeme manuell zu synchronisieren, was jedesmal mehrere Wochen dauerte.

Wenn solche Daten von Anfang an in miteinander vernetzten CMS oder CRM-Systemen aufgenommen werden können Vorgänge auf eine im Vergleich atemberaubende Geschwindigkeit beschleunigt werden. Auf wichtige Dokumente oder aktuelle Nutzerstatistiken lässt sich innerhalb von Minuten zugreifen, und die entnommenen Informationen und Erkenntnisse können sofort in die Weiterführung der Arbeit übernommen werden. Schöne neue Welt. Erst so lässt sich wirklich agil arbeiten.

Das Problem an dieser Stelle ist natürlich, dass eine Digitalisierung und Vernetzung größerer Aktenbestände Zeit und Geld erfordert. Der mittel- und langfristige Effizienzgewinn ist allerdings so groß, dass diese Investition sich absolut lohnt.


1Okay, mittlerweile nicht mehr.

Montag, 24. Oktober 2016

D-A-CH Chapter der Scrum Alliance ist im Aufbau

Bild: Pixabay/Lusign - Lizenz
Angekündigt war es schon länger, letzte Woche war es so weit: die Scrum Alliance hat im Anschluss an das Global Scrum Gathering Munich ein deutschsprachiges Chapter gegründet. Anders als zunächst angekündigt handelt es sich dabei nicht um eine nationale Organisation nur für Deutschland sondern um eine für den gesamten deutschsprachigen Raum. Die URL lautet zwar noch http://membership.scrumalliance.org/group/GermanChapter [Edit: Link ist mittlerweile tot], der Name ist aber bereits in D-A-CH Chapter geändert. Gut so.

Beim ersten Arbeitstreffen ging es um u.a. Themen wie gegenseitiges Coaching oder die Erarbeitung von Standards für Unternehmen, die Gruppe an der ich teilgenommen habe war aber die, die sich mit der Vernetzung, bzw. dem Aufbau der lokalen Events und User Groups beschäftigt hat. Ein Engagement in diesem Bereich halte ich grundsätzlich für wichtig, schließlich gehören Agilität und Subsidiarität für mich zusammen. Darüber hinaus scheint es in manchen Orten noch Nachholbedarf zu geben - selbst in großen Städten wie Frankfurt oder Wien finden dem Vernehmen nach nur unregelmässig Veranstaltungen statt.

Der bescheidene Beitrag den ich an dieser Stelle leisten kann ist das Weitergeben von Erfahrungen und best practices, schließlich bin ich recht intensiv in der Community in Köln/Bonn unterwegs und trage mit dem Scrumtisch Bonn auch zu ihr bei. Und vielleicht profitiere ich irgendwann auch selbst davon - wenn ich mal wieder ausserhalb des Rheinlandes unterwegs sein sollte wäre eine lokale Veranstaltung eine willkommene Alternative zur Hotelbar.

Donnerstag, 20. Oktober 2016

Backlogs ausmisten! (II)

Bild: Piqsels - Lizenz
Warum zu große Backlogs regelmässig ausgemistet werden sollten habe ich bereits beschrieben, jedem Product Owner lege ich den regelmässigen Griff zur Heckenschere ans Herz. Nicht festlegen würde ich mich auf die maximale Zahl vertretbarer Backlog Items, das kann je nach Einzelfall unterschiedlich sein. Meine Faustregel ist aber, dass man sich spätestens ab dem hundertsten Eintrag Gedanken machen sollte. Konkrete Ratschläge kann ich dagegen zu etwas anderem geben, nämlich dazu nach welchen Kriterien aussortiert werden sollte. Da gibt es mehrere Möglichkeiten:

Nach Priorität

Zugegeben, ein No Brainer. Je weiter nach unten eine Anforderung priorisiert ist desto verzichtbarer ist sie, weshalb man es sich ganz einfach machen kann - weg mit den unwichtigsten 10 Prozent und das Problem ist gelöst. Aber apropos Problem: an dieser Stelle gibt es eines. Die wichtigsten Anforderungen bekommt man noch irgendwie identifiziert, aber in den meisten Backlogs folgt danach eine amorphe Masse in der alles irgendwie gleich (un)wichtig ist. Wie soll man da mit dem Sortieren weitermachen? Die häufigste Antwort darauf lautet:

Nach Business Value

Okay, noch ein No Brainer. Je geringer der erzeugte Mehrwert desto eher kann eine Anforderung weg. Benutzen wir also das als Vergleichswert und wir haben ... schon wieder Schwierigkeiten. Ein paar zentrale Faktoren für ein funktionsfähigeses MVP oder eine bessere Vermarktbarkeit lassen sich natürlich finden, aber dann - wieder Unklarheit. Ist die intuitive Hauptnavigation jetzt wertvoller als der einfache Bezahlvorgang oder der schnelle Login? Viel Spass beim Entscheiden. Aber es gibt ja weitere Priorisierungskriterien. Zum Beispiel:

Nach Alter

Hier werden die Ersten widersprechen. Denn ich würde sagen: je älter eine Anforderung ist desto eher kann sie weg. Das widerspricht für viele den Denkgewohnheiten, schließlich könnte man meinen, dass eine Umsetzung um so dringlicher wird je länger sie sich hinzieht. Ich sehe das umgekehrt - wenn eine Anwendung so lange Zeit ohne ein Feature funktioniert, dann kann das nicht wirklich wichtig gewesen sein. Aber das nächste Dilemma kommt bereits um die Ecke - gerade zu Beginn kippen üblichweise alle Stakeholder gleichzeitig ihre Wünsche ein, wodurch ihre Anforderungen alle ähnlich alt sind. Doch auch hier gibt es einen Ansatz für eine weitere Auswahl:

Nach Stakeholder

Ja, genau, nach Stakeholder. Es soll weitergehen, es soll mehr Zeit geben, mehr Budget, mehr Ressourcen? Dann hilft es, wenn man nett zu dem ist der das Geld in der Tasche hat. Du kriegst Dein Feature, ich meine Ressourcen, beide sind glücklich. Ein Kuhhandel? Ja, ist es. Opportunistisch? Vermutlich auch. Aber hey, so ist es nun mal in der Welt. Ein grosses Geben und Nehmen. Allerdings, selbst wenn wir das machen bleiben oft noch Anforderungen übrig bei denen man nicht sicher sein kann für wen sie mal wichtig sein könnten. Im Zweifel behalten? Ach was, auch da lässt sich noch reduzieren, und zwar so:

(Festhalten:) Nach Zufall

Wait, what? Nach Zufall. Jetzt kann man losen, Glücksrad drehen, blind mit dem Finger auf etwas zeigen oder einfach jede vierte verbliebene Anforderung löschen. Alles ist erlaubt. Aberwitzig? Mitnichten! Schauen wir nochmal auf die letzten Auswahlrunden. In denen haben wir nicht nur entschieden was nach unten priorisiert wird, wir haben damit gleichzeitig auch nach oben priorisiert, das eine gehört untrennbar zum anderen. Und was in keinem dieser Durchgänge für wichtig genug befunden wurde, das kann eigentlich nur verzichtbar sein. Und deshalb kann die Zufalls-Auswahl so lange weitergehen bis das Backlog auf eine vernünftige Größe eingedampft ist. Nur zu.

AberAber: Was, wenn irgendwas davon doch wichtig war?

Ja, was dann? Was wenn wir versehentlich etwas rausgeworfen haben was wir doch ganz dringend brauchen? Ganz einfach - sobald das auffällt kommt es als neue Anforderung wieder rein. Und wenn auf diesem Weg so lange Anforderungen wieder zurückkommen bis das Backlog erneut ausufert? Na dann geht das Ausmisten eben von vorne los.

Montag, 17. Oktober 2016

Backlogs ausmisten!

Bild: Wikimedia Commons / Jorge Royan - CC BY-SA 3.0
Ein mitgenommenes Thema vom ersten Lean Coffee für Product Owner und Produktmanager, der letzten Freitag stattgefunden hat: wie kann man es schaffen, dass ein Backlog einen überschaubaren Umfang behält und nicht ausufert? Die einfache Antwort - regelmässig ausmisten. Von Zeit zu Zeit ist es sinnvoll sich in grossem Ausmass von bisher gesammelten Anforderungen zu trennen, selbst, bzw. gerade von solchen die noch nicht umgesetzt wurden. Und dafür gibt es auch Gründe:

Zu große Backlogs sind zu unübersichtlich

Zugegeben, eine Binsenweisheit, aber eine mit Folgen. Bei einer drei- oder vierstelligen Anzahl von Einträgen ist es nicht mehr möglich alle Inhalte im Kopf zu behalten, Duplikate, Redundanzen oder Überschneidungen fallen dann nicht mehr auf. Man kann zwar versuchen durch Kategorien, Schlagworte oder Verlinkungen die Übersicht zu behalten, allerdings ist das mit zusätzlicher Arbeit verbunden, die auch erstmal erledigt werden muss. Das bringt uns zum nächsten Punkt:

Zu große Backlogs erfordern einen unverhältnismässigen Pflegeaufwand

Ich habe Menschen gesehen, die in Vollzeit nichts anderes gemacht haben als alte User Stories und Bugs zu aktualisieren. Immer wieder überprüften sie ob das was sich in ihnen befand nicht bereits durch andere Anforderungen umgesetzt wurde, noch gewollt war oder seine Priorität geändert hatte. Nur in den seltensten Fällen führte das dazu, dass irgendetwas aus dem Backlog herausgenommen werden konnte, stattdessen kam es immer und immer wieder zurück (es war nicht ohne Grund so niedrig priorisiert). Eine unglaubliche Verschwendung von Zeit und Geld.

Zu große Backlogs veralten (auch wenn sie gepflegt werden)

Egal wieviel Mühe man sich gibt: zu große Backlogs werden immer Anforderungen enthalten die obsolet oder bereits umgesetzt sind. Alleine die Länge der Aktualisierungszyklen sorgt dafür, denn die können sehr schnell Wochen oder sogar Monate in Anspruch nehmen. Selbst wenn sie gerade erst durchlaufen wurden ist das aber keine Garantie dafür, dass alles aktuell ist. Grund dafür sind die oben erwähnte Unübersichtlichkeit und eine "im Zweifel behalten"-Einstellung die immer wieder anzutreffen ist.

Zu große Backlogs führen zu unrealistischen Erwartungshaltungen und Enttäuschungen


Für viele Stakeholder ist die Angelegenheit klar: ist meine Anforderung noch im Backlog? Klasse, dann ist es ja nur eine Frage der Zeit bis sie umgesetzt wird. Dass unwichtige Dinge immer wieder nach unten priorisiert und von neuen Anforderungen "überholt" werden wird dabei nicht bedacht. Am Ende führt das zu falschen Erwarungen, enttäuschten Hoffnungen und Frustrationen. Die entladen sich dann irgendwann. Apropos:

Zu große Backlogs führen zu Konflikten

"Meine User Story ist jetzt zum fünften mal nach hinten geschoben worden. Jetzt bin ich auch mal dran, wenn nicht eskaliere ich das!" Aussagen wie diese sind die fast schon zwangsläufige Folge zu großer Backlogs. Nicht nur weil ein Stakeholder das Gefühl hat, dass ihm falsche Hoffnungen gemacht wurden, sondern auch aus handfesten Gründen: es ist in vielen Unternehmen "best" practice, dass Boni und Jahresziele an die Umsetzung von Anforderungen geknüpft werden, und wenn die nicht erreicht werden stehen unangenehme Jahresgespräche bevor. In solchen Situationen ist es klar, dass die Betroffenen schnell in Krawallstimmung sind.

Also her mit der Heckenschere

Genug der guten Gründe und ans Werk. Her mit dem Backlog und raus mit allem was nicht wirklich nötig ist. Nur - wie? Wie wird entschieden was bleibt und was nicht? Nun, das wird ein Thema für einen eigenen Artikel.

Donnerstag, 13. Oktober 2016

Hierarchiefreie Kommunikation

Auch eine interessante Change Management-Geschichte: Der Stahlhändler Klöckner versucht Informationen schneller und effizienter im eigenen Unternehmen zu verteilen indem er "Hierarchiefreie Kommunikation" einführt, basierend auf einem firmeninternen sozialen Netzwerk. Hierarchiefrei bedeutet in diesem Fall horizontal, also durch direkte Ansprache des entsprechenden Kollegen und ohne Umweg über die jeweiligen Vorgesetzten.



Für viele Beschäftigte der Startup-Branchen, des Mittelstandes oder der IT-Industrie mag es zwar selbstverständlich sein direkt mit demjenigen zu reden für den man ein Anliegen hat, in Großunternehmen ist das allerdings häufig unüblich. Hier herrscht an vielen Stellen noch immer der Dienstweg, der erfordert, dass alle teamübergreifende Kommunikation über die jeweiligen Teamleiter und ggf. Unterabteilungs- und Abteilungsleiter zu erfolgen hat. Ein Vorgehen wie das von Klöckner kann in solchen Fällen dazu führen, dass sich Informationsverteilungen deutlich beschleunigen (in einem anderen Unternehmen habe ich miterlebt, dass bei einzelnen Vorgängen Monate (!) an Zeit eingespart werden konnten). Insofern eine bemerkenswerte Entwicklung.

Montag, 10. Oktober 2016

Certified Scrum Professional

Seit letzter Woche bin ich dem (organisierten) agilen Olymp eine Stufe näher. Ich habe die Ruhephase zwischen zwei Aufträgen genutzt um mich bei der Scrum Alliance als Certified Scrum Professional (CSP) zertifizieren zu lassen, wodurch ich jetzt in der Verbandshierarchie eine Stufe oberhalb der Certified Scrum Master (CSM) oder Certified Scrum Product Owner (CSPO) stehe.

Überraschend finde ich, dass der CSP verhältnismässig einfach und billig zu bekommen ist. Man zahlt 250 $ und benötigt nur drei Jahre nachweisbare Berufserfahrung im Scrum-Umfeld sowie 70 so genannte "Education Units", die aber recht banal zu bekommen sind: ein paar Fachartikel, ab und zu bei einer User Group wie z.B. dem Bonner Scrumtisch vorbeischauen und das war es. Keine Prüfung, kein Lehrgang, keine Präsenzveranstaltung - im Grunde reicht es einfach seinen normalen Job zu machen und sich ab und zu in der Community sehen zu lassen. Angesichts dessen finde ich es erstaunlich wie wenige CSPs bisher vergeben wurden.

Im Zertifizierungs-Verzeichnis der Scrum Alliance findet man im Moment 384.800 CSMs, immerhin 84.200 CSPOs aber gerade einmal 4.600 CSPs. Lediglich ein Prozent (!) der zertifizierten Scrum Master und Product Owner nimmt die nächste Stufe, die anderen bleiben da wo sie sind. Das ist dürftig, vor allem wenn man bedenkt, dass viele große Unternehmen permanent nach irgendwelchen Zertifizierungen suchen mit denen sie ihre Weiterqualifizierungsquoten für ihre Belegschaft erfüllen können. Was könnte also der Grund für diese niedrige Zahl sein?

Eine gute Begründung hat mir ein in einem Konzern arbeitender Freund gegeben. "Klar, für Dich ist das einfach" meinte er, "aber Du machst ja auch was in dem Bereich. Für die Leute bei uns ist das viel schwerer, die sind ja nur zertifiziert." Hinter diesem "nur zertifiziert" dürfte tatsächlich ein wesentlicher Teil der Begründung liegen: bei einem sehr großen Teil der CSMs und CSPOs handelt es sich um ganz normale Team-, Abteilungs- und Bereichsleiter, die irgendwann mal aus irgendeinem Grund (siehe letzter Abschnitt) auf eine zweitägige Schulung geschickt wurden, danach aber einfach so weitergearbeitet haben wie bisher (das entspricht auch meinem Eindruck aus vielen Unternehmen). Denen dürfte bereits der Nachweis von drei Jahren Scrum-Erfahrung schwerfallen, und ohne die sind auch Fachartikel und Community-Engagement nur schwer vorstellbar.

Weiter gedacht würde das bedeuten, dass es sich bei der organisierten Scrum-Community um einen Scheinriesen handelt. Einer großen Gruppe Zertifikatsinhaber stehen nur wenige gegenüber die auch wirklich nach dieser Methode arbeiten. Schlecht für den State of Scrum, gut für mich als käuflicher Scrum Master und Scrum Coach. Vor allem da jetzt der CSP-Badge auf meinem CV meine Kompetenz noch strahlender zur Geltung bringt als ohnehin schon.

Donnerstag, 6. Oktober 2016

Wie technikfern darf ein Scrum Master sein?

Bild: Public Domain Files/US Department of Energy - Public Domain
Anscheinend hat das Thema gerade Konjunktur, seit ca. zwei Wochen bekomme ich gefühlt jeden zweiten Tag von irgendjemandem erzählt, dass er ohne IT-Kenntnisse Scrum Master oder sogar Scrum Coach sein kann, bzw. werden möchte. Nun sehe ich an mir selbst (Geisteswissenschaftler), dass das geht und auch durchaus annehmbar funktioniert. Sowohl ich als auch meine Teams sind in den letzten Jahren damit erfolgreich gewesen. Aber:

Selbst wenn ein Quereinstieg möglich ist würde ich sagen, dass ein komplett technikferner Scrum Master auf Dauer in Probleme hineinlaufen wird. Das beginnt schon bei einer der Kernaufgaben, dem Beseitigen von Impediments: wenn die Entwicklerrechner zu wenig RAM haben, wenn es zu wenige Testumgebungen gibt oder wenn die Teams mit Feature Branches in eine Merge-Hölle geraten, dann muss man das nicht selbst beheben können, man sollte aber verstehen können worum es geht, damit klar ist wie eine Lösung angestoßen werden kann. Auch bei Microservices, festen und dynamischen IDs, Code Covarage, TDD und vielem mehr ist ein gewisses Verständnis mehr als hilfreich. Allerdings:

Die Bereitschaft sich in diese Bereiche einzudenken und einzulernen ist leider nicht bei jedem gleichermassen vorhanden. "Ich glaube, ich brauche das nicht. Ich coache ja nur deren soziale und methodische Skills" durfte ich mir in einem Fall gerade erst anhören. Und das ist gefährlich. Der schönste Prozess und das beste Arbeitsklima bringen nichts, wenn die Anwendung so verschachtelt gebaut und so schlecht durch Tests abgesichert ist, dass jede User Story durch eine mehrwöchige Analyse- und Bugfixing-Phase muss bevor sie auf Produktion kann. Deshalb:

Kein Scrum Master muss Entwickler sein (und ganz nebenbei - selbst wenn man als einer angefangen hat kann man erstaunlich schnell aus der Übung kommen). Wenn man aber nicht in unkalkulierbare Risiken hineinlaufen will sollte man Technikferne als relativen und nicht als absoluten Begriff begreifen.