Samstag, 29. September 2018

Kommentierte Links (XLI)

Bild: Pixabay / Bru-nO - Lizenz
  • Marcus Raitner: Die modernen Hofnarren

    Einerseits ist das was Markus Raitner hier schreibt absolut richtig - dadurch dass ein Scrum Master (bis zu einem gewissen Grad) von den Konventionen und sozialen Barrieren eines Unternehmens entbunden ist kann er Dinge ansprechen die von anderen nicht angesprochen werden können. Andererseits ist eine Konstellation in der das zutrifft hochgradig dysfunktional, bedeutet es doch, dass "normale Angestellte" eben nicht die Erlaubnis haben Kritik zu üben. Der Scrum Master-Hofnarr kann demnach zwar in einer Übergangsphase seine Berechtigung haben, als ständige Institution wäre er aber ein Anzeichen dafür, dass die agile Transition gescheitert ist.

  • Trish Khoo: Make a technical debt payment plan

  • Eine grossartige Idee! Wenn die finanziellen Schulden eine passende Inspiration für die Metapher der technischen Schulden sind, dann kann auch der Abbau technischer Schulden mit einem Begriff aus dem finanziellen Umfeld beschrieben werden. Ein Rückzahlungsplan wie man ihn für die Befreiung aus erdrückenden Verbindlichkeiten benötigt macht in der IT genau so viel Sinn wie bei der Haushaltsplanung: welche Schulden sind die drängendsten und dringensten, mit welchen Schritten kann ihr Abbau angegangen werden und wer wird sich dieser Schritte annehmen? Peter Zwegat wäre begeistert.

  • Krishna Kandala: Business agility for speed to market - Applying design & agile thinking to drive consumer value

    Der beste Weg in Richtung Zukunft ist die beständige Lieferung kleiner, funktionsfähiger, Mehrwert stiftender Neuerungen und Erweiterungen. Der Versuch in wenigen, grossen, seltenen Schritten riesige Fortschritte zu erzielen macht schwerfällig und vervielfacht das mit Fehlentscheidungen einhergende Risiko. Was in der IT Common Sense ist versucht Krishna Kandala auf die Business-Welt zu übertragen. Ein zentraler Punkt seiner Überlegungen: grosse Unternehmen haben in der Regel kein Problem mit der Entwicklung neuer Ideen, sie tun sich aber sehr schwer damit, daraus vermarktbare Produkte zu machen - und zwar weil sie ihre grossen Visionen nicht in kleine Incremente herunterbrechen können.

  • Mike Cohn: What Does It Mean to Be Potentially Releasable?

    Einer der wichtigsten Sätze im Scrum Guide ist: "The increment must be in useable condition regardless of whether the Product Owner decides to release it." Was für diesen Zustand nötig ist und was nicht ist Gegenstand umfassender und beständig wiederkehrender Debatten. Die Gedanken die sich Mike Cohn hier macht umfassen vieles davon und gehen an einer wichtigen Stelle noch einen Schritt weiter - was sollte man tun wenn man merkt, dass ein Increment nicht "potentially releasable" sein wird? Sein Ratschlag: die Arbeit daran unterbrechen, bzw. beenden. Interessant ist auch was er nicht empfiehlt: den Sprint-Abbruch.

  • Ron Jeffries: XP revisited

    Einmal mehr ein typischer Ron Jeffries-Text. Sehr lang, sehr gehaltvoll, sehr zu empfehlen. Im Mittelpunkt die Frage: wenn Extreme Programming heute neu erfunden, bzw. neu eingeführt werden würde - was wären seine Kernelemente?

Dienstag, 25. September 2018

Warum Agile/Scrum ohne Testautomatisierung nicht funktioniert (III)

Bild: NASA - Public Domain
Mitunter bekommt man als Agile Coach die aberwitzigsten Probleme mit. Ein derartiger Fall ist mittlerweile schon etwas her aber immer noch bemerkenswert: er dreht sich um eine Anwendung eines grossen Konzerns, deren Entwicklung irgendwie agil werden sollte, wobei aber ein nicht ganz unwesentliches Hindernis im Weg stand - die Regressionstests wurden noch weitgehend manuell durchgeführt. Es waren viele. Sehr viele.

Es handelte sich um ein System mit mehreren über die Jahrzehnte zugekauften und integrierten Teilsystemen, die durch zahlreiche Schnittstellen verbunden waren. Insgesamt 75.000 Testfälle (!) mussten jedes mal durchgeklickt werden um sicherzustellen, dass neuentwickelte Features nicht versehentlich bestehende Anwendungsteile beschädigt hatten. Eine ungeheuerliche Zahl, deren Bewältigung nur möglich war weil Offshore-Testing in irgendeinem asiatischen Land mit niedrigen Löhnen betrieben wurde.

Die Durchführung eines solchen Regressionstestzyklus dauerte etwa ein Jahr, bei den letzten Malen waren dabei jeweils knapp 7000 kritische Bugs (→ funktionale Fehler ohne möglichen Workaround) entdeckt worden. Da nach dem Beheben dieser Bugs ein weiterer Regressionstestzyklus zu lange gedauert hätte wurden die Bugfixes gleichzeitig mit neuen Features eingecheckt, was natürlich Merge-Konflikte verursachte. Die Folge war das erneute Auftreten tausender Fehler, womit der Kreislauf von neuem begann.

Warum in diesem Fall nicht einmal im Entferntesten an agile Softwareentwicklung zu denken war ist offensichtlich: ein einziges, dazu noch Bug-verseuchtes, Grossrelease pro Jahr? Das ist weit, weit, weg von der Auslieferung nutzbarer Inkremente mehrfach pro Monat. Um weitgehend fehlerfreie Anwendungen auszuliefern hätte man sogar mindestens einen Regressionstestzyklus einer Bugfix-Welle abwarten müssen, in Summe hätte es dann zwei Jahre gedauert.

Wie man denn aus dieser Situation hauskommen könnte, war die Frage. Ein nachträgliches Automatisieren der Testfälle wäre wegen fehlendem Budget nicht möglich, ob es denn andere Wege gäbe agil zu arbeiten? Als das verneint wurde war relativ schnell klar, "dass Agil wohl nicht das Richtige für uns ist." Quod erat demonstrandum. Zwei Jahre später kam es zu einem zufälligen Treffen mit einem Kollegen des Testmanagers, der sich so geäussert hatte. Mittlerweile waren es keine 75.000 Testfälle mehr. Die Zahl war deutlich höher.

Freitag, 21. September 2018

Die agile Legion

Dass die Agilität einen Grossteil ihrer Ursprünge in der Kriegsführung hat ist eine jener unangenehmen Wahrheiten die man gerne verschämt unter den Tisch fallen lässt. Und doch ist es so - von den Abhandlungen des Generals von Clausewitz bis zu den selbstorganisierten mongolischen Reiterhorden des Dschingis Khan zieht sich eine lange Spur erfolgreicher militärischer Anwendungen agiler Ansätze durch die Geschichte. Ein weiterer, noch länger zurückliegender betrifft eine der bekanntesten Armeen der aller Zeiten: die römischen Legionen. Anschaulich erklärt wird es in diesem Video:



Was durch Beispiele wie dieses klarer wird: Agilität ist keine Mode, kein Hype und kein Trend, sondern ein uralter (mindestens 2000 Jahre alter) Organisationsgrundsatz: dezentrale und anpassungsfähige Organisationen sind auf Dauer den zentralisierten, auf Planerfüllung ausgerichteten überlegen, und zwar selbst dann wenn sie zu Beginn noch in einer eher unterlegenen Position waren. Spätestens dann wenn "das Terrain unwegsam wird" bringen Grösse und Kraft alleine keinen Vorteil mehr.

Montag, 17. September 2018

It's all about People

Ich habe Gitte vor einigen Jahren auf einem Agile Coach Camp kennengelernt und kann bestätigen: sie umarmt Menschen, auch solche die sie nicht kennt. Das dürfte im Zusammenhang damit stehen, dass sie Agilität sehr stark von der menschlichen Seite aus betrachtet. So wie in diesem Talk.

Donnerstag, 13. September 2018

Maximum Work in Progress

Bild: Flickr / Alexander Baxevanis - CC BY 2.0
Ein häufiges Problem in Organisationen jeglicher Grösse ist das Untergehen in zu viel gleichzeitig begonnener Arbeit. Das Wechseln zwischen den verschiedenen Kontexten kostet Konzentration und begünstigt Verwechselungen und darauf folgende Fehlentscheidungen, die Menge paralleler Aufgaben sorgt dafür, das Übersichtlichkeit verloren geht und die Vielzahl wartender Stakeholder führt zu Konflikten und Meeting-Overhead. Derartige Zustände müssen verhindert werden, und zum Glück gibt es dafür auch einen Lösungsansatz.

Die Menge der übernommenen Aufgaben lässt sich in den Griff bekommen indem man sich selbst eine Obergrenze setzt (das ist sowohl für einzelne Personen als auch für ganze Teams möglich). Ist diese Grenze erreicht wird kein weiteres Arbeitspaket angenommen. Erst dann wenn eine der begonnenen Tätigkeiten abgeschlossen wird kann eine neue begonnen werden. Diese Obergrenze (das Maximum Work in Progress Limit) ist ebenso einfach wie wirksam - und fast nirgendwo gelingt es sie einzuhalten.

Angesichts des wunderbar einfach anmutenden Werkzeug des Maximum Work in Progress Limit gerät schnell in Vergessenheit, dass hinter gleichzeitigem Arbeiten an zahlreichen Aufgaben in der Regel keine Fahrlässigkeit steckt sondern Notwendigkeit. In arbeitsteilig geprägten Organisationen ist fast niemand mehr in der Lage eine Aufgabe alleine abzuschliessen, immer wieder muss auf Zulieferungen, Genehmigungen, Abnahmen oder Informationen gewartet werden. Manchmal stundenlang, manchmal wochenlang, manchmal noch länger. Um in dieser Zeit nicht untätig sein zu müssen fängt man eben mit der nächsten Tätigkeit an. Und der übernächsten. Und so weiter.

Wirksame Obergrenzen bedeuten demnach in der Regel nicht, dass man sich selber diszipliniert. Wirksame Obergrenzen bedeuten, dass man sich um vorgelagerte, nachgelagerte und parallele Prozesse kümmern muss. Erst wenn die so beschleunigt werden, dass man nicht mehr gezwungen ist auf sie zu warten kann man sich auf wenige gleichzeitige Tätigkeiten beschränken ohne dadurch immer wieder in Phasen der unfreiwilligen Untätigkeit zu geraten.

Um diese Beschleunigung umgebender Prozesse zu erreichen können je nach Kontext verschiedene Massnahmen sinnvoll sein. Die Aufstockung von Ressourcen, der Abbau von Vorschriften oder die Rücknahme lokaler Optimierungen können helfen, meistens können diese Massnahmen aber nicht selbst eingeleitet werden sondern nur von den jeweils betroffenen Einheiten. Mit Glück sind diese auch dazu bereit und in der Lage, mit Pech sind sie es nicht. Es bleibt dann nur noch ein Ausweg: selber machen.

Sowohl viele der vorgelagerten Schritte (Anforderungserhebung, Design, Abstimmung) als auch nachgelagerte Tätigkeiten (Test, Rollout) können von den meisten Entwicklungteams selber übernommen werden, wenn ihnen der nötige Freiraum und die nötigen Werkzeuge gegeben werden. Das genehmigt zu bekommen ist die eigentliche Herausforderung beim Versuch ein Maximum Work in Progress zu etablieren. Und die damit verbundenen Schwierigkeiten sind der Grund dafür, dass man wirksame Obergrenzen so selten finden kann.

Montag, 10. September 2018

Der Empfangstest

Bild: Wikimedia Commons / Deniz Gültekin - CC BY-SA 3.0
Eines der grössten Probleme in der Produktentwicklung ist zu geringes oder zu spätes Nutzer-Feedback zu den entwickelten Features. Zahllose Produkte sind am Markt vorbeientwickelt worden und haben nichts als finanzielle Verluste und Demoralisierung der Entwicklungsteams erzeugt. Um all das zu vermeiden gibt es nur einen Weg: einem potentiellen Kunden möglicht früh eine erste Version vorlegen und ihn nach seiner Meinung fragen.

Der klassische Weg das zu tun ist die Beauftragung eines internen oder externen Partners, der dann in den Fussgängerzonen der Grossstädte Passanten anspricht und in einen Befragungsraum bittet. In Bezug auf Professionalität und Reichweite noch immer der beste Ansatz, allerdings mit dem Nachteil behaftet, dass damit ein relativ hoher Zeitaufwand verbunden ist. Die Marktforscher müssen gebrieft werden, die Ergebnisse konsolidiert werden, etc.

Ein schnellerer und direkterer Weg ist eine "interne Marktforschung" im eigenen Unternehmen. Vor allem in grösseren Firmen mit hunderten oder tausenden von Mitarbeitern können sich so schon erste Feedbacks zu Verständlichkeit, Usability und Nachfrage ergeben, die man in die weitere Planung einfliessen lassen kann. Damit ist aber auch das Risiko verbunden, dass Betriebsblindheit in das Feedback einfliesst, da die eigenen Mitarbeiter keinen unbefangenen Blick mehr haben.

Eine gute Massnahme um dem entgegenzuwirken ist die Auswahl von Gesprächspartnern aus thematisch möglichst weit entfernten Unternehmensteilen. Bestenfalls mit einer so grossen Distanz, dass ihnen nicht nur die Entwicklungsabteilung fremd ist sondern auch die branchenspezifische Fachsprache, die bisherigen Altprodukte und der Markt mit seinen Konkurrenzanbietern.

Sehr gute Erfahrungen haben wir bei einem Kunden mit dem Empfangspersonal der verschiedenen Gebäude gemacht (für diese Interviews setzte sich schnell der Begriff "Empfangstest" durch). Die dort arbeitenden Damen und Herren standen in ihrem täglichen Alltag so weit ausserhalb der Arbeit der Produktentwicklung, dass sie einen unvoreingenommeneren und neutraleren Blick hatten als alle anderen Kollegen des Unternehmens.

Sich auf die Suche nach solchen Mitarbeitern zu machen ist hochgradig sinnvoll wenn um der Geschwindigkeit willen die ersten Nutzerbefragungen intern durchgeführt werden sollen. In den meisten Firmen gibt es auch mehr von ihnen als man denkt, man muss nur die Augen offenhalten - zum Beispiel beim Betreten des Gebäudes.

Donnerstag, 6. September 2018

Untertanenkultur

Bild: Public Domain Pictures - CC0 1.0
Zu den Demonstrationen von Rechtsradikalen und "besorgten Bürgern" die in den letzten Tagen in Chemnitz stattgefunden haben ist eigentlich schon alles gesagt worden (und Politik soll auch nicht das Thema dieser Website werden). Es gibt aber einen Aspekt der gesondert herausgehoben werden kann, weil er auch über die Politik hinaus eine Bedeutung hat: die von einem Teil der Demonstranten geäussterte unspezifische Erwartung, "irgendjemand" müsste sofort "irgendetwas" tun um die Gesamtsituation zu verbessern (ein Beispiel hier).

Hinter einer solchen Erwartung stehen mehrere verschiedene Grundeinstellungen. Zum einen die, dass derjenige der sich so äussert nicht selbst aktiv werden möchte. "Jemand anders soll tätig werden, nicht ich." Paradoxerweise ist das verbunden mit einem Gefühl der Dringlichkeit. "Es muss etwas passieren, und zwar jetzt." Zuletzt ein offenes Desinteresse an einer Beteiligung an der Lösungsfindung. "Was gemacht wird interessiert mich nicht, solange dadurch alles besser wird."

Diese Grundeinstellungen sind vor allem in grossen Organisationen wie Behörden oder Konzernen immer wieder anzutreffen. Die Ursache dafür (die auch die Verbindung zu den in der DDR großgewordenen "besorgten Bürgern" bildet) ist die private und/oder berufliche Sozialisation in hierarchischen, von Befehl und Gehorsam geprägten sozialen Systemen. Man spricht in diesem Zusammenhang von einer "Untertanenkultur", einem Begriff der eine nähere Betrachtung wert ist.

Geprägt wurde er von den beiden amerikanischen Politikwissenschaftlern Gabriel Almond und Sidney Verba in ihrem Werk "The Civic Culture". Basierend auf tausenden von Interviews in mehreren von einer Untertanenkultur geprägten Ländern konnten sie aufzeigen, dass diese auf vier Annahmen beruht:
  • Der einzelne Mensch ist unwissend und kann nichts bewirken
  • Das Gesamtsystem ist allwissend und kann alles erreichen
  • Der Einfluss des Einzelnen auf die Hierarchie ist winzig
  • Der Einfluss der Hierarchie auf den Einzelnen ist gewaltig
Es ist erkennbar: wer ein Weltbild hat das auf diesen vier Annahmen beruht wird fast zwangsläufig die Erwartungshaltung entwickeln, dass "die da oben" von sich aus darauf kommen müssen, wie eine als problematisch wahrgenommene Situation verbessert werden kann. passiert das nicht wird es als Systemversagen wahrgenommen, was zu Frustration und Wut führen kann.

Um die Betroffenen aus dieser Wut und Frustration in ein konstruktives Miteinander zurückzuführen ist ein Kulturwandel nötig, der in diesem Modell durch eine Widerlegung der besagten Annahmen herbeigeführt werden kann. Den Menschen muss klar werden, dass sie Gestaltungsspielraum haben, dass ihre Ideen gehört werden und dass das Gesamtsystem auf diesen Input angewiesen ist um funktionieren zu können. Das sagt sich leicht, umzusetzen ist es schwer. Aber es lohnt sich.

Wenn dieser Wandel stattfindet kann aus der Untertanenkultur (und der Erwartung "irgendjemand anders" müsste "irgendwie" alle Probleme beseitigen) eine partizipierende Kultur werden, in der jeder von sich aus dazu beiträgt, dass permanent an Verbesserungen gearbeitet wird. Dadurch wird nicht nur das Gesamtsystem leistungsfähiger, es werden auch die ihm angehörenden Menschen zufriedener. Und "besorgte Bürger" spielen dann keine Rolle mehr.

Montag, 3. September 2018

Silver bullets can hurt

Ein Vortrag über eines der grössten Risiken agiler Transitionen, die Methodengläubigkeit. Die Kernaussage, die ich auch unterschreiben würde: die gängigen Methoden und Frameworks sind gute Sammlungen von verwertbarem Wissen und Erfahrungen, aber keines von ihnen ist als Problemlösung ausreichend. Werden sie mit dieser Erwartung eingeführt richten sie eher Schaden an.