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