Agile Software-Entwicklung: ein Scrum Master berichtet aus der Praxis

A

Sebastian gibt uns einen Einblick, wie Scrum als eine Methode agiler Software-Entwicklung funktioniert. Er hat 2017 seinen Master in Informatik gemacht, ist seitdem als Software-Entwickler tätig und seit einem halben Jahr zertifizierter Scrum Master. Er wohnt und arbeitet in Dänemark.

(c) Sebastian D.

Wie läuft deine Arbeit ab?

Derzeit arbeite ich bei einer globalen Logistikfirma in einem Innovationsprojekt, zusammen mit insgesamt sechs Scrum-Teams.

Scrum ist ein Framework, was dazu anleiten soll, agil ein Produkt in Sprints zu entwickeln. Sprints, das sind so abgegrenzte Zeiträume, in der Regel von 2 bis 4 Wochen, die dazu dienen, die Komplexität des Produktes herunter zu brechen, weil man mit einem Zeithorizont arbeitet, in welchem man schon eher sagen kann, ob man irgendwas schafft oder nicht. Die Überraschungen werden dann wesentlich kleiner und unwahrscheinlicher.

Sprints dienen dazu, die Komplexität des Produkts herunter zu brechen

Wie fängt so ein Sprint an?

Am ersten Tag haben wir das sogenannte Sprint Planning. Das ist so eine Zeremonie, so heißen die Scrum Events, in der man mit dem Team durchgeht, welche Aufgaben im nächsten Sprint gemacht werden sollen. Der Product Owner, welcher die Verantwortung für das Produkt trägt, stellt vor, was auf seiner Liste oberste Priorität hat. Das Team entscheidet dann anhand der Produktivität der letzten Sprints: Wieviel glauben wir, können wir im nächsten Sprint schaffen?

Wichtig ist, dass man als Team vorher Schätzungen dieser Tasks, dieser User Storys vornimmt. Das Team schätzt anhand von Referenzwerten ein, wie viel Arbeit sie reinstecken müssen, um eine bestimmte Aufgabe zu erledigen. Das läuft nach einem Bucket-System ab: in den letzten Sprints haben wir so viele Punkte abarbeiten können, das sollte uns im Schnitt x Punkte für diesen Sprint zur Verfügung stellen.“

Dann nimmt man vom Backlog, der Liste der Aufgaben oder User Storys, von oben so viele Aufgaben in den Sprint herein, bis man die Kapazität des Teams erreicht hat.

Wie lange braucht ihr für so eine Schätzung?

Das ist eigentlich ein kontinuierlicher Prozess. Einmal pro Woche gucken wir uns ein paar User Storys an und gehen durch: „Was für Anforderungen stehen da drin? Was sind die Acceptance Kriterien, also wann sagt der Product Owner, dass diese Aufgabe erledigt ist?“

Das besprecht ihr tatsächlich in der gesamten Gruppe?

Ja, das ist sehr wichtig, das ganze Team zu involvieren, weil ich von allen die Erfahrung und die Meinung dazu haben möchte. Die Idee bei Scrum ist nämlich, sobald eine Aufgabe im Sprint ist und vom Team akzeptiert wurde, dann übernimmt das Team auch die Verantwortung, dass die Aufgabe erledigt wird.

…weil ich von allen die Erfahrung und die Meinung dazu haben möchte

Auch wenn man mal einen Entwickler hat, der jetzt gerade an einer Aufgabe hängt, einfach nicht vorankommt, dann können die Entwickler, die schon fertig sind, nicht einfach gehen und was Neues in den Sprint nehmen, sondern sie müssen dem Entwickler dann soviel Unterstützung geben, dass die Aufgabe erledigt werden kann.

Du bist als Scrum Master ja genau für diese Prozesse in der Gruppe verantwortlich. Was tust du, damit das gut funktioniert?

Das wichtigste Tool ist das sogenannte Daily Standup. Einmal am Tag stellt man sich als Team zusammen, für 15 Minuten. Es ist auch sehr wichtig, dass man sich hinstellt, weil das sehr intensive 15 Minuten sind, in welchen man produktiv sein soll.

Daily Standup: 15 Minuten intensiv produktiv sein

Das Team steht an einem Task Board mit den Aufgaben, die momentan bearbeitet werden und dem jeweiligen Zustand und geht diese durch. Jedes Teammitglied erklärt, woran er oder sie gerade arbeitet und was die Hürden sind. Dann gibt jedes Teammitglied auch eine Schätzung ab, wie lange es noch ungefähr dauert, bis die Aufgabe erledigt ist.

Das gibt eine vollständige Transparenz über den jeweiligen Arbeitsstand?

Genau. Es geht darum, sicherzustellen, dass kein Teammitglied einknickt und nicht weiß, was es machen soll, sondern dass man rechtzeitig mit dem Team aushelfen kann und das Problem zusammen löst.

Der Product Owner hat in den Daily Standups eher die Funktionalität, Fragen zu beantworten, z.B. bei Verständnisproblemen. Er ist nicht da, um zu kritisieren. Solange der Sprint noch läuft, hat das Team noch alle Freiheiten und muss sich erst bei Sprintende der Verantwortung stellen.

solange der Sprint noch läuft, hat das Team noch alle Freiheiten

Das zweite Werkzeug ist die sogenannte Retrospective. Die ist am Ende des Sprints, wenn der festgelegte Zeitrahmen abgelaufen ist. Das ganze Team setzt sich für eine Stunde oder anderthalb Stunden hin, je nachdem, wie lange der Sprint dauert und geht alles durch: Was lief gut im Sprint und was lief nicht so gut?

Dann nimmt man Korrekturen vor. Zum Beispiel, wenn man findet, dass man zu viele Aufgaben in den Sprint genommen hat und die Qualität des Produkts am Ende gelitten hat. Es ist wichtig, dass man sich dazu bekennt und sich als Team überlegt, was man da besser machen kann.

Retrospective: Korrekturen für das nächste Mal

Das macht ihr innerhalb des Teams?

Ja, genau, allerdings auch mit dem Product Owner. Alle anderen sind in dem Set nicht erlaubt. Manager z. B. sollten bei Retrospectives nicht dabei sein, weil das in der Regel das Vertrauen und die Ehrlichkeit im Team schwächt. Man gesteht sich natürlich weniger Fehler ein, wenn der Vorgesetzte dabeisitzt und lauscht.

Manager sind nicht erlaubt, weil das die Ehrlichkeit im Team schwächen kann

Das ist das A und O bei Scrum, dieser Prozess, drüber zu schauen und zu überlegen: War das wirklich das Richtige, was wir da gemacht haben? Oder hätten wir das vielleicht besser machen können, und wie?

Wie läuft die Zusammenarbeit zwischen den Teams?

Die Scrum-Teams haben alle ihr eigenes Produkt, aber sie sprechen miteinander, die Inter-Team-Kommunikation ist wichtig. Das funktioniert bei uns auch ziemlich gut. Die Kultur ist da sehr offen, sehr produktiv.

In einem agilen Kontext ändern sich die Anforderungen ständig

In einem agilen Kontext ändern sich ja Anforderungen ständig, und man lernt oft erst, wenn man den nächsten Sprint vorbereitet, was genau das nächste Feature, das man implementieren soll, eigentlich macht. Erst dann geht man so richtig in die Tiefe, auch technisch.

Wenn man dann Endpoints von anderen Teams benutzen will, dann ist es wichtig, mit denen zu reden und abzusprechen, wie genau das jetzt aussehen soll – vor allem, wenn das bei denen ja noch in der Mache ist.

Es ist auch öfter so, dass wir schon Aufgaben reinnehmen, die dann erst in der nächsten Woche fertig werden, die testen das noch grade, da muss man schon mit dem Team reden.

 Ihr arbeitet ja noch nicht so lange agil in dem Unternehmen. Wie hat sich das denn so entwickelt?

Die Firma, bei der ich jetzt arbeite, hat einen sehr traditionellen Hintergrund. Die bevorzugte Projektstruktur war da echt das sogenannte „Waterfall“, also Wasserfall-Modell.

Anfangs gab es schon Probleme, weil Scrum falsch angewendet wurde

Anfangs gab es dann schon Probleme, weil Scrum oft in der Firma falsch angewendet wurde. Man hatte einen Projektmanager anstatt eines Product Owners und der wollte dann natürlich auch bestimmen. Dann ergab sich oft so eine Konstellation, wo der Scrum Master und der Projektmanager zusammen gegen das Team gearbeitet haben. Wenn im Projekt irgendwas nicht lief, wurde das Team ausgelöchert: „Warum habt ihr das nicht fertiggekriegt?“ anstatt zu versuchen, das Problem gemeinsam zu lösen.

Das hat einen schlechten Ruf von Scrum in der Firma hervorgebracht. Wir stempeln da einen Namen drauf, damit wir modern sind, aber so wirklich machen wir es jetzt auch nicht.

Auf jeden Fall braucht man auch die Unterstützung von der Unternehmensführung. Man muss einen Vorschuss von Vertrauen kriegen, damit man diese Strukturen implementieren kann und die Prozesse, die nötig sind, um Scrum ordentlich durchführen zu können.

Man muss einen Vorschuss von Vertrauen kriegen

Wie hat sich das bei euch verbessert?

Die Firma hat angefangen, sogenannte Agile Coaches, also Trainer, einzustellen, die dann in die Projekte gegangen sind, um Angestellte zu schulen. Die haben eng mit den Scrum Masters und Product Owners zusammengearbeitet und sichergestellt, dass wirklich Scrum gemacht wird und nicht nur Waterfall mit anderem Namen.

Agile Coaches stellen sicher, dass wirklich Scrum gemacht wird und nicht nur Waterfall mit anderem Namen

Das hat dazu geführt, dass dann natürlich auch andere Leute eingestellt wurden. Es wurde gezielt nach Leuten gesucht, die mit Scrum arbeiten wollten, die vielleicht auch schon Erfahrung damit haben.

Mittlerweile haben wir eine globale Scrum Communitiy of Practice, also eine Gemeinschaft, wo Leute, die mit Scrum arbeiten, sich alle zwei Wochen treffen und verschiedene Aspekte von Scrum diskutieren. Z. B. hatten wir gestern ein paar Vorträge darüber, wie man den Aufwand von Aufgaben schätzt, und die typischen Fallen, die dabei auftreten.

Generell hat sich das Unternehmen in den letzten Jahren viel dynamischer entwickelt. Die starre Projektstruktur wurde aufgelockert. Die Entwickler sind jetzt alle in einer Art Pool zusammen, aus dem dann je nach Bedarf Teams zusammengestellt werden. Das heißt jetzt nicht, dass wir alle fünf Wochen in einem anderen Projekt arbeiten, aber wenn z.B. festgestellt wird, in dem Projekt brauchen wir jetzt nicht mehr so viele Entwickler, dann werden Arbeitskräfte davon abgezogen und in neue Projekte reingesteckt

Die Wissensbasis der Firma weiter ausbauen

Damit kann man auch die Wissensbasis in der Firma weiter ausbauen. Das ist jetzt sehr in den Fokus gekommen. Diese Communities of Practice, jetzt auch nicht nur mit Scrum, sondern in allen technologischen Bereichen, für Programmiersprachen, für bestimmte Tools, für DevOps, was jetzt auch eine Arbeitsweise aus der Software-Entwicklung ist, die in den letzten Jahren aufgetreten ist. Generell kriegen wir auch viel mehr Schulungen. Scrum hat nämlich sehr viele Nuancen, die man erstmal lernen muss. Es verlangt doch schon mehr vom Team, sich damit auseinanderzusetzen, als beim Waterfall.

Und beim Scrum ist die Rolle des Scrum Masters nicht die eines Managers, sondern quasi eines Lehrers, er soll das Team anleiten, bis er im Optimalfall gar nicht mehr gebraucht wird. Das Selbstmanagement ist im Scrum extrem großgeschrieben, es ist eines der Kernelemente.

Das Selbstmanagement ist im Scrum extrem großgeschrieben

Für welche Menschen oder Persönlichkeiten ist das denn eine gute Arbeit, und welche passen auch gar nicht?

Man muss auf jeden Fall Kritik vertragen und auch geben können. Es ist extrem wichtig, dass die Arbeitskultur im Team auch stimmt, dass man sich vertrauen kann, dass man ehrlich mit sich sein kann.

Der Fokus ist dann auch konsequent auf Teamarbeit. Deshalb ist es wichtig, dass man gut miteinander zusammenarbeiten kann. Das ist bei Kanban, dem anderen beliebten agilen Arbeitsmodell, nicht so wichtig, weil man einfach eine To-do-Liste kriegt, die man abarbeitet. Da gibt’s diese selbstkritischen Elemente von Scrum nicht.

Es geht sehr darum, das Team als Ganzes zu stärken. D.h. dann natürlich auch, die schwächeren Teammitglieder, wenn man das so sagen kann, zu unterstützen, so dass sie am Ende ähnlich oder genauso viel leisten können wie die anderen.

Dann ist es natürlich auch sehr wichtig, dass man bereit ist, neue Sachen zu lernen. Scrum in sich selbst kennt nämlich keine Rollen innerhalb des Teams. Sobald man Entwickler ist, ist man Entwickler, und theoretisch, im Idealfall, sollte man mehr oder weniger jedes Problem im Team lösen können. Natürlich hast du immer Teammitglieder, die etwas besser sind als andere. Es ist wichtig, dass man eine Offenheit dafür zeigt, dass man sich fortbildet.

Im Idealfall sollte jeder jedes Problem lösen können

Wie kommen ältere Kollegen damit zurecht?

Das ist schwer zu sagen. Ich habe nämlich in meinem Team niemanden, der älter ist als 45. Ich weiß von anderen Teams wo es gut klappt. Es kommt echt auf die Person an. Ich habe auch Kollegen erlebt um die 60, die noch echt aufgeblüht sind im Scrum Setup.

Du hast ja geschrieben, dass ihr seit Oktober im Homeoffice seid: wie macht ihr dann Daily Standup?

Ja, wir benutzen momentan TeamsTM. Wir haben eine Zeit ausgemacht, 9.15 Uhr jeden Morgen für einen Videoanruf, wo wir dann das Task Board teilen und uns quasi, wie wir es im Büro würden, zusammensetzen und darüber reden.

Das ist natürlich nicht so effizient. Es ist nicht dasselbe, als wenn man im Kreis steht und die Person anguckt, die jetzt gerade redet. Es ist schon eine andere Aufmerksamkeit erforderlich.

Das Teamgefühl aufrecht erhalten im Homeoffice

Ein anderer Punkt ist, dieses Teamgefühl aufrecht zu erhalten. Normalerweise kann man sich im Büro mal zu einem Kaffee oder während des Mittagessens zusammensetzen und ein bisschen quatschen, vielleicht auch mal nach der Arbeit auf ein Bier irgendwo hingehen. Das fällt jetzt auch alles weg und man muss irgendwie gucken, wie man das ersetzt.

Ich habe schon von Afterwork-Treffen auf Zoom gehört…

Was wir viel machen, ist, zusammen Videospiele spielen. Wir spielen dann Spiele wie Among Us. Aber natürlich ist nicht jeder im Team ein Gamer. Und da muss man dann schon Kompromisse finden. Aber dann so alle 2 bis 3 Wochen sollte es etwas sein, was das ganze Team machen kann.

Sebastian, vielen Dank für deine lebendige Schilderung!

Über den Autor

Sabine Neugebauer

1 Kommentar

Schreiben Sie einen Kommentar zu Sebastian Schneider Cancel reply

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

  • Sehr guter Beitrag zum Thema Scrum Master! Schön, dass du deine Erfahrung mit uns teilst! Aus Erfahrung kann ich sagen, dass Zwischenergebnisse sogenannte Mile Stones sein können, bei denen man immer wieder nachjustiert. Letztlich lassen sich bessere Ergebnisse erzielen und es gewährleistet eine bessere Kommunikation untereinander.

Von Sabine Neugebauer

Neueste Beiträge

Neueste Kommentare

Archiv

Kategorien

Schlagwörter