Inhaltsverzeichnis
Scrum ist nun schon deutlich über 10 Jahre alt und erfreut sich wachsender Beliebtheit, zumindest in der öffentlichen Diskussion.
So verwundert es, dass in den meisten Unternehmen, die neue Projekte beginnen, Scrum immer wieder neu eingeführt werden muss, weil weder Teams noch Projektleitung darin sehr geübt sind.
Somit beginnen viele Projekt zunächst damit, das Scrum Team und den Product Owner, vielleicht sogar die ganze Projektorganisation, in der das Projekt eingebettet ist, fit für die Methodik zu machen.
Da Scrum als Implementierungsmethodik ohnehin ein Kompromiss ist, mit einer nicht perfekten Welt umzugehen, ist die Unkenntnis der Methodik eine weitere schwere Hypothek und Grund für das Scheitern vieler Projekte.
In einer solchen Situation stehen Scrum Coaches, Scrum Master und agile Projektmanager vor der Herausforderung, die Teams und Stakeholder möglichst schnell fit für den effektiven Einsatz von Scrum zu machen. Dabei wird es von entscheidender Bedeutung sein, die richtigen Akzente zu setzen und Kompromisse an genau der richtigen Stelle zu machen.
In diesem Beitrag möchte ich einen Ansatz vorstellen, der in meiner Praxis gut funktioniert hat und nach sehr wenigen Sprints stets signifikante Verbesserungen zeigt.
Selten war der Spruch‚ „Hast Du es eilig, geh langsam“, so passend wie in dieser Situation.
Scrum sieht auf den ersten Blick verführerisch einfach aus, was in der Praxis oft dazu führt, dass Scrum – sagen wir mal – sehr mechanisch eingeführt und die Herausforderung deutlich unterschätzt wird.
Schritt 1: Wissen, worauf es ankommt - die richtigen Kompromisse machen
Wenn in einem schwierigen Umfeld etwas schnell erledigt werden soll, dann ist klar, dass gewisse Kompromisse gemacht werden müssen.
Ein Kompromiss ist nicht per Definition gut oder schlecht. Kompromisse machen ist nie sehr effizient, Kompromisse sind in der Regel auf die Erreichung eines bestimmten Zieles gerichtet, sie stehen also mehr auf der Seite der Effektivität, übrigens genauso wie Scrum als ein Kompromiss den Fokus von effizienter Softwareentwicklung auf effektive Softwareentwicklung verschiebt.
Ich muss sicher nicht ausführen was passiert, wenn Sie in der Eile die falschen Kompromisse machen: es passiert genau das, was immer passiert. Dafür wurde das schöne Wort ‚Verschlimmbessern‘ so wunderbar treffend erfunden.
Die Frage ist, wie finden Sie heraus, welche Kompromisse für die Erreichung Ihres Zieles gut sind und welche es nicht sind, denn Kompromisse werden Sie machen müssen.
Diese Frage lässt sich glücklicherweise eindeutig beantworten: Scrum beruht im Wesen auf nur zwei Grundprinzipien, auf Commitment und Completion. Da Scrum im Kern auf nur diesen beiden Paradigmen beruht – es hätten durchaus mehr sein können, wie Qualität, Velocity oder Teamarbeit – sollte jedem einleuchten, dass keines von beiden wirklich verhandelbar ist, also für einen Kompromiss taugt.
Bleibt mein Scrum Team bei dem was ich jetzt ändern möchte noch Commitment- und Completion-fähig?
Schritt 2: Fertig werden üben
- ‚ich bin fertig, habe aber noch nicht getestet‘
- ‚ich bin fast fertig‘
- ‚gestern hat es noch funktioniert‘
- ‚ich bin fertig, wir müssen da später aber vielleicht noch mal ran‘
- ‚eigentlich bin ich fertig‘
Die Liste könnte ich noch eine gute Stunde fortsetzen, der Kreativität der Entwickler scheint da kaum eine Grenze gesetzt zu sein.
Wenn SCRUM aber nun auf nur zwei Paradigmen beruht und eine davon ‚Completion‘ ist, dann ist natürlich klar, dass es wesentlich darauf ankommt, eine klare Definition des Begriffs ‚fertig‘ zu finden und diesen Prozess des Fertigwerdens überhaupt erst einmal einzuüben.
Der Begriff ‚fertig‘, der in SCRUM zu Anwendung kommt, leitet sich aus der ‚Definition of Done‘ ab und ist nicht verhandelbar.
Mein Golflehrer sagte mir zu Beginn meiner Karriere: ‚Das Wesen des Golfspiels beruht darauf, den Ball in die Luft zu bekommen. Dass er auch weit und in die richtige Richtung fliegt ist am Anfang ganz sekundär, das kommt später von ganz alleine‘. Und so war es dann auch.
Wenn Sie Ihr Scrum Team erstmal dazu kriegen, eine Story abzuschließen, dann haben Sie schon die halbe Miete eingefahren.
Im ersten Sprint sage ich dem Scrum Team immer, es ist völlig egal, wie lange es für die Implementierung einer Story braucht, mir ist völlig egal, ob sie vier, zwei oder nur eine Story im Sprint schaffen.
Velocity ist kein Thema, Velocity ist der erste große Kompromiss den ich eingehe, um das Lernziel ‚Completion‘ zu erreichen.
Ja, ich motiviere die (oft erstaunten) Teams geradezu die einzelnen Tasks möglichst pessimistisch und richtig satt zu schätzen. So satt, dass sie in jedem Fall mit der Story fertig werden und wenn es nur eine kleine Story ist.
Sie sollen sich daran gewöhnen, ein Commitment so zu geben, dass sie es unter allen Umständen auch halten können.
Hier müssen Sie als Scrum Coach oder Projektleiter Geduld haben. Wenn ein Scrum Team sich an das Fertigwerden gewöhnt hat, kommt die Velocity von ganz alleine.
Wenn Sie es konsequent machen, dann dauert das nicht länger als 2 bis 3 Sprints. Ich weiß, zwei Sprints können sehr teuer sein und es fällt schwer, zwei Sprints diese Geduld aufzubringen, man muss sich da schon richtig auf die Lippen beißen.
Aber bedenken Sie, Scrum sieht nur auf den ersten Blick so einfach aus, in der Tat ist es das nicht und mit zwei Sprints sind sie gar nicht mal schlecht bedient.
Das Fertigwerden-üben beinhaltet insbesondere den Prozess, des Erstellens eines Commitments, welches im Sprint-Planning 2 durch das Schätzen der technischen Subtasks für eine Story geschieht. Softwareentwickler schätzen in der Regel immer zu optimistisch. Das hat wesentlich drei Gründe:
Es ist die Stunde des Scrum Masters, der darauf achten muss, dass für eine Story ausreichend Subtasks für alle oben genannten Dinge erstellt werden, dass ausreichend Puffer einkalkuliert wird und fair geschätzt wird.
Da kann plötzlich eine simple Story, die nur ein User-Profil in einem Fenster anzeigen soll, schon schnell mal 4 Tage Aufwand bedeuten.
Scrum verlangsamt nicht die Entwicklung, Scrum ist wie ein Karies-Test – ‚oh alles rot‘ – Scrum macht den Prozess transparent und gibt Ihnen später die Möglichkeit gezielt an der Velocity zu arbeiten.
Um sich das nutzbar zu machen, achten Sie von Anfang an darauf, dass einzelne Subtasks für einzelne Entwickler nie länger als 8 Stunden dauern dürfen. Vergessen Sie nicht, dass ein zweistündiger Workshop mit 3 Teilnehmern nicht 2 sondern 6 Stunden Aufwand bedeuten und dass eine Story auf keinen Fall länger als ein Sprint dauern darf.
Schritt 3: Kommunikation im Scrum Team verändern
Nehmen wir als bestes und einfachstes Beispiel das Daily Standup
Viele Scrum-Master gehen hier sehr mechanisch vor und fragen die drei Fragen nach Lehrbuch: ‚Was hast Du gestern gemacht?‘, ‚Was planst Du heute zu tun?‘ und ‚Was hat Dich daran gehindert, deine gestrige Aufgabe zu erledigen?‘.
Das mag zwar sehr kommunikativ erscheinen, denn man unterhält sich ja über die Arbeit im aktuellen Sprint, geht aber am Kern des Meetings oft ziemlich vorbei.
Auch hier nehmen wir ernst, worauf Scrum tatsächlich beruht, auf Commitment und Completion. Und genau diese gilt es, im Daily Standup zu überprüfen.
Das einzige, was mich als Scrum Master im Daily wirklich interessiert ist die Frage, ob das Commitment noch gilt.
Der zweite Aspekt der Kommunikation,
der ebenfalls gleich am Anfang eingeführt werden muss ist die Perspektive der Kommunikation
Scrum Projekte scheitern oft daran, dass Teams auf Biegen und Brechen ihre gewohnte wasserfallartige, technische Perspektive in den Scrum-Prozess pressen möchten.
Scrum führt eine radikal vertikale, feature-orientierte Softwareentwicklung ein, während das gewohnte Wasserfall auf eine horizontale, layer-orientierte Entwicklung setzt (siehe Scrum vs. Wasserfall). Den Teams muss gleich am Anfang unmissverständlich klargemacht werden, was das bedeutet.
Die meisten Teams sehen die Methodik überhaupt nicht unter diesem Aspekt. Sie denken, dass lediglich Ihre Arbeit etwas anders organisiert ist, aber das sonst alles beim Alten bleibt, sie also wie gewohnt schön damit beginnen ein Datenmodell zu erstellen und sich Gedanken über einen Data-Access-, einen Business-Logik- und Repräsentations-Layer machen, statt für die erste Funktion einen kleinen Prototyp durch alle Schichten hindurch zu entwerfen.
Folgerichtig hören wir dann auch immer wieder die Argumente von Entwicklern, dass sie ohne Architekturmodell gar keinen Prototypen bauen können oder ohne ausgereiftes Datenmodell später alles refactored werden muss.
Scrum führt eine feature-orientierte Perspektive ein, der Product Owner beschreibt die Stories aus rein funktionaler Perspektive, es gibt keine technischen Stories, die Sprache im Planning 1 ist rein funktional und repräsentiert ausschließlich die Anwenderperspektive.
Je früher Sie Ihr Scrum Team dazu bekommen im Planning 1 die Dinge aus der Perspektive des Product Owners zu sehen, desto eher sind sie in der Lage, neben den Anforderungen der Stories auch die Vision des Produktes zu verstehen, und basierend darauf schon sehr früh wesentliche Technologie- und Architekturentscheidungen zu treffen.
So funktional die Sprache im Planning 1 ist, so technisch wird sie dann im Planning 2, denn hier geht es nur noch darum, für die gerade diskutierte fachliche Anforderung einen – so konkret und detailliert wie irgend möglich – technischen Implementierungsplan zu erstellen. Die darin kreierten Subtasks dürfen sich nur noch mit dem technischen ‚wie‘ befassen.
Die meisten Sprint-Backlogs sind auf Story-Ebene zu wenig fachlich bzw. schon zu technisch (bis hin zu reinen technischen Stories) und gleichzeitg auf Subtask-Ebene viel zu wenig technisch, beschreiben also immer noch das ‚was‘ aber nicht das ‚wie‘ (z.B. Funktion implementieren, Funktion testen, Funktion dokumentieren, etc. statt Class xy um Methode z mit folgenden Properties erweitern).
Schritt 4: Retrospektive nutzen
Als Maß für das Besserwerden können und sollten Sie die Velocity berechnet aus Story Points verwenden.
Auch wenn wir oben in den ersten Schritten beim Fertigwerden-lernen den Fokus auf Commitment und Completion legten und die Velocity explizit als Fokusthema abgewählt haben, so bleibt sie doch das Maß der Lernkurve.
Die Velocity stellt sich von allein ein, wenn die Voraussetzungen erfolgreich geschaffen wurden. Um das zu erreichen, fehlt nun noch ein letzter Schritt.
Um erfolgreich besser zu werden, sollte der Prozess des Besserwerdens institutionalisiert werden, Sie brauchen ein explizites Forum, in dem Sie sich mit dem Besserwerden beschäftigen können, wo das und nur das Thema ist und nicht irgendwo nebenbei behandelt wird.
Dieses Forum ist die in der Praxis völlig unterschätzte Sprint-Retrospektive. In einem Wasserfallprozess durchlaufen Sie den Softwareentwicklungszyklus aus Spezifikation, Implementierung, Test, Dokumentation, Rollout nur einmal.
Eine Lessons-Learned am Ende des Projektes (sehr beliebt beim Management) macht strenggenommen gar keinen Sinn, denn das nächste Projekt könnte völlig anders sein, anderer Gegenstand, anderes Team, andere Umgebung, etc.
In Scrum durchlaufen Sie den gesamten Prozess in jedem Sprint und es gibt viele Sprints, also viele Gelegenheiten im aktuellen Projekt Dinge zu verbessern.
Die Sprint-Retrospektive ist die institutionalisierte Instanz für die Erzeugung einer Lernkurve.
Der einzige Ort, wo Sie das wichtigste in Scrum managen können – nämlich die Frage, wie können wir unseren Prozess optimieren und schließlich die Velocity steigern.
Neben allen Hinweisen, was andere besser machen sollten, also Projektleiter, Product Owner, der Papst oder sonst wer, sollte der Scrum Master darauf achten, dass das Scrum Team pro Sprint in der Retrospektive mindestens eine Sache identifiziert, die das Team selbst besser machen möchte.
Im Folgesprint sollte diese eine Sache dann auch bewusst angegangen werden, quasi als Sprintziel mit aufgenommen werden und am Ende genauso begutachtet werden, wie die Stories.
Nur so bekommen sie auch hier einen Routineprozess in Gang dessen Erfolge nicht lange auf sich warten lassen werden.
Was hat die Neuregelung des AÜG mit Scrum zu tun? Ich meine viel und möchte auf die neuen Herausforderungen, die sich daraus für die Planung von SCRUM Projekten in vielen Unternehmen ergeben in diesem Artikel eingehen.
Scrum vs. Wasserfall – Für alle Scrum Fans die schlechte Nachricht zuerst: Scrum ist nur ein Kompromiss. Die gute Nachricht, dies ist die einzige schlechte Nachricht..
Der Erfolg von agilen Projekten hängt mit der Kommunikation zusammen! Leonardo DiCaprio in seiner Rolle in ‚Inception‘ ist heute Ihr Scrum Coach und verdeutlicht, wie in Scrum erfolgreich kommuniziert werden kann. Klingt abenteuerlich? Ist es auch 🙂 Lesen Sie weiter…
