Agil entwickeln ja jetzt alle.
Wir seit 142 Sprints. Ein kleiner Rückblick.
10.08.2024
Von Teo
Irgendwann im frühen Frühjahr 2025 werden wir unseren 150. Sprint feiern. Unsere Erfahrung mit agilen Entwicklungsmethoden wird dann mehr als sieben Jahre zurückreichen. Wir haben nicht von Anfang an das volle Scrum-Programm gefahren, aber wir waren auch nie AINO :). Niemand bei uns möchte in die Zeit vor Scrum zurück, aber es gibt einige Dinge, die wir heute anders machen würden.
The Iterators.
We are the most iterative, incremental and T-shaped, pulling, story-telling, Fibonacci nerds and collaborators that exist wherever there may or may not be dragons!
Ein Kanban Bord mit dem Sprint-Backlog. Wir haben für den Sprint eine Time-Box von drei Wochen und starten Dienstags. Da sind alle da, auch die 80% Leute und es ist freundlicher fürs Wochenende den Sprint an einem Dienstag zu schließen als an einem Montag.
Agile Entwicklung und Scrum ist ein Thema über das wirklich alles schon geschrieben wurde. Deshalb werde ich hier keinen weiteren Artikel darüber verfassen, wie Scrum funktioniert (Scrum ist nicht die einzige agile Methode, aber ca. 2/3 aller agilen Teams benutzen Scrum als Framework. Siehe: The 17th State of Agile Report) und was die Vorteile sind und warum man überhaupt unbedingt agil arbeiten sollte. Lieber teile ich ein paar Erfahrungen und Beobachtungen, die wir auf unsere Reise in's agile Arbeitsleben gemacht haben und freue mich, wenn für den oder die ein oder andere etwas Interessantes dabei ist.
Warum nur haben wir damit angefangen?
Wenn dein gesamtes Umfeld, deine Projektstrukturen, deine Kunden, deine Entwicklungsumgebung und die Art und Weise, wie du und deine Teams seit über 20 Jahren arbeiten, nicht agil sind, dann ist das erst mal eine sehr berechtigte Frage. Du willst Sprints, Reviews und User Stories, alle anderen wollen lieber Lasten, Pflichten, Abnahmeprotokolle und möglichst vollständige Spezifikationen. Und sie möchten, dass ihnen jemand sagt, was sie tun sollen. Das passt nicht zusammen und hat uns anfangs daran gehindert, Scrum so umzusetzen, wie es der Scrum-Guide vorsieht.
Als Stephan, unser Entwicklungsleiter, als erster bei uns seinen Scrum Master gemacht hat (und zwar bei Jeff Sutherland himself! Yas!), hat er uns alle erst mal damit angesteckt. Zum einen kam die Methode unserer Vorstellung von Selbstbestimmtem Arbeiten sehr nahe, vor allem aber fühlte es sich einfach richtig an.
Es war ein bisschen so, wie wenn wir als Bildhauer jahrzehntelang so gearbeitet hätten, dass wir uns einen ganz genauen Plan von einer Statue gemacht hätten, und dann hätten wir den Meißel unten links am Block angesetzt, um von dort nach rechts oben alles perfekt und bis ins letzte Detail herauszumeißeln, und dann kommt jemand und sagt: Hey, lass uns erst mal die grobe Form herausarbeiten und dem Ganzen ein bisschen Proportion geben. Dann kommen wir nach und nach zu den Details, und wie die genau aussehen, das können wir uns bis dahin überlegen. Wir können unserer Auftraggeberin einfach immer mal wieder einen Zwischenstand zeigen und dann überlegen wir gemeinsam, wie es weitergeht. Erinnert ihr euch noch an den Auftrag für die Venusstatue, wo wir die ersten vier Entwürfe wegwerfen mussten, weil der Hans sich erst mal vermeißelt hat, wir dann vergessen hatten zu spezifizieren, dass sie Sandalen tragen soll und am Ende die Beine irgendwie zu kurz waren? Ach ja, und die Muschelschale, die sie in der Hand hatte, die war auf der Zeichnung etwas ungenau, also mussten wir auch die Version wegwerfen, wo sie den Teller mit den Meeresfrüchten hält. Das kann man doch anders machen!
Agil war für uns deshalb so attraktiv, weil klar war, dass alle bisherigen Modelle einfach weltfremd waren.
El Producto: Jeder hat zu Beginn eines Projektes seine eigenen Vorstellungen und Erwartungen. Nur ein guter PO kann helfen, das zu synchronisieren, denn der Scrum Guide sagt dazu nichts.
Schritt für Schritt einführen würde ich wieder machen und eigentlich aber doch lieber nicht.
Da wir uns und unserem Umfeld die Chance geben mussten, sich auf die neuen Methoden einzulassen, haben wir Scrum schrittweise eingeführt. Und zwar ungefähr in dieser Reihenfolge
- Erst mal: Backlogs, Sprint-Backlogs, Dailys, Sprint-Planung, Story-Points, Scrum Master, Pull und teilweise Retros.
- Dann: Reviews, erste Versuche mit einer DoD, teilweise Product Owner
- Schließlich: Product Owner, Product Goal, Sprint Goal, richtige Backlogs, richtige User Stories, richtige Retros
Der erste Schritt hat uns vor allem mehr Transparenz und ein besseres gegenseitiges Verständnis dafür gebracht, was Product Owner, Entwickler und Designer machen. Dazu hat auch das Schätzen mit Story Points wesentlich beigetragen, auch wenn sich einige am Anfang damit schwer getan haben. Aber wenn man schätzen muss, wie viel eine Aufgabe wert ist, dann lernt man etwas darüber, woraus sie tatsächlich besteht, und das wiederum sorgt für ein besseres Verständnis im ganzen Team, was es eigentlich bedeutet, eine Aufgabe zu erledigen - von der ersten Idee bis zum Backend.
In einem zweiten Schritt hatten wir die Möglichkeit, in neuen Projekten Reviews einzusetzen, um unsere Kunden und Stakeholder besser einzubinden und zu lernen, wie wir ihr Feedback am besten in unsere Arbeit integrieren können. Das klingt einfach. Tatsache ist aber, dass der Scrum-Guide in vielen Bereichen bewusst unvollständig ist und offen lässt, wie bestimmte Elemente genau auszugestalten sind. "Anstatt den Menschen detaillierte Anweisungen zu geben, leiten die Regeln von Scrum ihre Beziehungen und Interaktionen." Das Herausfinden, "wie es funktioniert", ist daher oft eine echte Herausforderung. Einige Teams waren bei der Implementierung von Scrum auch schneller oder geschickter als andere, und das war auch eine Chance, voneinander zu lernen.
Deshalb kommt in der dritten Phase dreimal das Wort "richtig" vor. Wir haben vom ersten Tag an Dailys und Swarmings gemacht, aber erst im dritten Schritt haben wir wirklich verstanden, wie wir sie so einsetzen können, dass wir effizienter und vor allem vorausschauender arbeiten können. User Stories helfen uns heute, Mini-Wasserfälle zu vermeiden. Früher haben wir die Aufgaben gerne gleich in UX, Frontend und Backend aufgeteilt und im UX-Teil so gut wie möglich spezifiziert und genau dadurch natürlich erst Spezifikationslücken produziert. Heute spezifiziert das Team zumindest bei komplexeren Aufgaben gemeinsam und wenn etwas im ersten Sprint noch nicht so ist, wie es sein sollte, ist das kein Fehler oder unfertig, sondern eine Chance für eine bessere Version in der nächsten Iteration.
POs helfen den Fokus zu halten
Eine wichtige Erkenntnis war auch das Produkt noch ernster zu nehmen. Das ist auch der Grund, warum die POs für mich die mit den Superkräften sind. Eine gute PO, die weiß, was wirklich wertvoll ist und die mit allen gut kollaboriert, ist Gold wert. So können sich alle darauf fokussieren, die Arbeit zu machen, die als nächstes wichtig ist, während die PO dafür sorgt das immer die richtigen Aufgaben in der richtigen Art und Weise im Backlog auftauchen.
Epic basierte Release Planung mit Details bis herunter auf die einzelne User Story
Mit dem, was wir bei Sprint 1 wussten, wie unser Umfeld damals organisiert und wir als Unternehmen aufgestellt waren, würde ich auf jeden Fall wieder eine schrittweise Einführung bevorzugen, um die Chance zu haben, zu lernen und die Teams nicht zu sehr unter Druck zu setzen. Aber wenn ich mit der Erfahrung und dem Wissen, das wir heute haben, noch einmal zurückgehen könnte, würde ich Scrum in viel kürzerer Zeit einführen.
Was mir am besten gefällt.
Ganz oben steht wohl der Einfluss auf die Art und Weise, wie wir etwas umsetzen wollen und die insgesamt bessere Qualität in der Entwicklung bei höherer Effizienz, was zum Teil auch auf ein besseres technisches Setup zurückzuführen ist, das wiederum ohne agile Methoden auch nicht ohne weiteres einsetzbar wäre. Dann kommt vielleicht noch dazu, dass durch das Backlog klare Prioritäten geschaffen werden, Projekte besser steuerbar sind, weil das ganze Team versteht, wo wir gerade stehen und was noch fehlt, und zwar über alle Gewerke hinweg. Unsere Kunden schätzen, soweit ich weiß, die hohe Transparenz, die Verbindlichkeit, wann sie was erwarten können und dass sie besser Einfluss auf ihre Projekte nehmen können. Ich erwähne das, weil das auch für uns ein angenehmeres Arbeiten ist, wenn wir dem Kunden nicht ständig sagen müssen "Das haben Sie so nicht spezifiziert" oder "Das haben Sie aber im Design so abgenommen", sondern wenn wir im Review besprechen, wie die nächste Iteration aussieht, ob ein gewünschtes Feature dann implementiert werden soll oder ob es zu aufwendig ist oder ob etwas anderes wichtiger ist. Das wichtigste Kriterium dafür, dass wir auf dem richtigen Weg sind, ist aber für mich, dass die Teams hinter unserer Entwicklung stehen.
Luft nach oben.
Ein ganz ordentlicher Burndown, aber wie schön wäre er gewesen, wenn zu Beginn der zweiten und dritten Woche nicht noch zusätzliche Arbeit nachgelegt worden wäre.
Natürlich, die gibt es. Für manche Teams ist Scrum in Teilen schwierig, weil sie eher an Projekten als an Produkten arbeiten und nach einer Launch-Phase in eine Support-Phase übergehen, in der zum Beispiel viel unter dem Sprint gezogen werden muss und mit jedem neuen Projekt ein Projekt dazukommt, was potentiell irgendwann zu noch mehr Support führt.
Das Team ist auch nicht so konsistent, wie es sein sollte. Viele arbeiten im Laufe der Zeit an mehreren Projekten und mit wechselnden Teammitgliedern. Das macht es schwierig, die Events so zu organisieren, dass immer die Leute zusammenkommen, die sich auch etwas zu sagen haben. Hier arbeiten wir in den Retros an guten Anpassungen, die uns helfen, diese Probleme in den Griff zu bekommen. Dann gibt es immer noch Stakeholder, die erst das Vertrauen aufbauen müssen, das diese Arbeitsweise voraussetzt. Da hilft nicht viel mehr als Geduld. Und natürlich: UX und Design z.B. mit Ansätzen aus Lean-UX und der Idee des evidenzbasierten Designs in agile Setups zu integrieren ist nicht nur für unsere Teams eine ganz eigene Herausforderung.
Die beste Hilfe: Pragmatisch bleiben.
Eine Sache, die ich im Laufe der Zeit gelernt habe, hat mir sehr geholfen. Und zwar die simple Erkenntnis, dass es am Ende darum geht, funktionierende Software zu entwickeln. Genau so wie es in den vier Werten des Agilen Manifests steht. Überhaupt sind die eine echte Hilfe, um von nicht agil zu agil zu kommen. Der Pragmatismus, der darin anklingt, hat mir oft geholfen, mit Scrum nicht genau die Bürokratie und Schwerfälligkeit wieder einzuführen, die ich eigentlich abbauen wollte, weil es eben nicht darum geht, Regeln zu befolgen, sondern am Ende funktionierende Software zu entwickeln. Dazu gehört auch die Tatsache, dass spätestens durch Retros das allermeiste reversibel ist. Es schadet nicht, mal etwas zu riskieren, denn das Team merkt schnell, ob eine Maßnahme hilfreich war oder nicht und dann kommt sie einfach nicht über die Testphase hinaus.