Samstag, 30. Mai 2015

Kommentierte Links

Grafik: Pixabay / Elisa Riva - Lizenz

Gerald Traufetter und Matthias Gebauer: Airbus-Flieger stürzte wegen Software-Problemen ab

Einer dieser Fälle bei denen klar wird welche weitreichenden Folgen es haben kann, wenn bei der Qualitätssicherung von Software etwas übersehen wird. Gleichzeitig aber auch eine Erinnerung daran, wo heute überall Software drinsteckt (an praktisch jeder Stelle). Ein Flugzeug ist heute nicht mehr bloß eine fliegende Maschine sondern auch ein fliegender Computer (bzw. eine fliegender Schwarm miteinander vernetzter Computer und Maschinen).

Boris Gloger: Der Testmanager in Scrum

Boris Gloger schreibt, dass Kay Grebenstein meint, dass alle Aufgaben eines Testmanagers in Scrum genau so gut von dem Entwicklungsteam wahrgenommen werden können. Der Artikel enthält auch ein schönes Mapping von ISTQB-Testmanager-Aufgaben mit den Aufgaben eines Scrumteams, wodurch tatsächlich alle Testmanagement-Tätigkeiten abgedeckt werden. Ich glaube ja, dass da ein entscheidender Punkt fehlt, nämlich der, dass ein Testmanager in Scrum andere Aufgaben haben sollte (vereinfacht gesagt eine Art Scrum Master für die Tester der Teams). Aber vielleicht hat Gloger das auch einfach nicht erwähnt, er schreibt selbst, dass er einiges weggelassen hat.

Geoff Watts: Impostor Syndrome - Why Some ScrumMasters Feel Like They’re Faking It

Ein Thema das mir in letzter Zeit mehrfach untergekomen ist (u.a. in Gesprächen auf der Arbeit, in diesem Blog, auf dem Scrumtisch Essen). Bei manchen Scrum Mastern kann sich mit der Zeit ein verstecktes Minderwertigkeitsgefühl ausbreiten, weil ihnen das technische Verständnis für die Arbeit ihres Teams fehlt. Wie Watts es ausdrückt: "I was not a technical person, yet I was project managing a technical project full of technical people." Tatsächlich wären viele Scrum Master nicht in der Lage mitzuprogrammieren, entweder weil sie aus dem Projektmanager-Bereich kommen oder weil sie zwar mal Programmierer waren, aber seit langem aus der Übung sind. Ich halte das nicht für schlimm, wir leben nun mal in einer arbeitsteiligen Gesellschaft. Und auch unter den Entwicklern gibt es ja Spezialisierungen die dazu führen, dass nicht mehr alle überall mitarbeiten können.

Anik Subhan: Making the world a better place by not estimating

Anik Subhan von Lean Software Delivery hat recht wenn er schreibt, dass in seiner Firma Estimations nicht funktionieren. Das liegt aber nicht daran, dass Estimations schlecht sind, sondern daran dass sie dort falsch durchgeführt wurden. Es wurde nämlich nicht die Komplexität sondern der Zeitaufwand geschätzt, was man in Scrum grundsätzlich nicht tun sollte. In Folge dessen sind genau die Probleme aufgetreten die zu erwarten waren: Unrealistische Planungen, falsche Erwartungen, Hektik bei zeitlichem Verzug. Die Lösung die man dort gefunden hat halte ich allerdings ebenfalls für wirr: Man hat angefangen Timeboxing einzuführen (für bestimmte Arbeiten steht nur eine bestimmte Zeit zur Verfügung). Abgesehen davon, dass man auch dafür Zeitschätzungen braucht - was passiert wenn die Zeit um ist aber die Arbeit noch nicht fertig - hört man dann einfach auf? Eine bessere Idee hatte ich vor drei Wochen aufgeschrieben.

Dienstag, 26. Mai 2015

Kostensteigerungen in staatlichen Großprojekten

Der Laie wundert sich, der Fachmann hat es längst geahnt - die wahren Kostenexplosionen finden trotz Elbphilharmonie, Berliner Flughafen und Stuttgart 21 nicht in Bauprojekten statt, sondern in IT-Projekten wie z.B. bei Toll Collect, der Gesundheitskarte oder der (gescheiterten) Einführung einer bundesweit einheitlichen Finanzverwaltungs-Software. Eine aktuelle Studie der Hertie School of Governance [Edit: Link zur Studie ist mittlerweile tot] hat 170 staatliche Großprojekte untersucht und wie folgt aufgeschlüsselt:
Auch Gründe für die Kostenexplosionen werden genannt und erneut dürften erfahrene Projektmanager nicht überrascht sein: Die zentralen Ursachen sind überbordende Bürokratie, unrealistischer Planungsoptimismus und ständige Änderungswünsche (wobei den letzteren aufgrund der genannten Bürokratie nicht schnell genug nachgekommen werden kann). Eigentlich die idealen  Bedingungen für den Einsatz agiler Methoden - wenn diese nicht mit dem staatlichen Verwaltungsapparat weitgehend inkompatibel wären.

Montag, 18. Mai 2015

Qualität ist mehr als Testen: User Stories und Akzeptanzkriterien

Grafik: Pixabay / Geralt - Lizenz
Im klassischen Projektmanagement ist die Rolle des Testers relativ klar umrissen: irgendwann in einer lang zurückliegenden Projektphase hat jemand eine Feinspezifikation geschrieben. Aus der hat ein Testmanager Testfälle abgeleitet, die er in Form einer detaillierten Klickanleitung aufgeschrieben hat. Und die wird dann durchgeklickt. Wieder und wieder und wieder.

In agilen Projekten gibt es weder Feinspezifikationen noch Klickanleitungen, so dass der Tester wesentlich selbstständiger arbeiten muss. Konkret bedeutet das nicht nur, dass er die Testfälle selbst verfassen muss (dazu ein anderes mal mehr) - auch für die Anforderungen auf denen die Testfälle beruhen ist er (mit)zuständig. Spätestens an dieser Stelle der Erzählung ist es in den letzten Jahren regelmässig vorgekommen, dass sowohl Tester als auch Fachabteilungsmenschen Schnappatmung bekommen haben. "Was?? Test schreiben geht ja gerade noch, aber an den Anforderungen mitarbeiten? Das klappt doch niemals. Das kann ein Tester gar nicht."1
Soweit die Zweifler dieser Welt. Ich sage aber: es geht und es ist gar nicht schwer. Und zwar so:

Qualitätssicherung der Anforderung/User Story

User Stories bestehen in ihrer ursprünglichen Reinform aus einem einzigen Satz nach dem Muster "Als [User mit Rolle A] möchte ich [Aktion B durchführen können] um [Mehrwert C zu haben]." Um ein Beispiel zu nennen: Als Kunde möchte ich in meinem Login-Bereich meine Lieferadresse eingeben können, damit mir meine Waren zugeschickt werden können. Die Aufgabe des Testers wären hier folgende Überprüfungen:
  • Ist die Story klar genug beschrieben ("Ich möchte im Login-Bereich meine Adresse eingeben können" statt "Ich will meine Adresse eingeben")? 
  • Ist die Story klar zu anderen Anforderungen abgegrenzt ("Ich möchte meine Lieferadresse eingeben können" statt "Ich will alle meine Daten pflegen")? 
  • Ist ein Mehrwert erkennbar (endet die Story mit einem Zwecksatz)? 
  • Ist die Story testbar (" Ich will Daten eingeben können" statt "Ich will ein Eingabefeld haben, das in einer späteren User Story eine Funktion bekommen wird")? 
Sind diese Kriterien nicht gegeben ist eine Rücksprache mit dem Verfasser der Story zu empfehlen, da hier noch Verbesserungsbedarf besteht. Wenn die User Story so abgesichert ist folgt der zweite Teil, das Verfassen der Akzeptanzkriterien.

Verfassen der Akzeptanzkriterien

Akzeptanzkriterien sollten ähnlich wie die User Story selbst nicht in eine Feinspezifikation ausarten, sondern in einfacher, auch für den Nicht-Informatiker verständlicher Sprache geschrieben sein. Sie sollten vom Verfasser der Story gemeinsam mit dem Tester erarbeitet werden und beantworten im Idealfall die folgenden Fragen: Wer bin ich?, Wo kann ich eine neue Aktion durchführen?, Was für eine Aktion ist das?, Welchen Effekt löse ich damit aus? und Welche Voraussetzungen müssen dafür gegeben sein? Beim oben genannten Beispiel sähe das so aus:
  • Wenn ich mich als User mit Rolle "Kunde" einlogge sehe ich in der Kopfnavigation den neuen Menüpunkt "Lieferadresse pflegen"
  • Nach einem Klick auf den Menüpunkt werden Eingabefelder für Strasse, Hausnummer, Postleitzahl und Stadt angezeigt sowie ein Save-Button
  • Wenn die Daten eingegeben und gespeichert werden erscheinen sie in der nur für User mit der Rolle "Lieferant" sichtbaren Tabelle "Kundendaten"
  • Voraussetzungen: Die User Stories "Login" und "Kundendaten" müssen abgeschlossen sein bevor diese User Story begonnen wird
Und das ist es auch schon. Damit ist die Software-Anforderung fertiggestellt.

AberAberAber!!

Jedem der schon einmal eine klassische (Fein)Spezifikation gesehen hat wird spätestens jetzt ein Gedanke kommen: Dem Entwickler wird hier ja gar nicht gesagt wie er zu entwickeln hat! Und es gibt gar keine pixelgenaue Vorgabe wo und in welcher Farbe welches Element erscheinen soll!! Die Antwort darauf ist - natürlich nicht! Darauf zu verzichten und darauf zu vertrauen, dass das Entwicklungsteam (in Absprache mit PO und Tester) von sich aus die beste und effizienteste Lösung finden wird, das gehört zum agilen Vorgehen dazu. Und wenn man das einmal verinnerlicht hat kommt man auch schnell zu der Einsicht, dass eine "nur" aus User Story und Akzeptanzkriterien bestehende Anforderung auch von einem Tester mitbearbeitet werden kann - und auch mitbearbeitet werden sollte, wenn man denn Wert auf Qualität legt.

1Wörtliches Zitat

Freitag, 15. Mai 2015

Ein Bild sagt mehr als 1000 Worte (III)

View post on imgur.com

Montag, 11. Mai 2015

Schwarmdummheit

Einer der sehenswertesten Vorträge der Republica 2015 war sicherlich der zum Thema "Schwarmdummheit" in großen Organisationen, gehalten von Gunther Dueck. Für alle die 30 Minuten Zeit haben habe ihn hier eingebunden:



Duecks Vortragsstil ist etwas gewöhnungsbedürftig und es braucht ein bisschen bis sich alles zu einem Gesamtbild fügt, trotzdem ist das Video sehr zu empfehlen. Jedem der schon einmal in einem Konzernumfeld arbeiten durfte wird einiges sehr bekannt vorkommen.

Mittwoch, 6. Mai 2015

Statt Planning Poker: Flag Estimation

Grafik: Wikimedia Commons/Acme Squares - CC BY-SA 3.0

Zu den immer wiederkehrenden Herausforderungen eines Scrum Masters gehört sicherlich die Neigung von Product Ownern, Projektleitern aber auch einfachen Teammitgliedern, Stories nicht in Komplexität, bzw. Story Points sondern in Arbeitsstunden oder Personentagen messen zu wollen. Der Ursache dafür ist im Normalfall nicht, dass die Gründe für die Nutzung von Story Points unklar wären. Die sind bekannt und schnell erklärt:
  • Menschen können sehr schlecht Zeitaufwände schätzen (brauche ich dafür 5 oder 8 Stunden?) aber sehr gut Aufgaben in Relation setzen (A ist größer als B).
  • Zeitaufwände müssen ständig neu geschätzt werden weil eingespielte Teams schneller werden und Teams deren Mitglieder ausgetauscht werden langsamer. Komplexitäts-Schätzungen bleiben gleich.
  • Schätzungen von Zeitaufwänden führen oft (und z.T. unbewusst) zu unrealistischem Planungsoptimismus, wenn einfach die verbleibende Zeit auf die geplanten Features aufgeteilt wird. Bei Komplexitäts-Schätzungen besteht dieses Risiko nicht.
Dass es trotzdem regelmässig zu Rückfällen in Zeitschätzungen kommt liegt an verschiedenen Gründen: Alte Gewohnheiten oder im Hintergrund wühlende Abteilungsleiter sind Klassiker, erstaunlich oft liegt die Ursache aber auch da wo man sie am wenigsten vermuten würde, nämlich in einem klassischen agilen Werkzeug - den Planning Poker-Karten. Auf diesen befinden sich nämlich Zahlen, und selbst wenn diese explizit nicht dafür gedacht sind Tage oder Stunden darzustellen, so ist es für viele Menschen einfach zu naheliegend oder zu verlockend genau das zu machen. Was soll man aber mit einem Team anstellen, das sich beim besten Willen nicht davon abbringen lässt die Karten in dieser Weise zu missbrauchen?

Ein interessanter Lösungsansatz den ich einmal im Bordbistro eines Zuges mitbekommen habe (man lernt dort mitunter bemerkenswerte Leute kennen) ist der, statt klassischen Planning Poker-Karten ausgedruckte Fahnen verschieden großer Länder zu benutzen. Eine sehr kleine Story wäre z.B. Luxemburg, eine etwas größere Estland, dann die Niederlande, dann Spanien, dann Deutschland, bis hin zu den ganz großen: Brasilien, Russland, USA und schließlich als größte Karte China. Die so dargestellten Größeneinheiten sind noch immer eingängig, die Umrechnung in Tage und Stunden wird dagegen deutlich erschwert. Die dabei entstehende Herausforderung ist allerdings die, dass aus den Stories eines Sprints eigentlich eine Durchschnittsleistung/Velocity abgeleitet werden muss, was bei Karten mit Nummern darauf deutlich einfacher ist. In diesem konkreten Fall löste das Team diese Schwierigkeit dadurch, dass die Karten auch unterschiedlich groß waren. Nebeneinandergelegt entsprachen sie bestimmten Abschnitten einer Messlatte, denen dann die verschieden großen Kontinente zugeordnet waren: Australien, Europa, Afrika, Amerika und Asien.

Dem Vernehmen nach soll diese Idee ganz wunderbar funktioniert haben, weshalb ich sie irgendwann auch ausprobieren möchte. Im Augenblick mache ich zwar keinen Scrum Master, für den Fall das sich das mal wieder ändert habe ich aber vorgesorgt: Ausdruckbare Flaggen gibt es hier.

Montag, 4. Mai 2015

Der 'bestimmende Scrum Master'

Bild: Wikimedia Commons/Clinton Firstbrook - CC0 1.0

Ein Nachtrag zum Scrum Master vs Team Coach-Text von letzter Woche: wenn es Situationen gibt in denen ein "bestimmender Scrum Master" nötig ist, der "verhindert, dass das Team Dummheiten macht", wie genau sieht so etwas aus? Und wo sind die Gefahren dabei?

Um die zweite Frage zuerst zu beantworten - das Risiko besteht darin, dass ein zu dominanter Scrum Master die Eingeninitiative und Selbstverantwortung "seines" Teams abtötet. Drüben beim Agile Answerman werden die möglichen Folgen beim Namen genannt:
  • Dem Team wird die Möglichkeit zu experimentieren und etwas auszuprobieren genommen: Wenn der Scrum Master im Team Mikromanagement betreibt und Prozesse und Lösungswege vorschreibt, dann wird den Teammitgliedern die Möglichkeit genommen, Inspect & Adapt zu betreiben, also das was sie in Scrum eigentlich sollen. Zum einen bleiben so mögliche Lösungswege auf die der Scrum Master nicht selbst gekommen ist unentdeckt, zum anderen wird das Lernen aus den eigenen Fehlern unterbunden. Beides ist kontraproduktiv.
  • Das Team rutscht in die Apathie ab: Genau das was im Wasserfall-Vorgehen die Regel ist kann auch in (falsch umgesetztem) Scrum passieren - sobald ein Team das Gefühl hat, dass Entscheidungen ohne seine Beteiligung getroffen werden entsteht der berüchtigte "Entwicklerzynismus" der sich in dem bekannten Ausspruch manifestiert "Ich mache hier nur was mir gesagt wird". Die im agilen Vorgehen gewollte Selbstorganisation und Übernahme von Verantwortung verschwindet.
  • Das Teamkonzept wird in sein Gegenteil verkehrt: In dem Moment in dem wichtige Entscheidungen nur noch von einer Person getroffen werden, werden Kompetenz, Wissen und Potential der anderen Teammitglieder verschenkt. Dass der Scrum Master alles besser weiß als sein Team ist unwahrscheinlich genug, aber selbst wenn - wenn das Team nicht an Entscheidungen beteiligt wird, dann wird sich daran nie etwas ändern. Selbst wenn es mit gutem Willen geschieht, als Ergebnis entsteht eine Abhängigkeit vom Scrum Master, die so in der Methodik nicht gewollt ist.
Gründe für ein solches Fehlverhalten findet man hinter dem oben genannten Link, ich will stattdessen auf die erste Frage eingehen: Wie sollte man die Position eines bestimmenden Scrum Masters ausfüllen ohne die genannten Folgen hervorzurufen? Bevor es dazu kommt nochmal ein paar Worte zu den Vorbedingungen. Der bestimmende Scrum Master ist eine Notlösung, die nur dann eingesetzt werden sollte wenn das Team seine Selbstorganisations-Kompetenz nutzen will um das agile Vorgehen abzuschaffen (etwa durch Einführung von telefonbuchdicken Feinspezifikationen oder mehrere Monate langen Sprints, oder durch die Abschaffung von User Stories, Retrospektiven oder Sprint Boards). In diesem Fall würde das Projekt in ein als Scrum getarntes Wasserfall-Vorgehen zurückfallen, was nicht nur die Scrum-Methodik sondern im Normalfall auch den Projekterfolg gefährden würde. Das zu verhindern ohne dem Team Eingeninitiative und Selbstverantwortung zu nehmen ist die Herausforderung.

Der beste Lösungsansatz in einer solchen Situation dürfte der sein, dass der Scrum Master in einer "Schiedsrichter-Rolle" auftritt. Auch im Fussball oder Rugby gibt es Regeln an die sich jeder halten muss, ohne das dadurch die Selbstorganisation der Mannschaft aufgehoben wird. Solange sie diese Regeln einhält kann sie jede Taktik und Spielweise einsetzen die sie für richtig hält. Damit der Scrum Master als Schiedsrichter akzeptiert wird sollte er diese Regeln (z.B. die Prinzipien Agiler Softwareentwicklung) allerdings möglichst von Beginn an bekannt machen, er sollte sie möglichst selten (und schon gar nicht während eines Sprints) ändern oder erweitern und zuletzt - er sollte von jeder einzelnen auch überzeugend darlegen können warum sie sinnvoll ist. Wenn ihm das gelingt besteht berechtigte Hoffnung, dass er sich mit der Zeit zurücknehmen und auf eine Team Coach-Rolle zurückziehen kann. Wie bei allen Notlösungen gilt nämlich auch für den bestimmenden Scrum Master: manchmal geht es nicht anders, das Ziel muss es aber immer sein, ihrenen Einsatz so weit wie es geht einzuschränken.

Samstag, 2. Mai 2015

Ein Bild sagt mehr als 1000 Worte (II)