Freitag, 29. April 2016

Kommentierte Links (XII)

Grafik: Pixabay / Geralt - Lizenz

  • Michael Mahlberg: DevOps - Karl Marx to the rescue?

    • Und ich dachte schon, ich wäre der einzige, der über marxistische Ansätze in der IT schreibt. Wenn ich Michael Mahlberg mal wieder begegnen sollte bekommt er auf jeden Fall Kudos von mir. Darüber hinaus hat er natürlich recht - in der Software-Entwicklung müssen die Produktionsmittel (v.a. die Computer und deren Adminrechte) in der Hand der Arbeiter Programmierer sein. Beispiele wie die von ihm genannten habe ich auch schon erleben müssen: entfesselte Großkapitalisten Konzernabteilungen machten durch überbordende Bürokratie jedes Software-Update und jede Installation eines neues Tools zu einem wochenlangen Formular-Krieg. Das dauerte, machte alles teuer und vertrieb die dringend benötigten Fachkräfte aus der Firma. Aber ganz unabhängig davon - ich müsste mal darüber schreiben, ob Shared Code Ownership vielleicht ein bisschen kommunistisch ist. Nur so eine Idee.

  • Tim Kanning: Jetzt kommen die Lego-Banken

    • Dass agile Software-Entwicklung nicht nur das Projektmanagement sondern auch die Struktur der Software selbst umfasst wird viel zu oft vergessen. Tim Kannig arbeitet das am Beispiel einiger Fintechs sehr schön heraus. Dort wurde nicht nur erkannt, dass ein modularer Aufbau den Austausch und Umbau einzelner Bestandteile stark vereinfacht - dieses Baukasten-Prinzip ermöglicht es sogar, die Module verschiedener Startups so zu kombinieren, dass am Ende ein vollwertiges "virtuelles Finanzhaus" steht. Und diese Bündelung ermöglicht nicht nur Online-Banking sondern auch Auslandsüberweisungen und sogar das deutschlandweite Abheben von Bargeld an einem ebenso schrägen wie naheliegenden Ort: den Supermarktkassen. Ich kenne einige Bank-Manager die das gerade sehr nervös macht. Zurecht.

  • Jason Little: Successful Agile Transformation through Community Building (Edit: Link ist mittlerweile tot)

    Jason Little bringt es zunächst auf den Punkt wie große Organisatoren an der Einführung agiler Methoden scheitern: Irgendjemand in der bereits bestehenden hierarchischen Struktur bekommt die Verantwortung übertragen, versucht einen Rollout nach dem "bisher bewährten Vorgehen", scheitert, versucht es nochmal, scheitert nochmal, gibt auf und führt stattdessen Cargo Cult ein. Um das zu vermeiden empfiehlt Little eine neue Art der Einführung: statt zentralisierter Verantwortung wird eine agile Community gegründet, die den Änderungsprozess dezentral vorantreibt. Fördern kann man diese durch die Beschränkung von Regeln auf das absolute Minimum, das Zulassen von Experimenten, die Einführung informeller Meeting-Formate (z.B. Lean Coffees) und regelmässiger Retrospektiven, das Zurückschneiden der Planung zum Jahresbeginn und die Vernetzung mit anderen agilen Organisationen. Eine Erfolgsgarantie ist das zwar nicht, dafür steigt aber die Wahrscheinlichkeit, dass Agilität wirklich entsteht und nicht nur simuliert wird, drastisch an.

  • Charles Edge: From Dungeon Master to Scrum Master - 15 Software Development Lessons from Dungeons and Dragons

    • Die IT ist eben doch ein Tummelplatz für sympathische Nerds. Über diesen Allgemeinplatz hinaus geht dieser Artikel von Charles Edge aber auf einen wichtigen Punkt ein: da man als Scrum Master seinen Job ohne Social Skills nicht machen kann, und da diese Skills in Studium oder Ausbildung nicht vermittelt werden, muss man sie irgendwoher sonst bekommen. Rollenspiele wären zwar nicht die erste Option die mir in diesem Zusammenhang einfallen würde, aber wenn es funktioniert - warum nicht? Und wenn man seine Auflistung sieht muss man ihm schon irgendwie recht geben. Es gibt definitiv Einiges was man dort lernen kann.

  • Katrina the Tester: What problems do we have with our test automation?

    • Ähnliche Situationen wie die hier beschriebene habe ich bei verschiedenen Kunden erleben dürfen. Automatisierte Testsuites können schnell zu komplex und schwerfällig werden, benötigen dann mitunter Stunden für die Ausführung, sind nur mit Mühe aktuell zu halten und sind nur noch eingeschränkt für Absicherungen häufiger Merges in den Master Branch nutzbar. Die Agilität der Softwareentwicklung geht dann zurück. An einem konkreten Beispiel aus ihrer Arbeit beschreibt Katrina Clokie Probleme, Lösungsansätze und Lerneffekte. Ein eher technischer aber trotzdem wichtiger und interessanter Blickwinkel.

Montag, 25. April 2016

Agile Meetups und (Un)Konferenzen in NRW

Grafik: Landesverwaltung NRW
Eine der Sessions des Agile Ruhr Camp beschäftigte sich am letzten Wochenende mit der Frage, wo in der Gegend es überall agile Meetups und Veranstaltungen gibt, auf denen man sich zu den Themen Agile, Lean, Scrum, etc. austauschen kann. Da ich mittlerweile ein bisschen herumgekommen bin habe ich versucht alles zusammenzutragen was ich kenne, wobei einiges zusammengekommen ist. Hier ist die Liste, ohne Anspruch auf Vollständigkeit (Organisation erfolgt großteils über Xing, ggf. ist zum Ansehen ein Account erforderlich):

Meetups und Scrumtische

Aachen

Bonn

Düsseldorf

Ruhrgebiet

  • Agiler Stammtisch Ruhr (Xing) - monatlich
  • Scrumtisch Essen (Xing) - monatlich 

Köln

(Un)Konferenzen

Essen

Köln


Was noch fehlt ist das Meetup im Münsterland, um das es in der Session eigentlich ging. Das ist aber noch nicht im Internet zu finden.

Donnerstag, 21. April 2016

Organisatorische Schulden

Bild: Flickr/Rachel Doherty - CC BY 2.0
Vor einigen Jahren befand sich meine Firma in Gesprächen mit einem Startup, dem wir ein Testkonzept für seine Software erstellen sollten. Bis zu diesem Zeitpunk hatte es dort nur Unit Tests gegeben, wir hätten dort Integrationstests eingeführt, vielleicht wären auch Lasttests dazugekommen. Hätten, wären. Kurz vor einem wichtigen Termin wurde dieser abgesagt, da das gesamte Entwicklungsteam dieser Firma bei ihrem größten Kunden Hotfixing machen musste. Der Ersatztermin entfiehl aus dem selben Grund, zu einem dritten kam es nicht mehr. Ein Jahr später hörte ich, dass die Situation unverändert gleich war - noch immer bestimmten Hotfixes das Tagesgeschäft. Bei der Gelegenheit wurde mir beiläufig der wahre Grund für das geplatzte Geschäft mitgeteilt - es gab dort einfach niemanden, der sich für das Thema Qualitätssicherung verantwortlich fühlte. Die Entwickler interessierten sich nur für ihre eigenen Komponenten, einen QA- oder Testkoordinator gab es nicht, das Management war mit Auftrags- und Personalbeschaffung ausgelastet. Das hoffnungsvolle Startup erstickte gerade an etwas, dessen Existenz ihm gar nicht bewusst war: Organisatorischer Schuld.

Die organisatorische Schuld ist gewissermassen der unbekannte Zwilling der technischen Schuld. Unter der versteht man den Mehraufwand, den man für Reparaturen und Instandhaltung schlecht geschriebener Software aufbringen muss. Organisatorische Schuld ist dementsprechend der Mehraufwand der sich aus einer unzureichenden Organisationsstruktur ergibt - im oben genannten Fall aus dem Fehlen einer Person die sich für das Thema der übergreifenden Software-Qualität verantwortlich gefühlt hätte. Genau wie im Fall der technischen Schuld erscheint das Ganze zum Zeitpunkt des "Schulden Aufnehmens" auch oft unproblematisch, vielleicht sogar rational. Im Normalfall ist das Schulden aufnehmende Unternehmen noch klein und/oder jung und andere Probleme sind dringender, so dass die Weiterentwicklung der eigenen Strukturen auf "später" verschoben wird. Später sind dann andere Probleme dringender und noch später wieder andere, so dass es niemals zu einer Lösung kommt. Besonders perfide: viele der später auftretenden Probleme wären niemals entstanden wenn die Organisation von Anfang an besser aufgestellt gewesen wäre, ein Beispiel dafür sind die oben genannten Hotfix-Phasen. Letztendlich entsteht ein Teufelskreis - organisatorische Defizite führen zu Mehraufwänden wegen denen die Organisation nicht weiterentwickelt wird, was wieder zu Mehraufwänden führt. Und so weiter.

Was man an dieser Stelle bedenken sollte ist, dass die Existenz organisatorischer Schulden keineswegs notwendigerweise ein Fehler dessen ist, der sie aufgenommen hat. Möglicherweise stehen handfeste Gründe dahinter. Um ein letztes mal das Beispiel des oben genannten Startups anzuführen - vielleicht war am Anfang einfach kein Geld für jemanden mit Test- und QA-Know How da? Der Fehler dürfte eher in mangelnder oder fehlender Agilität liegen: bei funktionierendem Inspect & Adapt wäre zum einen das organisatorische Defizit rechtzeitig aufgefallen, zum anderen wäre auch klar geworden, wann man dieses Problem am besten (oder spätestens) hätte lösen müssen. Nicht, dass es später nicht mehr ginge. Es wird dann nur sehr, sehr teuer.

Montag, 18. April 2016

Agile is (not) dead

Ein weiterer Vortrag aus der Reihe: "Agile ist tot", diesesmal gehalten von Dave Thomas, einem der Verfasser des Agilen Manifests. Der zentrale Punkt - die Methode ist gut, aber den falschen Leuten in die Hände gefallen, die sie von ihren ursprünglichen Ideen entfremdet haben.



Ich habe zu dem Thema zwar eine differenzierte und zum Teil andere Meinung (siehe u.a. hier und hier), könnte aber trotzdem das meiste was er sagt unterschreiben. Besonders gefällt mir eine Kurzdefinition von Agilität, die er zwischendurch an die Wand wirft:

Agilität

Was sollte man tun?

  • Finde den ist-Stand heraus
  • Bewege Dich in kleinen Schritten Richtung Ziel
  • Passe Dein Vorgehen ständig an, basierend auf dem was Du lernst
  • Wiederhole die letzten drei Schritte

Wie sollte man es tun?

  • Wenn Du die Wahl zwischen zwei Alternativen hast, die ein vergleichbar wertvolles Ergebnis liefern, entscheide Dich für die, die es in Zukunft einfacher machen wird Anpassungen vorzunehmen
Einfach, nachvollziehbar, zielführend. Man fragt sich, warum nicht jeder so vorgeht.

Donnerstag, 14. April 2016

Steuerung langfristiger Vorhaben mit Kanban-Boards

Bild: Unsplah / Sebastien Bonneval - Lizenz
Im Gespräch mit einem Kollegen aus meiner Firma ergab sich die folgende Aufgabenstellung: eine Fachabteilung eines Kunden möchte agiler werden und in diesem Zusammenhang ihren Arbeitsfluss auf einem Kanban-Board visualisieren. Die Besonderheit dabei ist, dass darauf neben kurzfristigen auch langfristige Vorhaben abgebildet werden sollen, deren Erledigung Monate dauern kann. Der normalerweise in Scrum verwendete Board-Typ (To do/In Progress/Done) fällt damit weg, da die unterschiedlichen Durchlaufzeiten es sehr schwer überprüfbar machen würden, ob die Arbeit wie geplant vorangeht oder stillsteht. Überhaupt wäre eine Organisation nach Scrum schwierig, da die Begrenzung der Sprintlänge auf maximal vier Wochen nicht einzuhalten wäre. Eine alternative Vorgehensweise wäre die Darstellung als Kanban Workflow, etwa wie in dieser Form:


In diesem Vorgehensmodell wird der To do/In Progress/Done-Ablauf in mehreren Phasen wiederholt, wobei diese von links nach rechts immer kürzer werden. Die langfristige Vorarbeit könnte zum Beispiel die bereits im Vorjahr stattfindende Budgetplanung sein, die "kurz"fristige Vorarbeit wäre die im Vorquartal stattfindende Kommunikations- oder Schulungsphase, die Umsetzung wäre dann die eigentliche Arbeit, etwa das Rollout einer neuen Software oder das Rebranding einer Dienstleistung. Abhängig davon wie komplex und unberechenbar dieser Abschnitt ist könnte man in ihm sogar tatsächlich Scrum einsetzen, wobei es in diesem Fall sinnvoll wäre ihn auf einem zweiten Board mit höherem Detaillierungsgrad zu spiegeln. Als letztes ließe sich sogar ein Lessons Learned-Prozess mit abbilden, dessen Ergebnisse dann wieder auf der linken Seite ins Backlog einfließen könnten.

Natürlich ist dieser Entwurf zunächst nur einer auf relativ hohem Abstraktionslevel. Einige Aspekte fehlen noch und müssten ausgearbeitet werden, etwa die Visualisierung der Zuordnung von Aufgaben zu Personen oder Teams, oder auch die Kennzeichnung von Aufgaben die zu bestimmten Zeitpunkten erledigt sein müssen. Er ist auch nicht universell anwendbar, in manchen Fällen werden andere Vorgehensweisen mehr Sinn machen, beispielsweise die Benutzung von Story Maps oder anders konfigurierten Boards. In vielen Fällen wäre er aber ein erheblicher Beitrag zu mehr Transparenz und Übersicht - und mit Sicherheit wesentlich besser benutzbar als die immer noch weit verbreiteten Excel- oder MS Project-Monstrositäten.

Montag, 11. April 2016

Verwechselungsgefahr: Motivierte und frustrierte Entwickler

Bild: PDPics - CC0 1.0

Dass man in einem agilen Unternehmen Entscheidungen nur schwer gegen den Willen der Software-Entwickler umsetzen kann dürfte eine Binsenweisheit sein. In der Realität wird aber genau das immer wieder versucht, was oft daran liegt, dass dem Management der Widerstand in den Entwicklungsteams (oder das Ausmass dieses Widerstandes) gar nicht bewusst ist. Die Geschäftsführer/Abteilungsleiter/Bereichsleiter sind in solchen Fällen fest davon überzeugt, ihre Mitarbeiter eingebunden und mitgenommen zu haben und glauben auch, dass diese sich bereitwillig an den Entscheidungsprozessen beteiligt haben und deren Ergebnisse annehmen und akzeptieren. Diese Vorgesetzten fallen mitunter aus allen Wolken wenn ihnen irgendwann gesagt wird, dass ihre Teams sich in Wirklichkeit schon lange in innere Emigration und Entwickler-Zynismus ("Ich mache hier nur noch das was man mir sagt") verabschiedet haben.

Um zu erklären wie es zu diesen stark von der Realität abweichenden Einschätzungen kommt, kann man die Entwickler in zwei Personas einteilen: die Motivierten (die, die man gerne hätte, bzw. glaubt zu haben) und die Frustrierten (die die man oft in Wirklichkeit hat). Die einen fühlen sich wertgeschätzt, beteiligen sich und packen mit an, die anderen fühlen sich bevormundet, lehnen Änderungen ab und versuchen Dinge "auszusitzen".  Das Problem bei diesen beiden Typen: In Bezug auf die Akzeptanz von Entscheidungen und die Beteiligung an Entscheidungsfindungen unterscheiden sie sich zwar erheblich, von oben, bzw. von aussen kann man das aber nicht immer gut erkennen. Aus diesem Blickwinkel kann es sogar sein, dass sich überhaupt keine Unterschiede wahrnehmen lassen. Werfen wir einen genaueren Blick auf die beiden:
Man sieht - beide tun durchaus ähnliche Dinge, allerdings aus einer völlig unterschiedlichen Motivation heraus. Der Motivierte beteiligt sich an Change-Prozessen weil er einen Beitrag zur Verbesserung seines Unternehmens leisten will, der Frustrierte tut es um Schadensbegrenzung zu betreiben. Der Motivierte sieht in den Veränderungsergebnissen Leitlinien für sein Handeln, der Frustrierte tut zwar so, sieht in ihnen aber eher eine Liste der Punkte die er nicht verhindern konnte und um die er jetzt herumarbeiten muss. Der Motivierte stimmt Vereinbarungen zu weil er sie für sinnvoll hält, der Frustrierte tut es nur weil er glaubt, dass er sonst so lange in Meetings mit dem Management muss bis er seine Ablehnung aufgibt. Wenn man jetzt versucht, das Ganze aus der von aussen kommenden Position des Managements zu sehen, wird das Problem offensichtlich: beide wirken gleich. Beide beteiligen sich, beide stimmen den Ergebnissen zu, beide melden keine Bedenken an. Aus Management-Sicht sind beides motivierte Mitarbeiter. Die Fehlwahrnehmung ist entstanden.

Interessant ist im Folgenden die Reaktion des Managements auf eine Aufdeckung dieser Fehlwahrnehmung. Bei Variante A, in der frustrierte Entwickler fälschlicherweise für motiviert gehalten wurden, ist es sehr häufig Verleugnung ("Das kann nicht sein, wenn die so denken würden, dann würden die es mir sagen"). Das ist in der Regel ein Indikator dafür, dass der Manager an seiner Selbstwahrnehmung arbeiten sollte - er muss erkennen, dass er nicht der Freund und/oder Vertraute seiner Mitarbeiter ist für den er sich selber gehalten hat, sondern dass er von ihnen mit Distanz betrachtet wird und nur vorsichtig gefiltertes Feedback erhält. Ebenfalls häufig ist Relativierung, etwa indem behauptet wird, die Mitarbeiterhätten nicht die notwendigen Informationen und das notwendige Verständnis, weshalb sie die Situation gar nicht richtig beurteilen könnten. Auch das ist aber in der Regel ein Indikator für Management-Antipattern, etwa für eine verfehlte Informationspolitik oder für ein merkwürdiges Menschenbild.

Auch eine Variante B existiert übrigens, die sogar besonders tragisch ist: in ihr sind die Entwickler motiviert und bringen sich ein, dass Management geht aber davon aus, dass das nur die Fassade für ein frustrationsgetriebenes Aussitzen und ins Leere laufen lassen sein kann. Da sich das in misstrauischem und kontrollierendem Verhalten niederschlägt ist es eine selbsterfüllende Prophezeihung - es ist nur eine Frage der Zeit bis die Teams tatsächlich frustriert sind.

Zuletzt ist natürlich auch eine positive Wendung möglich: das Management realisiert seine Fehlwahrnehmung, erkennt das Problem (auch) bei sich und arbeitet an einer Anpassung und Verbesserung des eigenen Verhaltens. Das erfordert allerdings zwei der größten Kuststücke die eine Führungsposition vollbringen kann - das Eingeständnis sich geirrt zu haben und den Sprung über den eigenen Schatten. Dafür ist bei Gelingen der Applaus sicher.

Donnerstag, 7. April 2016

Wohin mit dem Kanban Board?

Ein Klassiker unter den Ausreden "warum Agil bei uns nicht geht": Es dürfen keine Post-Its an den Wänden angebracht werden, weil der Putz/die Tapeten so empfindlich sind.1 Vor kurzem erst habe ich mir das von einer jungen Projektmanagerin anhören dürfen, der ich gleich eine Wette angeboten habe - alleine in ihrem Lieblings-Social Media-Service (Instagram) würde ich genug Beispiele dafür finden, wie man diese Beschränkung umgehen kann. Hier sind einige Ergebnisse:

Auf ein Fenster

Auf Stellwände

Auf einen Schrank

Auf ein Whiteboard

Auf einen Spiegel

Auf ein Flipchart

Auf eine Korkwand

Auf einen Kalender

Auf den Schreibtisch

Auf ein mitnehmbares laminiertes Blatt


Übrigens: der Dame sind dann sofort ganz viele andere Gründe eingefallen warum Scrum dort nicht funktioniert. Wer nicht will, der will nicht.


1Nur zur Klarstellung: natürlich geht Agilität auch ganz ohne physisches Board, es gibt aber gute Gründe eines zu haben.