Funktionale Testautomatisierung begleitet mich mittlerweile, seitdem ich die Universität nach meinem Studium verlassen habe. Für mich war es erhellend, als ich einige Jahre später endlich gelernt hatte – von keinem anderen als Gojko Adzic selbst – was agiles Akzeptanztesten bedeutet, und dass ich mich nicht länger mit den technischen Details herum schlagen sollte, sondern mich stattdessen darauf fokussieren sollte, die Anwendungsdomäne und die Business-Probleme, die unsere Software lösen soll, zu verstehen.

Viele Bücher fokussierten sich zunächst für mich zu sehr auf die Prinzipien hinter dem, was wir als ATDD kennen. Für mich fehlte aber immer ein Teil, der die Brücke zwischen dem Anfänger und dem Experten schlägt. Eine praktischer Guide “machen Sie es so”, der dem Beginner über die ersten Hürden hilft. ATDD in der Praxis will gezielt die Brücke zwischen agilem Testneuling und der Expertenliteratur schließen.

Neben der deutschen Übersetzung des Werkes ATDD by Example finden Sie in der deutschen Ausgabe einige Korrekturen und Updates. Seitdem ich die erste Version des Manuskriptes in englischer Sprache fertig gestellt habe, haben sich einige Neuerungen ergeben, die ich für die deutsche Ausgabe einfliessen lassen habe. Neben den kleineren Fehlern, die noch im englischen Text zu finden waren, habe ich so die zwei Beispiele auf einen technologisch aktuellen Stand gezogen.

Das erste Beispiel hat dabei den Upgrade von Selenium 1 in Ruby zu Selenium 2 erfahren. Die Code-Beispiele sind hier auf den aktuellen Stand der Webdriver-Entwicklung gehoben worden, so dass Sie morgen damit direkt loslegen können.

Das zweite Beispiel ist um Screenshots und Tabellen der aktuellen FitNesse-Version ergänzt worden. Mittlerweile hat FitNesse nämlich ein Face-Lifting bekommen, so dass sich das Wiki von der Benutzbarkeit jetzt auch wie ein Wiki aus dem Jahr 2012 anfühlt, anstatt wie eines aus dem Jahr 2002.

Beide Beispiele wurden zudem für die deutsche Sprache angepasst. Dadurch erhalten Sie auch direkten Kontakt damit, wie Sie Beispiele gezielt auf deutsch ausdrücken können, so dass Ihre Business-Experten diese lesen können und auch langfristig damit arbeiten können.

Die Code-Beispiele sind in einem eigenen Repository auf Github gelandet. Den Code zum ersten Teil, dem Flughafenparkplatz, finden Sie hier. Den Code zur Ampelsteuerung finden Sie hier. Die Beispiele sind dabei bewusst einfach gehalten, damit Sie Sich auf das Erlernen der Vorgehensweise konzentrieren können, und ich nicht zu tief in die Anwendungsdomäne einsteigen muss.

Code Coverage (Branch)

Code Coverage beschreibt, wie viel Code durch Tests abgedeckt ist. Dabei ist für mich die meistens interessante Metrik die Zweigabdeckung (engl.: Branch-Coverage) – im Gegensatz zur Zeilen- und Methodenabdeckung.

Bei der Zweigabdeckung geht es darum, dass alle Bedingungen einmal durchlaufen werden müssen. Für eine 100%ige Zweigabdeckung von folgendem Pseudo-Code bedarf es insgesamt mindestens drei Tests:

if (a || b) {
    c();
}
d();

Im ersten Test sollte a true sein. Im zweiten Test sollte a false und b true sein, und im dritten Test sollten a und b false sein.

Die Zweigabdeckung zählt zu den sog. White-Box Testverfahren.

Einer der oftmals gemachten Fehler mit Codeabdeckung ist, einzig darauf zu achten, dass eine Kennzahl erreicht wird. Viel wichtiger bei der Entwicklung ist allerdings, die sinnvollsten Tests parallel zur Entwicklung zu schreiben, – im Idealfall mit Hilfe von testgetriebener Entwicklung – dabei die Codeabdeckung zunächst nicht zu beachten, und anschließend die Codeabdeckung heranzuziehen, um die Stellen im Code, die noch nicht abgedeckt sind, im Brain-On Modus kritisch zu hinterfragen, ob dafür nicht noch ein automatisierter Test geschrieben werden sollte. Die weiterführende Literatur gibt hierfür noch ein paar weitere Begründungen und Tipps.

Weiterführende Literatur

• How to misuse code coverage von Brian Marick
• Software Engineering Metrics – What do they measure and how do we know? von Cem Kaner und Walter P. Bond
• BBST Foundations Video 4c von Cem Kaner und Becky Fiedler

Lines of Executable Code

Bei Lines of Executable Code wird der Umfang an nicht-Kommentar-Code gemessen, der für das Programm notwendig ist. Wie bei dem berühmten Zitat von Goethe geht es bei gutem Code nicht darum, möglichst viel Code zu schreiben, sondern eher möglichst wenig.

Entschuldigen Sie, dass ich Ihnen einen langen Brief schreibe, für einen kurzen habe ich keine Zeit.

Guter Code lässt sich dadurch erkennen, dass er minimal in Bezug auf Anzahl an Klassen und Methoden ist.

Weiterführende Literatur

• XP Simplicity Rules von Kent Beck
• The four elements of simple design von J.B. Rainsberger

Statische Code-Analyse

Bei der statischen Code-Analyse werden häufig vorkommende Fehler in der jeweiligen Programmiersprache analysiert. Dadurch lassen sich beispielsweise Null-Referenzierungen in Java-Code früh aufdecken, aber auch Paradigmen wie nicht verwendete Variablen oder Quer-Zuweisungen.

Wie bei allen Regeln sollten auch die Regeln für die Code-Analyse nicht mit gedankenlosem Vertrauen verbessert werden. Im Zweifelsfall spreche ich mit meinen anderen Teammitgliedern darüber, was wir hier verbessern können, und welche Fehler wir vielleicht aus unserer Konfiguration entfernen sollten.

Weiterführende Literatur

• Continuous Integration von Martin Fowler
• Static Code Analysis von John Carmack

Zyklomatische Codekomplexität

Die zyklomatische Codekomplexität nach McCabe bildet die Komplexität einer Klasse oder einer Methode in der Source-Code-Basis ab. Jede konditionelle Bedingung erhöht dabei den Wert der zyklomatischen Codekomplexität um 1. Eine Methode der Komplexität 20 besitzt somit 20 Bedingungen. Derart komplexer Code ist in der Regel nur schwer zu warten.

McCabe’s Theorie besagt außerdem, dass für eine Methode oder Klasse der Komplexität N mindestens N+1 Unittests benötigt werden, um eine ausreichende Abdeckung zu erzielen. Eine Klasse der (über alle Methoden aufsummierten) Komplexität 100 benötigt also 101 Unittests, um eine Basisabdeckung für Fehler durch Regressionen (ungewolltes Einbauen von Fehlern) zu verhindern.

Weiterführende Literatur

• Cyclomatic Code Complexity von McCabe

Komponenten-Abhängigkeiten

Zu viele Abhängigkeiten einer Komponente (Klasse oder Paket) deuten auf ein schlechtes Design der Software hin. Die Code-Struktur ist dabei sehr von Änderungen an den Abhängigkeiten betroffen. Sogenannte Ripple-Effekte treten dann bei Änderungen an einer Klasse auf, so dass Änderungen langfristig immer schwieriger werden, da immer mehr Klassen betroffen sind. Diese Abhängigkeiten werden durch das Konzept von Kopplung (engl.: Coupling) und Kohäsion (engl.: Cohesion) ausgedrückt.

Aus diesem Grund sollten Klassen und Pakete wie die Unix-Tools unabhängig von einander sein. Jedes Klasse sollte eine kleine Aufgabe sehr gut erledigen können. Das große Zusammenspiel der kleinen Helfer wird dann durch Dependency Inversion gezielt in die übergeordneten Abstraktionen gegeben, so dass auch diese abstrakteren Komponenten weiterhin testbar bleiben.

Weiterführende Literatur

• von Robert C. Martin
• Dependency Inversion Principle von Robert C. Martin

Abhängigkeitszyklen

Zyklen in der Architektur sind im besten Fall schlecht zu warten, im schlimmsten Fall bedeuten sie Unwartbarkeit für die weitere Entwicklung eines Projekts. Im schlimmsten Fall ist ein sog. Big Ball of Mud entstanden, eine Masse von Spaghetti Code, die das Ende des Projektes andeuten kann.

Aus diesem Grund sind zyklische Abhängigkeiten ein Hinweis auf schlechtes Design und schlechte Architektur. Jedes Klasse und jedes Paket sollte eine klare Abhängigkeitsstruktur besitzen. Im einfachen Fall liegt eine Klasse einfach in dem falschen Paket und der Zyklus kann durch Verschieben der Klasse aufgebrochen werden. Im schlimmeren Fall ist die Abhängigkeitsstruktur innerhalb der Software falsch definiert, und Prinzipien wie Dependency Inversion und Single Responsibility sollten hier Abhilfe schaffen.

Weiterführende Literatur

• Acyclic Dependencies Principle von Robert C. Martin

Zum Glück stolperte ich Anfang 2008 über einige Word-Dateien im Internet, die mir bei der Beantwortung der Fragen helfen konnten. Ich verschlung die Draft-Kapitel für ein neues Buch regelrecht und konnte es kaum erwarten, das nächste Kapitel zu lesen. Den Autorinnen schickte ich währenddessen stets Mails mit meinen Anmerkungen und Korrekturen, damit daraus ein noch besseres Buch werden konnte. Als ich ein Jahr später das erste Mal das ganze Werk in den Händen hielt, hatte ich bereits etliches von den Praktiken und Techniken in die Tat umgesetzt und in meiner Testgruppe etabliert.

Insider wissen an dieser Stelle bereits, dass es sich um kein anderes Werk als Agile Testing – A practical guide for testers and agile teams handelt. Zugegebenermaßen ist es ein sehr umfangreiches Buch mit über 500 Seiten geballter praktischer Anleitung – nicht zum Testen in agilen Projekten, sondern zu den Softskills. Lisa Crispin und Janet Gregory geben eine praktische Einführung und Orientierung für alle, die wie damals ich die große Frage haben: “Wie soll das denn alles in dieser unglaublich kurzen Zeit gehen?”

Meine Kollegin Meike Mertsch sucht nach Unterstützung, um dieses Buch ins Deutsche zu übersetzen. Dabei geht es weniger, um Übersetzungshilfe, sondern um Interesse am Buch. Wenn Sie also ein Tester in einem agilen Projekt sind, dessen Interesse ich jetzt geweckt habe, wenn Sie ein Testgruppenleiter sind, der seinen Testern praktische Hilfestellung an die Hand geben will, wenn Sie ein Entwickler in einem agilen Projekt sind, und nicht wissen, wie Sie Ihre Tester noch näher an die Entwicklung bringen können, dann wird sich Meike sicherlich darüber freuen, wenn Sie ihr einen Hinweis hinterlassen, wie eine deutsche Version von Agile Testing für Sie nützlich sein könnte.

Testen im zweiten Quadranten

Seit einiger Zeit beschäftigt mich die Erkenntnis, dass es den meisten Testern schwierig fällt, wie sie ein Entwicklungsteam konstruktiv unterstützen können. In meinen Schulungen schlägt sich das bei der Testquadranten-Übung stets so nieder, dass bei einem Brainstorming von Aktivitäten der zweite Quadrant der agilen Testquadranten verhältnismäßig leer bleibt. Bei der Übung frage ich Tester danach, welche Aktivitäten und Testmethoden sie kennen, und lasse sie diese auf die vier Testquadranten nach einer kurzen Einführung mappen. Der Bereich um die technisch-orientierten Tests, die dem Team weiterhelfen, sowie die geschäfts-orientierten Tests, die das Produkt kritisieren, ist dabei sehr klar. Genauso der vierte Quadrant mit technisch-orientierten Tests, die das Produkt kritisieren. Der Bereich um geschäftlich-orientierte Tests, die dem Team helfen sollen, allerdings ist meistens sehr leer.

Ich führe das auf eine Fehleinschätzung aus der traditionellen Testlehre zurück. Diese Miskonzeption beruft sich darauf, dass Tester und Entwickler unabhängig von einander sein sollten. Schließlich kann ein Entwickler mit seinem Positivismus den kritisch-denkenden Tester dahingehend beeinflussen, dass er nicht so ausführlich testet oder aus Gefälligkeit den Entwicklern gegenüber nicht so gründlich ist. Natürlich besteht die Gefahr eines derartigen kognitiven Bias, doch wie hoch sind die Kosten, wenn ich Tester und Entwickler davon entmündige, selbst aus ihren Fehlern lernen zu können?

Ich habe Firmen gesehen, in denen es verboten war, dass Programmierer mit Testern sprechen. Dort flossen alle Informationen über das Bugtracking-Tool, jenseits von jeglicher menschlichen Nähe, mit all den negativen Konsequenzen wie einer Blaming-Kultur, Misstrauen und sog. Information Hiding. Mit Abstand betrachtet floss in diesen Unternehmen mehr Energie darin, fehlerfrei auszusehen, als dass gute Arbeit geleistet wurde. Oh, und natürlich müssen Biological Testing Units stets ausgelastet sein, damit sie die höchste Produktivität erreichen können.

Auf der anderen Seite habe ich Teams gesehen, die den Sprung von räumlich getrennten Testern hin zu vollständig co-located Teams gemacht haben. Auch wenn der Tester nur zwei Räume weiter saß, haben sich dramatische Verbesserungen ergeben, wenn der Tester beim Team sitzen konnte. Auf einmal war Pro-Aktivismus nicht nur beim Stand-Up offensichtlich. Der Tester konnte auch öfter Teammitglieder um Hilfe bitten, und langfristig entwickelte sich ein Vertrauensverhältnis zwischen Entwicklern und Testern.

Letzten Endes ist es eine dramatische Falle zu glauben, nur weil Tester und Entwickler nicht miteinander reden dürfen, seien Tester unabhängiger. Das gleiche Argument kann ich zum Beispiel auch anführen, wenn Tester andere Dokumentation über das Projekt bekommen, andere Statusberichte abliefern müssen und andere Kunden als Ansprechpartner haben. Dann wären sie doch vollends unabhängig von den Entwicklern. Tester zu entmündigen, indem man ihnen die Fähigkeit aus Fehlern zu lernen, abschreibt, ist in meinen Augen das Nummer eins Problem in der Softwareentwicklung. Dadurch entmündigt man nicht nur erwachsene Menschen, man bevormundet sie auch. Natürlich alles im Namen der Qualität. Doch was ist das eigentlich? Qualität?

Qualität ist Mehrwert für jemanden

“Qualität ist, was immer mir gefällt” könnte ein passender Ausspruch sein. “Ich erkenne Qualität, wenn ich sie sehe” ist ein vergleichbar schwammiges Statement. Jerry Weinberg hat in den 90er Jahren mit seinem Zitat “Quality is value to some person” den Nagel auf den Kopf getroffen. Mehrwert für einen User kann weniger Wert für einen anderen bedeuten. Beispielsweise wollen wir cross-site scripting Attacken unterbinden, damit die zahlenden Kunden trotzdem noch unsere Applikation verwenden werden, aber Hacker ausgesperrt sind.

Bei der Softwareentwicklung geht es darum zu identifizieren, auf wen wir bei der Qualitätsbetrachtung achten sollen, und unterschiedliche Bedürfnisse gegeneinander abzuwägen. Tester liefern hier einen großen Mehrwert mit ihrer Fähigkeit, kritische Fragen richtig stellen zu können. Sie sind in der Lage Fehlerszenarien zu erdenken, bevor sie ein (unerwünschter) User des Systems haben kann. Doch dafür müssen sie früh eingebunden sein – idealerweise zeitgleich mit dem Rest des Entwicklungsteams, wenn nicht sogar noch früher.

Aber man kann doch erst nach der Fertigstellung testen!

Falsch. Ich kann bei der Anforderungsanalyse, im Spezifikations-Workshop, beim Coding und nach der Fertigstellung der Software testen. Dafür habe ich gelernt, die richtigen Fragen zur richtigen Zeit zu stellen. Manchmal lerne ich neu, dass ich gewisse Fragen etwas mehr zurückstellen muss, oder erstmal ein generelles Bild für das kommende Release entwickeln muss, bevor ich sie stelle. In jedem Fall kann ich nicht nur testen, wenn der Code fertig ist, und ich eine fertige Applikation habe. In jedem Fall kann ich immer etwas lernen, wenn ich mir selber einen Ruck gebe, und noch eher einsteige, als mein persönliches Wohlbefinden für richtig erachten würde.

Mein Hauptkritikpunkt liegt hier wieder in der Entmündigung von Testern durch vorgegebene Testskripte in Form von sog. strukturierter Testfallanalyse und Testplänen, die letzten Endes nur die Freiheit des erwachsenen Testers einschränken. Doch dadurch lässt sich ja die Anforderungsabdeckung haargenau nachvollziehen. Noch viel trauriger ist allerdings, dass wir kein anderes Mittel als die kreative Einschränkung durch Testskripte kennen. Natürlich ist die Alternative von Explorativem Testen, die in den meisten Firmen in Deutschland gelebt wird, noch viel schlimmer. Das liegt aber doch nicht daran, dass Exploratives Testen böse ist, sondern dass wir Tester stets entmündigen müssen, so dass sie nicht lernen und daran arbeiten, ihre Fähigkeiten zu verbessern und besser explorativ testen zu können. Auch hier habe ich bereits signifikante Verbesserungen erlebt dadurch, dass ich ein paar wenige Hinweise für besseres exploratives Testen wie session-basiertes Testmanagement, ein Low-tech Testing Dashboard oder auch einfach nur Testcharter für individuelle Testaktivitäten gegeben habe.

Tester können doch nicht programmieren

In meinen Augen einer der schlimmsten Sünden ist, dass wir Testern absprechen, neue Fähigkeiten lernen zu können, ja sogar lernen zu wollen. Programmierer konnten auch nicht immer programmieren, trotzdem haben sie es irgendwann gelernt. Noch viel schlimmer ist es, dass ich im vergangenen Jahr von einem Entwickler gehört habe, der an seinen Schreibtisch ging, seinen Arbeitsvertrag herausholte, und meinte: “Da steht nichts von Unittesten drin!” Vergleichen Sie Ihre Reaktion einmal mit der folgenden Geschichte, die ich vor ein paar Woche hörte: Ein Tester geht an seinen Schreibtisch, holt seinen Arbeitsvertrag raus, und meint: “Da steht nichts von Programmieren drin!” – Wieso ist Ihre Reaktion auf einmal gänzlich anders?

Tester können lernen zu programmieren. Man muss ihnen häufig nur die Angst davor nehmen. Das kann man zum Beispiel dadurch schaffen, dass man Pair Programming einsetzt, und ein Tester so sein Testwissen gezielt an einen Entwickler beim Unittesten weitergibt, und dabei ein paar neue Kenntnisse über das Programmieren vom Programmierer erlernt. Mein Vater sagte mir einmal, dass er kurz nach seiner Ausbildung gelernt hat, dass er im Leben nie auslernen wird. Mein Vater war Automechaniker, und nach der Ausbildung in den 70ern, musste er sich mit immer mehr technologisierten Maschinen auseinandersetzen. Seitdem weiss ich, dass mir das ähnlich gehen wird, und ich versuche kontinuierlich meine Grenzen zu erweitern. Dieses Mindset vermisse ich in den meisten Softwarefirmen.

Holistische Sicht

Alles in allem fehlt es uns in Deutschland an einer holistischen Sicht auf die Arbeit, die wir tun. Dadurch dass wir die Wände zwischen Programmierern und Entwicklern so künstlich aufrechterhalten, entmündigen wir nicht nur unsere Tester, nein, wir geben ihnen sogar Futter dafür, in ihrer jeweiligen Komfortzone zu einem Ten-to-Four-Worker zu mutieren, der das Ende seiner Karriereleiter verwirkt hat. Schade. Dabei haben wir so ein großes Potential, das wir nicht zu nutzen wissen. Denn letzten Endes kommt es als Team darauf an, dass wir ein funktionierendes System ausliefern können – und das in agilen Projekten in jeder Iteration. Wenn wir das nicht hinbekommen, können wir unsere Aufwände auch gleich sein lassen – denn sie sind nichts weiter als verschwendete Zeit, wenn wir es nicht hinbekommen, in zwei Wochen die Software nicht nur zu entwickeln, sondern auch durch gutes Testen ausreichend beleuchtet zu haben, dass wir sie ruhigen Gewissens ausliefern können.

Im Extreme Programming gibt es eine weitere Praktik, auf die ich gestern gar nicht eingegangen bin: die sog. Zero-Bug Policy. Beim Bestellen in einem Restaurant fiel mir vor kurzem auf, dass der Kellner einen Fehler bei der Aufnahme der Bestellung gemacht hat, den obersten Zettel seines Notizblocks abriss, und alles noch mal von vorne aufschrieb. Das nennen wir in der agilen Softwareentwicklung die Zero-Bug Policy. Wir geben uns nicht mit “wenig” Fehlern zufrieden, sondern wir legen unseren Maßstab so hoch, dass wir null Fehler zulassen.

Von dieser Denkweise ausgehend bekomme ich Sorgenfalten (und graue Haare, die ich dann auf meine Frau schieben kann), wenn mich jemand danach fragt, ob dann nicht 80% durchlaufende Tests in Ordnung sind. Nein, das sind sie nicht. 80% Tests bedeutet, dass wir 20% Risiko eingehen, dass etwas an unserer Software nicht funktioniert. Für ein 5 Euro Projekt wären das 20 cent, aber für ein 5 Million Euro-Projekt stehen immerhin 200.000 Euro auf dem Spiel. Für diesen Betrag kann ich als Privatperson ein ganzes Haus kaufen! Das Risiko ist es mir als professioneller Softwareentwicklung nicht wert einzugehen.

Die Messlatte für unsere Unittests sollte bei 0 insgesamt liegen. Jeder Test, der fehlschlägt, weist uns sehr deutlich auf ein Problem hin. Wenn wir diese Anzeichen ignorieren, weil wir neue Funktionalität bauen wollen, dann hilft uns das nur kurzfristig weiter. Langfristig wissen wir nach wie vor nicht, wo wir mit unserem Projekt überhaupt stehen. Das ist nicht nur schlecht, sondern führt auch den Sinn von Continuous Integration ad absurdum. Transparenz ist einer der höchsten agilen Werte, und wir sollten nicht die Augen davor verschließen, was uns diese Transparenz versucht mitzuteilen.

Entweder geht es darum, dass die fehlschlagenden Tests uns mitteilen wollen, dass wir ein Problem in unserer Software haben. Dann sollten wir das so schnell wie möglich im Sinne einer Zero-Bug Policy lösen, und wieder zu einem potentiell auslieferbaren Zustand kommen. Das schaffen wir nur, wenn wir das Problem auch beheben.

Vielleicht liegt es aber auch daran, dass unsere Tests auf Deutsch gesagt sch… sind. Hurra! Wir können was lernen! Dann sollten wir uns auch daran setzen, dass wir uns überlegen, was wir daraus schließen können. Lag es daran, dass unsere Tests auf einem Anfängerniveau geschrieben wurden? Dann sollten wir überlegen, ob wir die Tests jetzt neu schreiben, wo wir mehr Erfahrung bekommen haben, oder sie ganz und gar entsorgen. Derzeit scheinen sie uns nur echte Probleme zu verschleiern, aber den Build bei 80% erfolgreich laufen zu lassen erscheint mir da die falsche Reaktion zu sein.

Zu guter Letzt könnte es noch sein, dass unsere Tests nicht gepflegt werden. Dann ist aber doch ein erfolgreicher Build nur eine Verschleierungstaktik, um von den wirklichen Problem abzulenken. Letzten Endes wird dann Pareto CI nur dazu ausgenutzt, dass ich auf meine Probleme nicht mehr hören muss. Für mich verstösst das grob gegen die Prinzipien von Offenheit und Transparenz in agilen Projekten. Ich würde sogar so weit gehen, und eine derartige Taktik alles andere als agil nennen. Das Team nimmt sich jede Chance sinnvoll aus Fehlschlägen zu lernen. Schade.

Doch wo liegen die Vorteile für einen ProductOwner bei 100% durchlaufenden Tests, TDD und Pair-Programming? 2009 hörte ich von Elisabeth Hendrickson die Geschichte eines Projektes, in dem 60% Staff-Rotation vorherrschte. Dort war es normal, dass jemand anderes in den nächsten zwei Wochen in das Projekt kam. Wie haben die überlebt? Durch test-getriebene Entwicklung und Pair-Programming!

Durch langfristigen Einsatz von CI, TDD und Pairing erhalte ich eine Code-Basis, die von allen verstanden werden kann. TDD und Pairing führen mittelfristig dazu, dass ich ein gemeinsames Verständnis von gutem Code erhalte, und ein gemeinsames Verständnis einer testbaren Code-Basis entsteht. Dabei spielen Wechsel von Teammitglieder irgendwann anscheinend nur noch eine untergeordnete Rolle.

Könnt Ihr unser Projekt auch so einrichten, dass der Build erst bei 80% fehlschlagenden Tests fehlschlägt?

Kürzlich fand ich mich mit dieser Frage konfrontiert. Bei aller Liebe musste ich mich kurz daran erinnern, dass es sicherlich einen gerechtfertigten Grund für diese Reaktion auf die kürzlichen Buildergebnisse gab. Alles in allem machte das aber nicht so wirklich Sinn für mich. Hierzu würde ich gerne eine etwas längere Erklärung geben.

Continuous Integration (CI) gehört anscheinend nach wie vor zu den am häufigsten missverstandenen Praktiken der XP-Kultur. Letzten Endes bedingt CI, dass ich einen automatisierten Build besitze, der mir innerhalb von 10 Minuten Feedback zu jeglichen Code-Änderungen liefert, und im Idealfall auch in der gleichen Zeit meine automatisierten Akzeptanztests ausführt. Im schlechtesten Fall laufen die Akzeptanztests in einem eigenen Staged-Build, der höchstens 3 Stunden dauern sollte.

Viele Teams bekommen das leider nicht hin. Dabei mangelt es vor allem an essentiellen Dingen wie einem vollautomatisierten Build (und damit meine ich nicht, die Konfiguration von Buildschritten in Jenkins), Unittests, die zu viel und zu unfokussiert testen, und schlechte oder gar keine Akzeptanztests.

10 Minuten Build

Ein Build sollte vollautomatisch durch einen Befehl ausgeführt werden können. Ein Kommando wie ant tests ist dabei genau so ein Befehl wie mvn release oder make -Dintegration. Nicht ok sind Builds, die ausschließlich aus der IDE oder dem Jenkins kommen, denn sie sorgen dafür, dass ich bei neuen Teammitgliedern viel Zeit in die Einarbeitung stecken muss. Außerdem führen nicht einheitliche IDEs dazu, dass ich stets Aufwand und Zeit in die Fehleranalyse stecken muss.

Zum gleichen Punkt zählt für mich auch, wenn ganze Buildketten ausschließlich über den CI-Server gebaut werden können, weil nirgendwo sonst die einzelnen Buildschritte abgebildet sind. Damit nimmt sich jedes Projektteam die Möglichkeit, auf Störungen im Build-System einzugehen, bzw. Änderungen lokal zu bauen. Klar, die Integrationsumgebung sollte einen definierten Stand haben, aber das Frontend-Team sollte nicht dadurch blockiert werden, dass der Build-Server wegen zu geringer Rechnerkapazitäten stundenlang benötigt, um einen Build vom Backend einzuspielen. In meinen Augen hat jeder ProductOwner an dieser Stelle ein gerechtfertigtes Interesse daran, ein professionelleres Arbeiten seines Entwicklungs-Teams zu verlangen.

Unfokussierte Unittests

Doch wie kommen überhaupt mehrstündige Builds zustande? Häufig sind sog. Integrationstests einer der Hauptgründe dafür. Ich persönlich hasse diesen Begriff, da bei dem Therm Integrationstest nicht klar ist, was integriert wird. Sind es einzelne Klassen? Module? Subsysteme? Alles auf einmal? Ich spreche hier von Tests, die lang sind, viele Abhängigkeiten besitzen, und mehr als eine Klasse heranziehen. Beim Editieren meines Kapitels zu How to reduce the cost of software testing erinnerte mich Michael Hill deshalb auch daran, dass wir Unittests besser Mikrotests nennen sollten – also sehr, sehr kleine fokussierte Tests. Diese bieten den Vorteil, dass sie schnell durchlaufen und im Idealfall innerhalb von Millisekunden Feedback liefern können.

Die Rechnung ist einfach. Nehmen wir an, wir haben eine Codebasis von 10.000 Klassen. 10.000 Klassen ist im Vergleich zu den meisten Projekten, die ich gesehen habe, nicht viel. Nehmen wir weiterhin an, dass diese 10.000 Klassen klein genug sind, um mit 20 Tests sinnvoll abgedeckt zu sein. Damit hätten wir 200.000 Tests für unser ganzes Projekt. Wenn die Tests jetzt im Durchschnitt eine Sekunden benötigen, dann bekommen wir eine Gesamttestsuite, die 55 Stunden zum Durchlaufen benötigt. Im Ernst: Würden Sie so eine Testsuite regelmäßig ausführen? Genau! Sie würden Sich im Blindflug befinden.

Wenn wir jetzt statt unfokussierter Integrationstests Mikrotests implementieren, dann bekommen wir schnelles Feedback. Nehmen wir mal 10 msek. pro Test an. Dann erhalten wir eine Testsuite, die in 2000 Sekunden durchläuft. Das sind ca. 33 Minuten. So eine Testsuite würde man doch schon etwas häufiger ausführen. Allerdings auch nicht bei jeder kleinen Änderung. Wenn wir die Zeit pro Mikrotest auf 1 msek. bekommen können, dann sind wir aber bereits bei ca. 3 Minuten. 3 Minuten, das klingt schon eher nach einer Testsuite, die ein Team regelmäßig ausführen würde.

Insgesamt könnte so ein Build auch unter 10 Minuten bleiben, inklusive dem Ausführen von sämtlichen Unittests. Aber dafür bedarf es schon einiger technischer Exzellenz. Letzten Endes muss das Team Testautomatisierung beherrschen, emergente Architekturen kennen und auch das Design muss eine testbare Flexibilität mitbringen. Ansonsten werden sie eher langläufige Intgrationstests schreiben können.

Fehlende Akzeptanztests

Wie Jerry Weinberg in Perfect Software …and other illusions about testing beschreibt, genügen Mikrotests allein nicht. Jeder der das glaubt, unterliegt der Decomposition Fallacy. Über Mikrotests hinaus benötigen wir Akzeptanztests, die das Zusammenspiel der einzelnen Komponenten durchspielt. Dabei wollen wir uns auf die fachlichen Begriffe fokussieren, anstatt der eher technisch fokussierten Mikrotests. Akzeptanztests und Mikrotests formen ein symbiotisches Sicherheitsnetz, das es dem Team ermöglicht, kontinuierlich neue Features in gleichbleibender Geschwindigkeit zu liefern.

Meistens benötigen Akzeptanztests länger als Mikrotests. Mit einem idealen Gemisch aus Akzeptanz- und Mikrotests gelingt mir aber der Trade-Off zwischen technischer Exzellenz und fachlichen Anforderungen. Während mir die Mikrotests schnelles Feedback geben, benötige ich aus fachlicher Sicht nur noch wenige Akzeptanztests, die mir die Lücken End-to-End schließen. Eine breite Testbasis aus Mikrotests hilft mir also dabei, auch weniger langläufige Akzeptanztests auf mich zu nehmen. Im Idealfall kann ich 95% Code Coverage erreichen, während mein gesamter Build nach wie vor unter 5 Minuten benötigt. Wie häufig würden Sie in einem solchen System Ihre Tests ausführen? Wie schwer wäre es, wenn Sie Sich in so eine Codebasis neu einarbeiten müssten? Denken Sie mal drüber nach, was 5 Minuten bis zum Feedback darüber, ob ich gerade einen Fehler in das System eingebaut habe, hier bedeuten können.

Langer Rede, kurzer Sinn: Wenn ich meine Programmierer derart unter “Feature-Druck” setze, dass sie die Scheuklappen für Neulieferung von Features aufsetzen, dann muss ich mich nicht wundern, wenn Dinge wie technische Exzellenz, gute Unittests und ein 10-Minute Build auf der Strecke bleiben. Das mag zwar kurzfristig Vorteile haben, langfristig baue ich mir aber einen Haufen technische Schulden auf, die mir mittelfristig eine steile Aufwandskurve bringen werden. Der einzige Weg, schnell voranzukommen, ist eben doch der Weg, dass ich vernünftig voranschreite.

Im Kern ging es um einen Effekt, den ich bereits vor einigen Jahren in einem ganz anderen Kontext erlebt hatte. Um mein Studium zu finanzieren, arbeitete ich in einem Kaufhaus als Verantwortlicher für alkoholfreie Getränke, Bier, und später auch Wein, Sekt und Spirituosen. Ich war lange Jahre dafür verantwortlich, dass die Regale gefüllt waren, die Reste nachgeräumt wurden am Wochenende, und ich für die kommende Woche eine neue Bestellung gemacht hatte.

Für das “Trockensortiment” hatten wir dafür zwei Ordersätze zu je ca. 120 Seiten. Ich war mit den Getränken zuletzt für rund 40 dieser Seiten zuständig. Auf jeder Seite befanden sich ca. 30 Artikel, die wir bestellen konnten. Cola-Dosen 0,33l und 0,5l, Cola-Flaschen 1l, Beck’s Pilsener im 6er-Träger und in der 0,5l Dose. Jede Woche kostete mich die Bestellung ca. 45-60 Minuten meiner Arbeitszeit.

Eines Tages teilte mir mein damaliger Abteilungsleiter mit, dass er nach 9,5 Jahren in dem gleichen Markt weiterkommen wollte, und den Laden wechseln werde. Da ich sehr eng mit ihm zusammengearbeitet hatte, und wir auch nach der Arbeit öfter mal zusammen essen waren und uns privat verstanden, fiel ich etwas aus allen Wolken. Nach heutigem Stand ist mir bewusst, dass ich von einem sog. “foreign element”, wie Virginia Satir es in ihrem Change-Modell genannt hat, getroffen wurde.

Nun sollte natürlich ein neuer Abteilungsleiter kommen. Dieser setzte sich nicht so vehement gegenüber dem Chef von dem Laden ein, so dass der oberste Chef eine Änderung in den kommenden Monaten etablieren konnte. Bis heute weiß ich leider nicht, worauf diese Idee beruhte, aber auf den ersten Blick sieht sie einfach aus: Die beiden Abteilungsleiter sind fortan für die Bestellung zuständig, alle anderen verräumen nur noch die Ware.

Wie mit jeder Regel gab es auch hier Ausnahmen. Dazu zählte unter anderem ich, der weiterhin seine 40 Seiten durcharbeiten durfte. In anderen Bereichen waren fortan die Abteilungsleiter damit beschäftigt, die Bestellungen zu machen: Konserven, Müsli, Tiernahrung, Fertigsuppen. Die Stellvertretung vertraute mir einmal an, dass se dafür ca. 4 tunden ihrer Zeit benötigte.

In den kommenden Monaten und Jahren kam ich mehr und mehr dazu, auch andere Bereiche zu verräumen wie z.B. Konserven. Dabei machte ich dann folgende Beobachtung. Ich erinnere mich noch daran, dass es bei den Backzutaten zwei Schokosaucen vom gleichen Hersteller gab. Einmal 750ml und einmal 500ml (oder so ähnlich). Über Wochen beobachtete ich, dass in der Weihnachtszeit die große Schokosauce leer war. Ich hätte jetzt jede Woche die große Schokosauce bestellt. Das macht ja schließlich auch Sinn: Ware leer, Ware wird neu bestellt.

Ich bemerkte allerdings, dass jede Woche auf’s neue die kleine Schokosauce kam, die aber bereits im Regal voll war. Also kam die neue “Einheit” hinten direkt aufs Lager. Ich gebe zu, ich habe einmal die vier neuen Einheiten ins Regal gestellt, weil mich das aufgeregt hat. Die standen dann so hoch, dass kein Kunde mehr dran kam. In der Folgewoche kamen vier neue Einheiten mit sechs neuen Flaschen jeweils.

Was war hier passiert? Die zwei Kollegen, die 200 Seiten Ordersatz jede Woche bestellen mussten, waren mit dem großen Produktkatalog derart überlastet, dass sie schnell durch jede Seite gehuscht sind, und nicht immer sorgfältig auf die Einheitsgröße geachtet haben. Dadurch kam es zu sehr vielen Fehlbestellungen, die Lagerbestände gingen hoch, die Produkte im Regal liefen zum Teil ab, Kunden beschwerten. Als kleine Randnotiz habe ich Ende letzten Jahres erfahre, dass selbiger Laden im März diesen Jahres geschlossen werden soll. Diesen gibt es also heute nicht mehr.

Dort, wo ich und auch andere Kollegen weiterbestellen konnten, hingegen, blieben die Lagerbestände Saison bedingt normal. Also kurz vor Vatertag gab es immer noch mehr Bierreste im Lager, aber ansonsten war das Lager normal gefüllt. Wie kam es zu diesem Effekt?

Zwei wichtige Bedingungen trafen hier zusammen. Das Feedback der Warenlieferung an denjenigen der bestellte, war verschwunden. Zuvor war jeder für seinen Bereich zuständig, und konnte somit selbst von seinen Fehlern lernen. Wenn er etwas zu viel bestellt hatte, dann passierte das maximal ein weiteres Mal, dass das nochmal falsch geliefert wurde. Doch dann wurde das jeweilige Produkt für mehrere Wochen einfach nicht mehr bestellt. Oftmals strich ich schon in weiser Voraussicht zwei Wochen auf einmal im Ordersatz durch, weil ich genau wußte, dass ich den Artikel erstmal nicht bestellen muss. Bei der Massenbestellung aber fehlte denjenigen, die bestellten, das Feedback von der Lieferung. Die beiden Abteilungsleiter waren nämlich derart unter Zeitdruck neue Bestellungen zu machen, dass sie die neue Ware nicht verräumten, und somit nicht mitbekamen, was falsch bestellt worden war.

Ab und an räumten aber die beiden Abteilungsleiter auch mal Reste nach. Da hätten sie sehen können, dass da etwas viel von der einen Sorte geliefert wurde. Doch in der Hektik der Bestellung (diese musste bis 14 Uhr in der Zentrale übertragen sein, damit die Ware zwei Tage später auf dem Hof stand), war diese Erkenntnis wieder verloren. Vielleicht war es auch eine Abwandlung des Student-Syndroms, aber der Zeitdruck für die Bestellung reichte aus, um all das wieder zu vergessen.

Als ich mein Studium fertig hatte, und das erste Mal in der IT arbeiten durfte, verwunderte mich, dass wir mit Ansätzen wie “der Testmanager schreibt ein Testfalldokument, dass die Tester dann durchführen können” genau so ein Verhalten an den Tag legen.

Was hat das alles jetzt mit dem Lernen bei der it-agile zu tun? Intern hatten wir fast schon eine Hetzjagd darüber, dass Taylorismus für das Trennen von Denken und Handeln stünde, und Taylorismus das Grundübel allen Managements sei. Wie beim Identified Patient Syndrom war alles, was auch nur im Anklang nach Trennung von Denken und Handeln aussah Teufelswerk und die Befürworter davon wurden nahezu gekreuzigt. (Ich übertreibe hier etwas.)

Die Situation wurde besser, als ein Kollegen (danke Arne) tatsächlich das frei verfügbare Werk von Frederick Taylor einmal gelesen und für uns zusammen gefasst hat. Auf einmal konnten wir wieder vernünftige – im Sinne von Vernunft getriebene – Diskussionen führen.

Was hat mich das alles gelehrt? Mich hat das vor allem an das Gesetz von Loftus:

Some people manage by the book even though they don’t know who wrote the book or even which book it is.

(Gerald M. Weinberg, More Secrets of Consulting, Dorset House, Seite 40)

Diesen Ausspruch will ich sogar noch weiter transportieren als nur zum Management. Einige Tester testen nach der reinen Lehre, obwohl sie nicht wissen, wer diese Lehre verteilt hat, in welchem Zusammenhang dieser Vorschlag entstand, oder wie das entsprechende Buch oder Verfahren dazu heißt. Einige Programmierer programmieren (und designen) nach der reinen Lehre, obwohl sie nicht wissen, wer diese Lehre vertritt, in welchem Zusammenhang das Vorgehen Sinn macht, oder in welchem Buch es vorgestellt wird.

Wissen Sie, woher ihr derzeitiges Vorgehen kommt?

Markus Gärtner: 20 Tage im Start-Up March sind nun vorbei. Was habt Ihr gelernt?
Manuel Küblböck: Das Einholen und die Interpretation von Benutzer-Feedback ist verdammt schwer. Insbesondere am Anfang eines Projekts, wenn man nur sehr wenige bis keine Benutzer hat. Ein Werkzeug zu bauen, dass nicht unbedingt massen-kompatibel ist, erschwert das ganze noch zusätzlich. In diesem Fall ist es wohl besser mit Einzelpersonen zu sprechen, als zu versuchen statistisch irrelevante Ergebnisse zu interpretieren.
Stefan Roock: Jede Menge, ich weiß gar nicht, wo ich anfangen soll. Ich finde besonders erwähnenswert insbesondere bezogen auf den Startup-Anteil unserer Arbeit:

• Der Ansatz, Annahmen über quantitative Daten zu belegen hat deutliche Grenzen. Erstens kann man seine Annahmen in der Regel nur belegen, aber nicht widerlegen. Wenn kein Mensch mein System benutzt, kann es bedeuten, dass es keinen Wert schafft. Vielleicht war aber auch einfach nur mein Marketing schlecht. Außerdem funktionieren quantitative Analysen schlecht, wenn man in der Anfangszeit nur wenige Benutzer hat. Ich glaube, wir haben am Anfang zu sehr auf die (nichtssagenden) Daten geguckt und haben zu spät den direkten Kontakt mit den tatsächlichen Anwendern gesucht.
• In diesem Zusammenhang ist mir auch klar geworden, dass man bei einem Experiment nicht nur designen muss, wie man die Annahmen prüfen will. Man muss auch die Annahmen “designen”. Was uns nämlich zuerst so als Annahme eingefallen ist, war letztlich viel zu groß.Wir hatten am Anfang die Annahme, dass Kategorien ein Unique Selling Point für Discuss2Decide sein könnte. Da hängt aber zuviel dran: Erstmal müssen wir viele Leute auf die Platform kriegen. Dann müssen wir viele von denen dazu kriegen, dass sie tatsächlich Diskussionen anlegen und dann müssen viele von denen dauerhafte Nutzer des Systems werden. Da sind für den Anfang einfach zu viele “wenns” drin. Besser wäre gewesen, die Annahme kleiner zu halten, z.B. “Wir finden einen Benutzer, der Kategorien so nützlich findet, dass er nur deshalb regelmäßig Discuss2Decide benutzt. Diese Annahme hätte man belegen und sogar widerlegen können und es hätte auch einen klaren Fokus für das Vorgehen gegeben.

Markus Gärtner: Discuss2Decide, DiscuMeter, welche weiteren Produkte sind entstanden?
Stefan Roock: Es ist bei diesen beiden Produkten geblieben. Obwohl wir uns anfänglich mit DiscuMeter besser gefühlt haben als mit Discuss2Decide war die Benutzerresonanz zu Discuss2Decide größer. Daher haben wir dort den größten Aufwand investiert und in Discuss2Decide mit sehr vielen weiteren Features und Zielgruppen experimentiert. Vielleicht wird es irgendwann eine Integration von DiscuMeter in Discuss2Decide geben.
Manuel Küblböck: Wir haben uns darauf fokussiert discuss2decide zu verbessern und kein weiteres neues Werkzeug erstellt. DiscuMeter findet sich nicht direkt darin wieder, die Idee davon kann man aber im Awareness-Feature von discuss2decide erkennen. Man kann jetzt sehen wer wann das letzte Mal an einer Diskussion teilgenommen hat und wann gegebenenfalls jemand eine Diskussion explizit verlassen hat. Wir haben somit an der Hypothese festgehalten, dass wir mit einer Diskussionsplattform ein relevantes Problem lösen. Wir hatten natürlich einige weitere Hypothesen im Verlauf der letzten beiden Wochen. Zum Beispiel, dass wir mehr Leute auf die Seite bekommen, indem wir eher “triviale” Diskussionen wie “Wo gehen wir heute Abend hin?” vorschlagen und diese auf Facebook bewerben.

Markus Gärtner: Welche Hypothesen hattet Ihr auf dem Weg dorthin?
Stefan Roock: Jede Menge und wie oben ausgeführt, könnten wir durch einen zu starken quantitativen Fokus viele davon weder belegen noch widerlegen. Trotzdem gab es viele Erkenntnisse.

• Wir hatten z.B. die Annahme, dass Kategorien (z.B. Annahme, Fakt, Meinung etc.) in Beiträgen die Diskussionen übersichtlicher machen. Das ist nicht der Fall. Allerdings hatten die Kategorien einen interessanten Seiteneffekt. Die Autoren haben fokussiertere und kürzere Beiträge in Diskussionen geschrieben. Daher sind die Kategorien nach wie vor im System.
• Wir hatten die Annahme, es sinnvoll ist, explizit die Konvergenzphase in Diskussionen zu unterstützen. Dazu haben wir Same-Different, Umfrage-Übersichten und Zusammenfassungen implementiert, die auch als nützlich empfunden werden.

Markus Gärtner: Wie geht’s weiter? Habt Ihr einen Investor gefunden, und könnt Euch die nächsten 30 Jahre zur Ruhe setzen?
Manuel Küblböck: Ja, Gott sei Dank, muss ich Montag nicht mehr zur Arbeit erscheinen :) Im Ernst, nein, wir haben (noch) keinen Investor. Unser Geschäftsmodell ist derzeit darauf ausgelegt, dass wir in Zukunft geschlossene Gruppen ein Bezahl-Feature machen. Wir werden das Projekt aber zunächst weiterhin in Freizeit und Slack voran treiben.
Stefan Roock: Nein, wir haben keinen Investor gefunden. Wir haben aber abgefahrene Ideen, was wir mit dem Geld tun würden, wenn uns jemand das System abkaufen würde. Dabei geht es nicht um den persönlichen Reichtum der Teammitglieder, sondern etwas viel cooleres. Aber das verraten wir erst, wenn jemand ausreichend Geld auf den Tisch legt :-)

Markus Gärtner: Was habt Ihr über Lean Start-Up und Agile Software Entwicklung gelernt? Was werdet Ihr zukünftig bei Eurer Arbeit anders machen?
Stefan Roock: Wir haben im Team kein Vorgehen a la Scrum oder Kanban vereinbart. Das Vorgehen hat sich herausgebildet und war weder Scrum noch Kanban. Es war deutlich radikaler: Im Schnitt ca. 15 Live-Deployments pro Tag. Product-Owner-Rolle auf das ganze Team verteilt. Die meisten User-Storys kleiner als 1/2 Tag. 3-4 Daily Scrums pro Tag. Inkrementelles User-Experience-Design und UI-Design und und ich. Es wird sicher eine Weile dauern, bis wir das alles ausgewertet haben. Es wird sicher Niederschlag finden in Vorträgen, Artikeln und Blog-Posts.
Manuel Küblböck: Für mich ist Agile eine Vorraussetzung für Lean Startup. Der gravierende Unterschied (bzw. die entscheidende Erweiterung) liegt für mich darin, dass man sich in der Lean Startup Methode immer überlegt mit welchem Experiment man eine Hypothese überprüft. Und zwar mit einem möglichst einfachen Experiment, idealerweise ohne überhaupt erst Code zu schreiben.

Markus Gärtner: Was würdet Ihr potentiellen Nachahmer mit auf den Weg geben?
Manuel Küblböck: Die Antwort ist mir zu lang für dieses Interview geworden und ich habe daraus einen eigenen Blogpost gemacht.
Stefan Roock: Das meiste steht in Steve Blanks Customer Development Manifesto.

Markus Gärtner: Vielen Dank Euch beiden. Ich hoffe, Ihr findet nach diesem aufregenden Monat die Zeit für ein wenig Erholung.

Markus Gärtner: Halbzeit im Lean Startup March. Habt Ihr bereits Produkte auf den Markt gebracht in den rund zwei Wochen?
Sandra Reupke-Sieroux: Wir haben bereits in der ersten Woche zwei Produkte zum Thema “Online-Diskussionen” online gestellt, die aber nur spärlich bis gar nicht genutzt werden. In der zweiten Woche haben wir mehr an Verbesserungen von ‘discuss2decide’ bezüglich Nutzung und Benutzeransprache gearbeitet.
Manuel Küblböck: Ja, wie vor dem Startup March schon angedacht, haben wir uns entschieden ein Werkzeug für strukturierte Diskussionen zu bauen. Unter Discuss2Decide.com kann man jetzt schon diskutieren und zu Entscheidungen kommen, wenn auch natürlich noch ziemlich rudimentär. Die zweite Seite DiscuMeter.com dient dazu das Energielevel einer Diskussion zu messen und wird letztendlich wohl in discuss2decide aufgehen.
Stefan Roock: Ja, wir haben Discuss2Decide und DiscuMeter auf den Markt gebracht und bereits mehrfach an den beiden Produkten Verbesserungen/Überarbeitungen vorgenommen.

Markus Gärtner: Welche Erfahrungen habt Ihr dazu bis jetzt sammeln können? Mit der Methode Lean Startup als auch mit den Produkten.
Sandra Reupke-Sieroux: Es ist unheimlich schwierig an Feedback zu kommen, auf dessen Basis man sinnvolle Entscheidungen treffen kann. ‘Warum werden keine Diskussionen angelegt?’ ‘Führen nur wenige Leute online Diskussionen?’ ‘Fragen wir die falschen Leute?’ ‘Hilft das Tool nicht wirklich dabei?’ ‘Kriegen wir nur unsere Idee nicht verkauft?’ ‘Braucht es nur die richtige Zeitspanne zwischen auf das Tool aufmerksam werden und Bedarf für eine Diskussion zu haben?’

Wenn wir hilflos werden bezüglich der Feedback-Auswertung, fallen wir immer wieder mal in die Falle, uns über das Entwickeln neuer Features ‘Befriedigung’ zu verschaffen. Ich denke, wir sollten hier eigentlich im Sinne der Lean Startup Prinzipien kreativer und experimentierfreudiger werden.

Zwischendurch habe ich immer mal das Gefühl, dass wir uns genau die richtigen Fragen stellen und dann fühlt sich Lean Startup verdammt gut an.
Stefan Roock: Wir haben bei discuss2decide teilweise mehrere hundert neue Benutzer je Tag auf der Seite. Allerdings legen davon nur sehr wenige tatsächlich Diskusionen an. Die Conversion ist nicht befriedigend. Das hatte ich aber auch nicht anders erwartet. Es ist sehr unwahrscheinlich, gleich mit der ersten Version erfolgreich zu sein. Im Moment experimentieren wir mit verschiedenen Features, um zu gucken, was die Nutzer dazu bringen würde, das System zu nutzen.

Lean-Startup ist hilfreich, auch wenn wir noch viel darüber lernen, wie wir MVPs (Minimal Viable Product) noch schneller umsetzen können – vor allem, indem wir die MVPs noch leichtgewichtiger definieren. Im Moment brauchen wir für ein MVP 1-2 Tage.
Manuel Küblböck: Ich glaube, der Lean Startup Methode ist inherent, dass man sich am Anfang erst mal verloren fühlt. Im Gegensatz zum klassischen Produktentwicklungsansatz, denkt man sich zu Beginn nicht einfach ein tolles Produkt aus und entwickelt das dann. Es geht in erster Instanz darum zu Lernen was der Markt will, und das am besten, ohne überhaupt Code zu schreiben. Darüber hinaus sind die nackten Zahlen schon manchmal brutal. Entscheidung werden auf Grund von Benutzer Feedback gefällt. Da ist es schon frustrierend, wenn man rausfindet, dass es keinen interessiert, was man da gerade zusammengeschustert hat.

Markus Gärtner: Wie geht es weiter? Was glaubt Ihr in den kommenden zwei Wochen noch erreichen zu können?
Manuel Küblböck: Es gibt noch Phasen einer Diskussion für die discuss2decide im Moment noch keine Unterstützung bietet. Ich denke, dass wir an diesen Stellen zumindest noch eine rudimentäre Lösung bereitstellen werden. Vorausgesetzt natürlich wir machen kein Pivot in eine komplett andere Richtung.
Stefan Roock: Wir haben keinen Plan, der länger als 2 Tage ist. Daher weiß ich nicht, wie es inhaltlich weitergeht. Wir lernen weiter, wie wir die Bedürfnisse der Anwender adressieren können. Ich hoffe, dass wir im zweiten Teil des Startup-Marches soweit kommen, dass wir eine kleine treue Anwendergemeinschaft haben. Dann könnten wir nach dem Startup-March auf dieser Basis weitersehen, wie es weitergeht.
Sandra Reupke-Sieroux: Ich hoffe noch mutiger und disziplinierter als in den letzten zwei Wochen. Inhaltlich kann ich das noch nicht sagen, weil ich unsere Ideen von morgen noch nicht kenne. :-)

Markus Gärtner: Ihr nehmt am Startup-March bei it-agile teil. Was ist das?
Henning Wolf: Der Startup-March ist eine Initiative von it-agile-Kollegen, die für einen Monat aus Ihrem Slack und zusätzlicher Freizeit heraus einmal wirklich wissen wollen, was es bedeutet, ein Startup loszutreten.
Doreen Timm: Ein Experiment, an dem sieben Kollegen von it-agile teilnehmen.
Zusammen gründen wir ein Startup Unternehmen, um ein Produkt erfolgreich am Markt zu platzieren.
Stefan Roock: Beim Startup-March arbeiten einige Mitarbeiter von it-agile einen Monat lang ungestört an der Entwicklung eines neuen Produktes (eine simulierte Startup-Umgebung). Dabei setzen sie insbesondere die Techniken aus “The Lean Startup!” ein.
Sandra Reupke-Sieroux: Im Lean Startup March nimmt sich ein Team von it-agile Mitarbeitern einen Monat Zeit, um ungestört in eine Produktidee zu investieren. Dabei setzen sie auf Lean Startup Techniken, um schnelles Lernen und Feedback zu gewährleisten.
Manuel Küblböck: Im Startup-March werde ich mit 6 it-agile Kollegen den kompletten März damit verbringen, an einer Produktidee zu arbeiten. Vorgehen wollen wir dabei nach der von Eric Ries gehypten Lean Startup Methodik. Validiertes Lernen steht also im Vordergrund. Sowohl über unser mögliches Produkt, als auch über Lean Startup.

Markus Gärtner: Wie groß ist Eure Vorfreude auf dieses Experiment?
Doreen Timm: Sehr groß. :)
Manuel Küblböck: Ich freue mich schon tierisch darauf. Aus vielerlei Hinsicht. Im Alltag beim Kunden habe ich es in der Regel mit ‘agil’ im Anfangsstadium zu tun. Das heißt, hauptsächlich die Regeln und Zeremonien eines agilen Vorgehens zu erklären und vorzuleben. Beim Startup March werden wir sicher auf einem anderen Level agieren, auf dem man mehr pragmatisch statt dogmatisch sein kann. Bisher hatte ich noch nicht das Vergnügen, mit so vielen eigenen Kollegen in einem Projekt zu arbeiten. Zudem macht es natürlich immer Spaß, an einem neuen Produkt zu arbeiten.
Sandra Reupke-Sieroux: Ich freue mich riesig auf diesen Monat. Es ist eine wunderbare Gelegenheit, gemeinsam etwas mit Kollegen zu machen – insbesondere, da ich bislang mit keinem von ihnen gemeinsame Projekterfahrung habe. Ich freue mich darauf unsere Produktidee zu erkunden und bin gespannt darauf, wo wir nach einem Monat rauskommen und was wir alles über unser Produkt und mögliche Kunden gelernt haben.
Henning Wolf: Meine Vorfreude ist groß. ich freue mich auf die enge Zusammenarbeit im Team, auf die Konzentration auf neue Ideen und das Ausprobieren der Lean Startup Ansätze.
Stefan Roock: Ich freue mich sehr darauf. Endlich kann ich mal wieder mit it-agile-Kollegen zusammenarbeiten. Endlich kann ich mal wieder programmieren.

Markus Gärtner: Was erhofft Ihr Euch von diesem Experiment?
Sandra Reupke-Sieroux: Oh. Das ist vielerlei:

• Ich hoffe darauf, dass wir am Ende des Monats eine Produktidee so weit gebracht haben, dass wir Leute finden, die gewillt sind, in sie zu investieren. Venture-Capital ist dabei nur eine für mich vorstellbare Option.
• Ich habe noch nie zuvor in einem Projekt gearbeitet, das alle diese Eigenschaften hat: co-located Team von 4+ Leuten, volle Arbeitszeit, alle Teilnehmer sind auf Eigeninitiative dabei, alle Teilnehmer sind begeistert für Agilität und sehr kompetent. Ich erhoffe mir Einblicke darin, was möglich ist, wenn alle drei Säulen der Motivation – Purpose, Autonomy und Mastery – geballt zusammen kommen.
• Ich bin – wie die meisten Agilisten – sehr versessen auf Feedback und kleinschrittiges Arbeiten und auch wenn ich mich in der Vergangenheit darum bemüht habe, für neue Ideen schnelles Feedback einzuholen, weiß ich, dass ich da noch lange nicht am Ende der Fahnenstange angekommen bin. Ich erwarte mir hier einen enormen persönlichen Verständniszuwachs.

Henning Wolf: Primär rechne ich mit Spaß, aber ich hoffe auch auf Erkenntnisse über Customer Development und Lean Startup. Wenn es richtig gut läuft, kommt dabei dann auch ein Service heraus, mit dem man wirklich Geld verdienen kann.
Doreen Timm: Ich bin sehr gespannt wie wir mit Herausforderungen umgehen. Momentan kommt es mir so vor, dass wir einen Plan haben, wie wir mit eventuellen Hürden, Anpassungen an das Produkt, Kundenfeedback usw. umgehen. Gibt es etwas, was wir noch nicht angedacht haben? Bestimmt, und wenn, wie werden wir dann damit umgehen? Herrlich, ich freue mich schon. :)
Manuel Küblböck: Ich bin gespannt, wie weit wir in nur einem Monat kommen. Bisher gibt es nur eine grobe Idee von einem Produkt. Mal sehen, wie viel wir davon umsetzen können und wie sehr, wenn überhaupt, es am Ende noch der ursprünglichen Idee entspricht. Ich erhoffe mir, dass wir am Ende etwas haben, an dem wir auch über den März hinaus profitabel weiter arbeiten können und wollen.
Stefan Roock: Und dabei gibt es auf jeden Fall jede Menge zu lernen. Und wenn es ganz großartig läuft, haben wir hinterher sogar eine erste Produktversion, mit der man z.B. Venture-Capital akquirieren kann.

Markus Gärtner: Vielen Dank für Eure Antworten. Ich bin gespannt auf Eure Erfahrungen.