Donnerstag, 21. Juli 2016

20.000 mal automatisch getestet

Bild: Wikimedia Commons/Library of Congress - Public Domain
Die Geschichte die in den letzten Tagen durch die Medien ging war in vieler Hinsicht bemerkenswert: Nachdem die Comdirekt-Bank Anfang der Woche eine neue Version ihrer Banking-Software deployed hatte war es zeitweise möglich sich in die Accounts anderer Kunden einzuloggen, die Kontenstände einzusehen und Änderungen der Einstellungen vorzunehmen. Ein massives Versagen der Qualitätssicherung also, das den Ruf dieses Instituts schwer beschädigt hat. Ein interessantes Detail war in diesem Zusammenhang das Statement einer Unternehmenssprecherin, die gegenüber der FAZ erklärte, dass alle IT-Updates mehr als 20.000 Mal automatisch getestet würden, weshalb solche Fehlfunktionen die absolute Ausnahme wären.

Ganz abgesehen davon, dass diese Aussage für die Betroffenen nicht besonders tröstlich sein dürfte - sie steht symptomatisch für ein Problem an dem viele Firmen leiden: den Glauben, dass Risiken sich minimieren lassen indem einfach mehr Tests durchgeführt werden. Das ist zwar nicht völlig falsch, viele, in kurzen Abständen durchgeführte Tests können einen hohen Mehrwert bringen. Zu glauben, dass hier eine Kausalität bestehen würde ist allerdings hochgradig riskant. Die Anzahl der Tests ist bestenfalls ein Indikator, mehr nicht.

Ich habe es über die Jahre immer wieder erlebt, dass ein Management "ambitionierte Ziele" formuliert hat, die erfüllt werden mussten. Pro Woche wurde eine bestimmte Anzahl von Tests vorgegeben die zu schreiben waren, und zwar sowohl bei den manuellen Tests als auch bei Unit Tests, automatisierten GUI-Tests und in anderen Bereichen. Um nicht an die Wand gestellt zu werden taten die Entwickler und Tester alles dafür diese Vorgaben zu erfüllen. Am Ende wurde die Planzahl erfüllt, allerdings durch sinnloses Aufblähen: Unit Tests für Getter und Setter, eigene End to End Tests für praktisch identische Testdaten-Sets und Ähnliches mehr kam so zu stande.

Wesentlich wichtiger als die Anzahl der Tests ist aber ihre Qualität: decken sie auch negative Validierungen ab? Überprüfen sie Grenzwerte? Basieren sie auf Überlegungen wo eine Fehlfunktion besonders großen Schaden anrichten würde? Solche Sachen. Das Problem dabei - lässt man sich darauf ein kann man als Manager nicht mehr so einfach an irgendwelchen Stellschrauben drehen um die (Illusion von) Sicherheit zu erhöhen. Auf der anderen Seite produzieren solche Tests dann tatsächlich einen Mehrwert und nicht bloß eine imposant klingende Zahl. Wenn es darauf ankommt ist die nämlich weder tröstlich noch nützlich. Siehe oben.

Montag, 18. Juli 2016

Kritischer Rationalismus


Vielleicht habe ich doch mehr aus meinem Studium in meinen Beruf übertragen als ich dachte - aus einer Diskussion mit einem alten Studienfreund habe ich mitgenommen, dass das was ich im Rahmen von Organisationsentwicklung mache, viel mit dem Kritischen Rationalismus zu tun hat, über den ich damals Klausuren schreiben durfte. Das Zitat oben auf dem Bild sagt im Grunde alles aus:
Alle Aussagen müssen an der Erfahrung überprüfbar sein, müssen sich in der Konfrontation mit der Realität bewähren. Mit anderen Worten: Alle Aussagen einer empirischen Wissenschaft müssen - sofern sie unzutreffend sind - prinzipiell an der Erfahrung scheitern können.
Karl Popper, Logik der Forschung
Vor allem eine Variation des letzten Satzes trage ich schon seit Jahren jedem meiner Kunden vor: "Alle Maßnahmen müssen an der Realität scheitern können." Hinter dieser Aussage steckt ein Ansatz der allgemein als datengetrieben (data driven) bezeichnet wird und nichts anderes tut als das gute alte Inspect & Adapt auf eine empirische Basis zu stellen: jede Maßnahme sollte mit einem messbaren Ziel verbunden sein, damit sich feststellen lässt ob sie wirksam ist oder nicht. Die in diesem Zusammenhang notwendige empirische Validierung beginnt idealerweise bereits mit der initialen Formulierung. Statt sie um eine vermeintliche Kenntnis kausaler Zusammenhänge herum aufzubauen (Um mehr Kunden zu bekommen bauen wir mehr blinkende Banner ein) sollte sie als widerlegbare Hypothese formuliert sein (Wenn auf jeder Webseite mindestens ein blinkendes Banner zu sehen ist gewinnen wir mindestens 100 neue Kunden).

Aufbauend auf diese Fomulierung sollte dieses Widerlegen dann versucht werden, und zwar durch einen transparenten Vergleich von Hypothese und Ergebnis. Dabei ist es von wesentlicher Bedeutung, dass nicht versehentlich doch eine Belegung oder Verifizierung der Hypothese im Mittelpunkt steht, sondern die zentrale Komponente des kritischen Rationalismus, die Falsifizierung oder eben Widerlegung. Hintergrund ist, dass man bei Verifizierungen immer wieder auf Vermutungen angewiesen ist (wir haben 100 neue Kunden, das muss an den blinkenden Bannern liegen), während die Falsifizierungen klarere Aussagen zulassen (im Vergleich zu Produkten mit blinkenden Bannern haben die Produkte ohne blinkende Banner genauso viele Neukunden, die Maßnahme ist also wirkungslos).

Einige der erfolgreichsten agilen Unternehmen wie z.B. Netflix oder Spotify setzen bei der Produktentwicklung durchgehend darauf, Hypothesen in Experimenten zu überprüfen und rollen Neuheiten erst dann komplett aus, wenn sie nicht falsifizierbar sind. Der Erfolg ihrer Produkte gibt ihnen recht. Im Umkehrschluss ist das auch ein Grund dafür, dass viele Großkonzerne mit ihren "innovativen" Produkten nur mittel bis wenig erfolgreich sind - da hier oft eine Kultur des keine Fehler machen dürfens vorherrscht kann sich niemand die Falsifikation seiner Hypothesen erlauben, da ihr Eintreten als Versagen gesehen würde und Karrieren beschädigen könnte. Um sicher zu sein versucht man es meistens gar nicht erst.

Letztendlich folgt aus dem Gesagten eine Schlusspointe - der auf den ersten Blick negative, destruktive und auf Falsifikation fixierte Ansatz des Kritischen Rationalismus entpuppt sich bei näherer Betrachtung als durchaus menschenfreundlich: Fehler werden in ihm nicht nur toleriert sondern sogar zum Zweck des Erkenntnisgewinns bewusst in Kauf genommen. Die Folge ist eine angstfreie Arbeitsumgebung, etwas das weit weniger selbstverständlich ist als man glauben sollte.

Donnerstag, 14. Juli 2016

Das agile Pandämonium

Mein favorisiertes Video der letzten Tage. Nicht nur wegen des österreichischen Dialekts (ich habe ein paar Jahre an der Grenze gewohnt) sondern auch wegen des Wahrheitsgehalts. Jedem dieser "Dämonen" habe ich in der Realität bereits begegnen dürfen.

Das Agile Pandämonium from JAX TV on Vimeo.

Montag, 11. Juli 2016

Update des Scrum Guide 2016

Bild: Pixabay/Geralt - Lizenz
Zum ersten mal seit drei Jahren hat der Scrum Guide, das offizielle Regelwerk von Scrum, wieder ein Update bekomen. Neu hinzugefügt wurde ein Abschnitt über die Werte von Scrum. Im Einzelnen sind das Commitment (Engagement/Hingabe), Courage (Mut), Focus (Konzentration/Zielgerichtetheit), Openness (Offenheit) und Respect (Respekt). Diese Werte sind keineswegs neu, sie gehören schon seit Jahren zu den Best Practices von Scrum, nur eben ohne offizieller Bestandteil zu sein. Das sind sie erst jetzt.

Ich kann diese Erweiterung nur begrüßen, schließlich habe ich mehr als einmal erleben dürfen was mit Unternehmen oder Teams passiert, die versuchen Scrum zu adaptieren ohne die dahinterstehenden Werte zu ihren eigenen zu machen (kurz gesagt: sie scheitern). Bisher ließ sich diese Art von Cargo Cult immer damit rechtfertigen, dass diese Werte ja nicht zwingend notwendig wären, denn sonst würden sie ja im Scrum Guide stehen. Jetzt stehen sie drin, es gibt also eine Ausrede weniger.

Da wir gerade beim Thema Update des Scrum Guide sind - ich finde, eine weitere Ergänzung wäre sinnvoll gewesen, nämlich die Verkürzung der maximal möglichen Sprint-Dauer von vier auf drei oder vielleicht sogar zwei Wochen. Überall dort wo ich Drei- oder Vierwochensprints erlebt habe war das Inspect & Adapt etwas schwerfällig, Stories wurden tendenziell zu groß geschnitten und Arbeit staute sich vor dem Sprintende. Aber vielleicht kommt das ja beim nächsten Update.

Donnerstag, 7. Juli 2016

Remote-Retrospectiven mit Google Docs

Bild: Pexels / Monstera - Lizenz
Zum ersten mal seit längerem habe ich diese Woche wieder eine Remote-Retrospektive moderiert. Ich persönlich finde es zwar immer besser alle Teilnehmer in einem Raum zu haben, wenn es aber nicht anders geht ist remote besser als nichts. Die Frage ist nur: wie gestalte ich den Termin so, dass man sich auch aus der Ferne aktiv beteiligen kann? Zu diesem Zweck habe ich in dieser Woche etwas Neues ausprobiert, nämlich die  Einbindung von Google Docs in den Veranstaltungsablauf. Das hat gleich so gut funktioniert, dass ich es hier teilen möchte.

Google Docs hat gleich mehrere Vorteile: es ist kostenlos, es kann online benutzt werden und die hier erstellten Dokumente können von mehreren Personen gleichzeitig bearbeitet werden. Vor allem der letzte Aspekt ist wichtig - die Bearbeitungen sind sofort und ohne Neuladen der Seite für alle Teilnehmer sichtbar. Durch diese Bearbeitung in Echtzeit kann ein solches Dokument viele der Funktionen übernehmen, die sonst eine Wand oder ein Board hätte. Gleichzeitig kann es direkt im Anschluss als Dokumentation des Meetings benutzt werden, entweder online gespeichert bei Google oder heruntergeladen als PDF, JPG, PPT oder Doc-Datei.

Das folgende Template entspricht etwa dem das ich benutzt habe, ergänzt um einige Verbesserungsmöglichkeiten die mir während der Durchführung aufgefallen sind. Als Tonspur haben wir Hangout benutzt, aber auch jede andere Konferenz- oder Chatsoftware wäre möglich. Die Bilder sind von Pixabay, einem Anbieter für kostenlose lizenzfreie Inhalte, die auch komerziell genutzt werden können.

Dienstag, 5. Juli 2016

Wer nimmt am Estimation-Poker teil?


Zugegeben, im Normalfall ist das keine schwere Antwort. Der Product Owner stellt die Story vor, das Entwicklungsteam hält die Karten hoch, der Scrum Master steht daneben und macht ein interessiertes Gesicht. So einfach ist das. Es kann allerdings auch anders kommen, nämlich dann wenn im Team sehr unterschiedliche Berufe vertreten sind. Der Scrum Guide gibt es klar vor: "Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment". Je nach Produkt können also auch Designer, Business Analysten, manuelle Tester oder sonstige IT-ferne Gruppen zum Team gehören. Sollten die an den Schätzungen teilnehmen?

Von verschiedenen Scrum Mastern oder Agile Coaches habe ich gehört, dass auch solche Personen mit der Zeit ein Gespür für die Komplexität von Anforderungen bekommen könnten. Das mag in diesen Fällen auch so gewesen sein, allerdings bezweifele ich, dass man daraus eine Regel ableiten kann. Ich durfte bereits mehrmals beobachten wie sich derartig gemischte Teams über einen längeren Zeitraum entwickeln, und selbst nach ein oder zwei Jahren war von einem "Gespür" nichts zu sehen. Es war so als würde man nur die Kühlerhaube kennen und würde versuchen auf dieser Grundlage über den Motor zu reden. Für die beteiligten Entwickler war es bestenfalls amüsant, für die anderen im schlimmsten Fall demütigend. Hilfreich war es für niemanden.

Die verborgene Tragik in derartigen Anekdoten: nirgendwo in den Scrum-Regeln steht geschrieben, dass alle Teammitglieder an jeder Schätzung teilnehmen müssen. Es reicht völlig aus wenn Estimations nur von denjenigen vorgenommen werden die dazu wirklich in der Lage sind, im Fall von Software-Entwicklung also von den beteiligten Entwicklern. Dabei ist es natürlich so, dass die anderen Mitglieder in den dazugehörenden Diskussionen darauf hinweisen können, dass der Dokumentations- oder Testaufwand mit berücksichtigt werden sollten. Das kann wertvoll sein. Aber: wenn es z.B. darum geht den Kundendaten-Bereich aus einer monolithischen Anwendung in einen Microservice zu überführen - welcher Nicht-Entwickler soll das beurteilen können? Keiner.

Natürlich mag es immer Ausnahmen geben, grundsätzlich kann man aber sagen: so schade es aus methodischer Sicht auch ist, es wird immer wieder Fälle geben in denen nicht alle Teammitglieder an den Aufwandsschätzungen teilnehmen können (und manchmal kann das sogar umgekehrt sein, etwa wenn die Entwickler nicht beurteilen können wie aufwändig eine Marktstudie ist). Genau dafür gibt es im Estimation Poker auch die Karte mit dem Fragezeichen.

Donnerstag, 30. Juni 2016

Kommentierte Links (XIV)

Grafik: Pixabay / Geralt - Lizenz

  • Haufe.de: Wie Unternehmen agil werden

    • Den Namen dieses Artikels muss man nicht beachten, darüber wie Unternehmen agil werden wird man hier nicht viel finden. Wesentlich interessanter sind dagegen zwei an dieser Stelle veröffentlichte Zahlen aus der von Haufe durchgeführten Studie "Agilität in deutschen Unternehmen". Denen zufolge halten zwar 70 Prozent der Führungskräfte ihr Unternehmen für agil, von den Mitarbeitern sehen das aber nur 31 Prozent so. Diese Ergebnisse decken sich in etwa mit dem was ich auch angenommen hätte und was ich in verschiedenen Unternehmen bereits gesehen habe: die oberen Hierarchieebenen sind so weit weg von der tatsächlichen Arbeit, dass die blosse Existenz von Sprints oder User Stories sie an die eigene Agilität glauben lässt. Die unteren Dienstränge wissen es besser, werden aber nicht gehört oder ernstgenommen.

  • Georg Meck: Wie wollen wir morgen arbeiten?

    • Zu den in vielen Firmen noch immer unterschätzten Voraussetzungen für agiles Arbeiten gehört die passende Architektur. Die klassischen Einzel- oder Doppelbüros sind im wahrsten Sinne des Wortes betonierte Kommunikationsbarrieren, verschlossene Türen sorgen für Intransparenz, Wohnzimmer-Arbeitsplätze mit Büropflanzen, Bildern und Festnetztelefonen befördern die Herausbildung von Unternehmensbewohnern. Neuartige Open Space-Büros wie in der in diesem Artikel vorgestellten neuen Siemens-Zentrale wirken dem entgegen. Wunder bewirken können sie nicht (einige der unagilsten Unternehmen die ich kennenlernen durfte residieren in luftigen Glaspalästen), aber alleine durch ihre Offenheit und Durchlässigkeit vereinfachen sie die Zusammenarbeit und bringen die Mitarbeiter zusammen. Das ist viel wert.

  • Noah Lorang: Real-time dashboards considered harmful

    Was Noah Lorang da beschreibt kann ein echtes Problem sein: Wenn ein Team die falschen Kennzahlen auf den großen Wandmonitoren abbildet besteht die Gefahr, dass es in Aktionismus verfällt sobald diese zu schwanken beginnen. Dabei ist es grundsätzlich richtig, die richtigen KPIs zu monitoren und dafür zu sorgen, dass sie stabil bleiben. Die Kunst besteht darin, herauszufinden welches die richtigen sind. Einige gute Ansätze werden in dem Artikel genannt: längere Darstellungszeiträume, Interaktionsraten, relative statt absolute Werte und Focus auf hohe statt auf niedrige Abweichungen. Unwichtige Metriken werden dadurch weggefiltert und man sicher sein, dass die angezeigten Zahlen so bedeutsam sind, dass man auf Schwankungen schnell reagieren sollte.

  • Adam Taylor: Why login isn’t the first thing you build

    • Ich gestehe: auch ich habe schon einmal einem Product Owner geraten, die Login-Funktion zum Thema seiner ersten User Story zu machen. Wenn man davon ausgeht, dass man möglichst früh ein Minimum Viable Product will, ist das aber sehr wahrscheinlich falsch. Nach den ersten Stories ist noch so gut wie kein Produkt marktreif und das muss es auch noch gar nicht sein. Es sollte aber bereits so weit sein, dass es dem Auftraggeber, dem Kunden oder einer Testgruppe vorführbar ist, und für diese Zwecke ist ein möglichst großer initialer Funktionsumfang wichtiger als ein vorgeschalteter Login. Dass der später noch gebaut werden muss steht bei den meisten Produkten außer Frage, aber als erstes Feature empfiehlt sich definitiv etwas mit größeren Aha-Effekt.

  • Lafable.com: Large Agile Framework Appropriate for Big, Lumbering Enterprises

    • Eine großartige Parodie auf (pseudo)agile Skalierungsframeworks. In der Theorie klingt das alles nicht schlecht, in der Realität ist es oft nur ein Feigenblatt für Großkonzerne die agil erscheinen möchten ohne ihre "traditionellen" Vorgehensweisen aufzugeben. Wer beide Welten kennt wird es schnell merken - wir sehen hier das klassische Wasserfall/Chaos-Vorgehen mit potemkinscher agiler Fassade.

Dienstag, 28. Juni 2016

Size matters (die umgedrehte Test-Pyramide)

Beim Durchsprechen einer Präsentation für einen unserer Kunden sind ein Kollege und ich zu einer bemerkenswerten Erkenntnis gekommen: die Benutzung der "umgedrehten Test-Pyramide" kann unter Umständen das Gegenteil des gewünschten Effekt bewirken. Um das zu erklären zunächst die Grundlage - das hier ist die Pyramide in ihrer richtigen und in ihrer umgedrehten Form1:


Die richtige Form auf der linken Seite stellt dar wie die Größenverhältnisse zwischen den verschiedenen Test-Arten sein sollten: Sehr viele Unit Tests, weniger Integrationstests und ganz wenige manuelle Tests der obersten Ebene. Die Realität entspricht oft der rechten Darstellung: Viele manuelle Tests, wenige Integrationstests und kaum Unit Tests. Die Präsentation dieser beiden Grafiken soll den Managern des Kunden die Missstände aufzeigen und sie dazu bewegen etwas an ihnen zu ändern. Die Pyramidenform hat sich in diesem Zusammenhang als bewährtes Mittel der Visualisierung erwiesen. Sie lässt sich einfach aufzeichnen, stellt Ebenen und Größenverhältnisse nachvollziehbar dar und ist auch ohne technisches Vorwissen einfach verständlich.

Trotzdem haben wir in dieser Darstellung der beiden Pyramidenformen eine Quelle für Missverständnisse und Fehlentscheidungen entdeckt, und zwar die folgende - beide Pyramiden sind gleich groß. Für eher technikferne Entscheidungsrunden entsteht auf diese Weise der Eindruck, die Testabdeckung wäre in beiden Fällen gleich. Natürlich ist in diesem Zusammenhang offensichtlich, dass die manuelle Ausführung länger dauert, aber das muss ja aus Managementsicht nicht schlimm sein. Ich erinnere mich in diesem Zusammenhang an ein Berliner Startup, dass statt Testautomatisierern manuelle Tester einstellte, da es für das selbe Geld doppelt so viele von denen gab.

Was dabei völlig untergeht ist die Tatsache, dass die rechte Pyramide nicht nur auf dem Kopf steht, sondern, dass ihre Tests in Summe auch eine viel geringere Testabdeckung ergeben, und zwar auch dann noch wenn unproportional viele manuelle Tester eingestellt werden. Weder von der Menge noch von der Frequenz kann eine Ausführung von Hand auch nur in Ansätzen mit einer automatisierten mithalten. In einer guten Präsentation sollte das berücksichtigt werden, ganz einfach dadurch, dass die rechte, umgekehrte Pyramide erkennbar kleiner ist als die linke:


Das alleine kann zwar noch nicht garantieren, dass in den Managementrunden die notwendigen Erkenntnisprozesse stattfinden, es ist aber ein weiterer Baustein. Einer von mehreren die in Summe die klare Botschaft vermitteln sollen, dass die umgekehrte Pyramide etwas schlechtes ist, etwas, dass man so schnell wie möglich loswerden sollte.

1Natürlich ist das eine sehr stark vereinfachte Form, z.B. könnte es noch eine Ebene für automatisierte Oberflächentests geben.