Nach dem „Planning Poker“ möglichst schnell coden

Seit wann und bei welchen Projekten arbeitest du im Scrum-Modus?

Ich bin schon seit 2004 fast ausschließlich in agilen Projekten unterwegs. Offiziell bin ich momentan im Bereich Front Office Ticketing, werde aber häufig für andere Projekte ausgeliehen, beispielsweise für Leisure Evolution (Weiterentwicklung Amadeus Tour Market) und CheckMyTrip (mobile Anwendungen).

Wie können wir uns die ersten Schritte im Scrum vorstellen?

Zum Projektstart evaluieren wir die Rahmenbedingungen: Welche Technologien werden wie verwendet, also etwa JavaScript, PHP oder Java, wie möchte ich die Anwendung aufbauen, passt sie in die aktuellen Projektanforderungen und in die technische Umgebung von Amadeus? Diese technischen Aspekte haben Einfluss auf den Backlog, in dem Themen gesammelt, priorisiert und so auf eine Zeitachse gebracht werden. Damit startet das „Planning Game“, das die Sprintplanung 1 und 2  anstößt. Wir setzen die ausgewählten fachlichen Themen (Stories) innerhalb der Sprints um, die jeweils etwa drei bis vier Wochen dauern. In die Planung sind alle Teammitglieder eingebunden, jeder soll wissen, worum es geht. Wir erläutern, was alles umgesetzt werden muss, und schätzen den Zeitaufwand.

Wie schätzt ihr den Zeitaufwand für einen Task?

Wie spielen – nämlich „Planning Poker“: Jeder hat einen Satz Poker-Karten (1, 2, 3, 5, 8, 13, 20, 40, 100) in der Hand, wir zählen bis drei, und jeder hält eine Karte vor sich. Die Zahl darauf steht für die Komplexität der Aufgabe. Dabei haben wir ein Referenzthema vor Augen, zum Beispiel ist ein einfaches Eingabefeld zur Suche eine „1“, und ich schätze dann, wieviel schwieriger und komplexer die Aufgabe ist, um die es jetzt geht. Wer die niedrigste und die höchste Zahl hat, erläutert seine Gründe für die Bewertung und es folgt die zweite Schätzrunde, in der sich die Zahlen dann stärker annähern. Das fördert zum einen die Kommunikation, aber man versteht das Thema auch immer besser. Der Product Owner kann die Komplexität besser erfassen, man tauscht Blickwinkel und Ideen aus. Ich stelle zum Beispiel fest, dass ich etwas übersehen habe, was der Teamkollege aber bedacht hat, oder umgekehrt: Der Kollege mit einer niedrigen Zahl hat eben eine geniale Idee im Kopf, die alles viel einfacher macht. Das heißt, wir nähern uns an. Es geht gar nicht um die Zahl an sich, sondern darum, ob es „viel weniger“ oder „viel mehr“ Aufwand ist, und wir gehen sicher, dass alle das Thema richtig verstanden haben. Im Zeitverlauf können wir dann immer zuverlässiger absehen, wie viele Komplexitätspunkte wir innerhalb von drei Wochen, also einem Sprint, schaffen.

Dieser Kommunikationsaspekt spielt also auch für Entwickler eine wichtige Rolle?

Absolut. Ich habe inzwischen auch die Daily Stand-Ups lieben gelernt – anfangs dachte ich: Was bringt das? Dann hatte ich eine Zeit ohne sie und habe gemerkt, wie sie mir fehlten. Wir stehen jeden Morgen maximal 15 Minuten zusammen und tauschen uns aus: Was habe ich gestern gemacht, was habe ich heute vor, was blockiert mich vielleicht? Wenn einer zu ausführlich wird, heißt es: „Komm‘ mal zum Punkt!“ Und allein das Stehen hält die Runde kurz. Man bekommt mit, was die anderen machen, und versteht sie und das ganze Projekt besser, auch wenn dort nicht alle offenen Punkte geklärt werden sollten. Aber man findet zum Beispiel auch heraus, welche Leute noch miteinander reden sollten oder ob man jemanden stärker mit einbeziehen sollte. Und man konzentriert sich darauf, was heute ansteht. Diese tägliche Problemfindung und Vorwärtsplanung findet aber innerhalb der festen Sprintplanung statt, die den Rahmen gibt. Es geht also nur um eine Feinjustierung, die Teil des empirischen Prozesses ist. Niemand bekommt einen Task übergestülpt, sondern jeder nimmt sich seine  Aufgabe, sein Tageshäppchen, und geht in die Bearbeitung. Das fachliche Feature ist dann beendet, wenn alle Tasks abgearbeitet sind. Das funktioniert besonders gut im kleinen Team, da sonst zu viele Tasks auf Sprint-Backlog stehen, die in Form eines Kanban Boardsvisualisiert werden.

Zu große Teams sind also eher ungünstig?

Absolut! Sieben plus minus zwei Mitglieder sind ideal, also Entwickler, Analysten, Tester, meist der Scrum Master. Der Product Owner kann, aber muss nicht dabei sein bei den Stand-ups, und wenn, redet er an dieser Stelle nicht mit. Zu große Teams zerstören die Agilität, sie sollten gesplittet werden.

Nach drei bis vier Wochen ist der erste Sprint geschafft – wie geht’s weiter?

Nach dem ersten Sprint gibt es bereits eine Demo. Sie zeigt dem Product Owner die definierten Features in der Anwendung. Und auch wir halten uns damit vor Augen, was wir geschafft haben, denn das vergisst man oft im Projektalltag. Oft sind das erstaunliche Ergebnisse, die ungemein motivieren! Wir bekommen eine frühe Rückmeldung zu dem, was wir geleistet haben. Wichtig ist hier das konstruktive Feedback des Product Owners. Gemeinsam gehen wir in die Retrospektive, wo wir festhalten, was in unserem agilen Prozess gut oder weniger gut funktioniert hat, und planen den nächsten Schritt. Das heißt, es geht dann wieder los mit dem Planning Game gefolgt vom nächsten Sprint und Daily Standups gefolgt von Demo und Retrospektive. Dieser Kreislauf wiederholt sich bis Projektende, wobei die Planung mit der Zeit immer flüssiger wird.

Welche Kernwerte der Methodik sind dir besonders wichtig?

Zum einen die Wertschätzung, die ich beispielsweise durch die eben erwähnte Rückmeldung bekomme. Jeder erkennt die Kompetenzen des anderen an. Das faire Miteinander fördert den ehrlichen Austausch und stärkt das gegenseitige Vertrauen. Das alles sind enorme Motivationsfaktoren. Transparenz ist wichtig, auch die gelebte Fehlerkultur. Es gibt kein Finger Pointing! Und natürlich die Kommunikation, in die man keinen zwingen kann, die aber bei den meisten früher oder später in Fleisch und Blut übergeht, auch wenn wir Nerds sind: Ich will kommunizieren, weil ich daraus viel zurückgewinnen kann. Aber die Verständigung im Team ist immer unterschiedlich aufgrund der individuellen Charaktere und muss sich entwickeln. „Es gibt nicht die eine, die richtige Art, wie Scrum funktioniert“, heißt es so treffend – aber man muss sich einfach darauf einlassen. So passt man sich permanent an, und es läuft.

Du fühlst sich im Scrum also absolut wohl? Oder stößt du auch an Grenzen?

Ja, wenn er so eingeführt wird, wie er gedacht ist, geht’s mir sehr gut. Damit meine ich: Wir müssen die Werte und Prinzipien des „Agilen Manifests“ im vollen Umfang leben, also beispielsweise die offene Kommunikation. An Grenzen stoßen wir schon mal, beispielsweise beim Project Reporting: Dann kommt die alte Welt  zurück, das „Command and Control“. Dann heißt es: Wie ist eure Performance? Stimmt der Aufwand noch an genau dieser Stelle? Während unsere Idee ist: Gebt uns einen Rahmen, also Zeit, Budget, eine Qualitätsvorgabe und die grobe Richtung, und wir gestalten das Projekt in diesem Rahmen eigenverantwortlich gemeinsam mit dem Product Owner. Wir brauchen die Möglichkeit, Prozesse und Paradigmen anzupassen, wir müssen nachjustieren, neue Aspekte hineinnehmen oder einzelne User Stories auch nach hinten verschieben können. Das klassische Ressourcendenken ist also so eine Grenze, die sich auch bei der Kapazitätsverteilung zeigt. Stabile agile Teams arbeiten mindestens ein Jahr zusammen und es lohnt sich, die Teamreife auszuschöpfen, statt zu häufig neue Teams zusammenzustellen.

Aber noch mal kurz zum Wohlfühl-Aspekt: Positiv für Software-Entwickler wie mich ist dieses schrittweise Vorgehen auch in weiterer Hinsicht. Wir wollen hacken und nicht erst 100 Seiten Spezifikation schreiben! Scrum ist für uns einfach natürlicher: Wir planen eine User Story in Form von Tasks und können dann sofort mit dem Programmieren anfangen. Wir sitzen also spätestens nach einem Tag an der Tastatur und dürfen coden – und das ist nun mal unser Lebenselixier …

Letzte Frage: Alte Welt und neue Welt, Wasserfall und Scrum – hast du dazu ein Bild für uns, das uns das unterschiedliche Vorgehen veranschaulicht?

Stell dir vor, du stehst in einem Raum und sollst „blind“ zu einem Punkt gehen. Im Wasserfall zeige ich dir das Ziel, verbinde dir die Augen und sage dann: Lauf dorthin. Irgendwann bleibst du stehen, weil du denkst, dass du jetzt da bist. Im Scrum machst du nur einen Schritt, dann darfst du gucken und dich orientieren, wo du stehst, und den nächsten Schritt planen. Und du kriegst auch mit, wenn sich das verflixte Ziel noch mal bewegt. Wie im richtigen Leben halt!

Weitere Blogartikel aus dieser Serie:

Als motivierender Steuermann mittendrin

Alle Kraft dem Team

Patrick Mentz

Patrick Mentz, 36, ausgebildeter Fachinformatiker und mittlerweile auch zertifizierter Scrum Master, ist seit 2013 IT-Entwickler bei Amadeus Germany und hat davor bereits zwölf Jahre im agilen Scrum-Modus bei der Commerzbank gearbeitet. Auch privat programmiert er für sein Leben gern, ob es ein Schichtplan-Tool für seine Frau oder ein Open-Source-„Helferlein“ für Entwickler-Kollegen ist. Außerdem liebt er Computerspiele, fährt aber auch gerne Fahrrad und interessiert sich für Fußball.