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.

Montag, 4. April 2016

The Agile Bookshelf: Vom Kriege

Bild: Wikimedia Commons/Vernet/Swebach - Public Domain
Agilität mag (auf Organisationslehre bezogen) ein relativ neuer Begriff sein, seine Vorformen reichen allerdings deutlich weiter zurück. Zu den bedeutendsten Vordenkern zählt dabei der preußisch-russische General Carl Philipp Gottlieb von Clausewitz (1780 - 1831), der in seinem Hauptwerk Vom Kriege bereits wichtige Aspekte des heutigen agilen Projektmanagements behandelte. Hintergrund waren allerdings noch nicht die Organisations- oder Produktentwicklung sondern die Kriegsführung und der Versuch diese beherrschbar zu machen. Neben verschiedenen militärspezifischen Begriffen sind dabei vor allem zwei zentrale Problemstellungen von Bedeutung, die unter anderen Namen bis heute weiterbestehen: die Friktionen und der Nebel des Krieges.

Friktionen
Unter Friktionen (Brüchen) verstand Clausewitz jegliche Abweichungen der Realität vom ursprünglich gedachten Plan, die dessen Durchführung erschwerten oder unmöglich machten.
So stimmt sich im Kriege durch den Einfluß unzähliger kleiner Umstände, die auf dem Papier nie gehörig in Betrachtung kommen können, alles herab, und man bleibt weit hinter dem Ziel. Diese entsetzliche Friktion, die sich nicht wie in der Mechanik auf wenig Punkte konzentrieren läßt, ist deswegen überall im Kontakt mit dem Zufall und bringt dann Erscheinungen hervor, die sich gar nicht berechnen lassen.
Clausewitz, vom Kriege
Wichtig für das Verständnis dieses Konzepts ist es, dass es sich bei Friktionen nicht um wenige große, sondern um viele kleine Ereignisse handelt, etwa um Verkehrsunfälle durch die einzelne Verbände plötzlich unbeweglich werden oder um lokale Wetterumschwünge durch die das Schießpulver feucht und unbrauchbar wird. Durch diese Vielzahl und Kleinteiligkeit wird nicht nur die Planung erschwert, auch Korrekturmaßnahmen sind schwierig, was mit dem zweiten großen Problem zusammenhängt:

Der Nebel des Krieges
Dieser etwas ungewöhnliche Begriff ließe sich am ehesten mit Kontrollverlust übersetzen: Der Kriegsverlauf ist weder überall gleichzeitig einzusehen noch überall gleichzeitig zu kontrollieren.
Der Krieg ist das Gebiet der Ungewißheit; drei Vierteile derjenigen Dinge, worauf das Handeln im Kriege gebaut wird, liegen im Nebel einer mehr oder weniger großen Ungewißheit. [...] Diese Schwierigkeit ist nicht unbedeutend bei den ersten Entwürfen, die auf dem Zimmer und noch außer der eigentlichen Kriegssphäre gemacht werden, aber unendlich größer ist sie da, wo im Getümmel des Krieges selbst eine Nachricht die andere drängt.
Clausewitz, vom Kriege
Ursache für diesen "Nebel" sind neben der fehlenden Einsehbarkeit und Kontrollierbarkeit vor allem zwei weitere Faktoren: die Volatilität (ist die Situation heute noch immer vergleichbar mit der von gestern?) und die Gleichzeitigkeit (alle Truppenteile geben ständig neue Zwischenstände durch, die sich in Summe kaum noch überblicken lassen).

Die zentrale Erkenntnis von Clausewitz war, dass durch die Friktionen und den Nebel des Krieges sämtliche Pläne bereits nach kurzer Zeit nicht mehr zu gebrauchen sind und angepasst werden müssen. Diese Anpassungen waren für ihn allerdings mit Risiken verbunden: eine umfangreiche Neuplanung wäre zu langwierig umd zum Zeitpunkt ihrer Fertigstellung bereits wieder überholt. Und zu häufige und nicht aufeinander abgestimmte Anpassungen können in Unordnung und Chaos führen. Um dem entgegenzuwirken setzte er auf zwei Eigenschaften, die er bei jedem Anführer für zwingend erforderlich hielt - Geistesgegenwart und Beharrlichkeit.

Geistesgegenwart
Für Clausewitz war Geistesgegenwart die auf Intelligenz und Entschlossenheit beruhende Fähigkeit, geänderte Rahmenbedingungen schnell zu erkennen und auf sie zu reagieren.
Bei dem coup d'oeil [dem Verstand, der auch in dieser gesteigerten Dunkelheit nicht ohne einige Spuren des inneren Lichts ist] und der Entschlossenheit liegt es uns ganz nahe, von der damit verwandten Geistesgegenwart zu reden, die in einem Gebiete des Unerwarteten, wie der Krieg ist, eine große Rolle spielen muß; denn sie ist ja nichts als eine gesteigerte Besiegung des Unerwarteten.
Clausewitz, vom Kriege
In heutigem Verständnis ist das, was Clausewitz unter Geistesgegenwart verstanden hat, im Wesentlichen identisch mit Agilität. Bemerkenswert ist an dieser Stelle auch, dass er sein Geistesgegenwarts-Konzept bereits als empirisch und datengetrieben beschrieb. Oder mit seinen Worten: "so wird das wirklich Vorhandene die Daten abgeben für das Unbekannte, zu Erwartende, was gefunden werden soll." Damit war er wesentlich fortschrittlicher als andere Anführer seiner Zeit, die sich noch weitgehend von "Genie" oder "Intuition" leiten ließen.

Beharrlichkeit
Der Beharrlichkeits-Begriff von Clausewitz enthält die modernen Begriffe Fokus und Vision. Durch Beharrlichkeit soll verhindert werden, dass Anpassungen beliebig vorgenommen werden.
Im Kriege mehr als irgendwo sonst in der Welt kommen die Dinge anders, als man sich es gedacht hat, und sehen in der Nähe anders aus als in der Entfernung. [...] Wer diesen Eindrücken nachgeben wollte, würde keine seiner Unternehmungen durchführen, und darum ist die Beharrlichkeit in dem gefaßten Vorsatz, so lange nicht die entschiedensten Gründe dagegen eintreten, ein sehr notwendiges Gegengewicht.
Clausewitz, vom Kriege
Wichtig an dieser Stelle ist der Einschub im letzten Satz, "so lange nicht die entschiedensten Gründe dagegen eintreten ...". Durch ihn grenzt er die Beharrlichkeit ab vom Methodismus (auch diesen Begriff definiert er in Vom Kriege), der immer dem selben Muster folgt. Beharrlichkeit tut das dagegen nur so lange wie es Sinn ergibt, weshalb auch sie einem datengetriebenen Anpassungs-Ansatz unterliegen muss.

Mit seinen Konzepten der Friktionen, des Nebels des Krieges, der Geistesgegenwart und der Beharrlichkeit hat Clausewitz also zentrale Aufgabenstellungen und Lösungsansätze der agilen Vorgehensmodelle vorweggenommen. Dass das heute nicht (mehr) bekannt ist, ist bedauerlich, aber erklärbar. Es dürfte zum einen an seiner aus heutiger Sicht umständlichen Sprache liegen und zum anderen an der Abkehr Deutschlands von seinen militärischen Traditionen. Wer sich davon nicht abhalten lässt kann sich allerdings einige interessante Inspiratonen an einer Stelle holen, an der man sie normalerweise nicht erwarten würde.