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 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.

Nämlich der Herausforderung ein Team in einem bereits laufenden Projekt – egal ob das Projekt gerade erst begonnen hat, oder der erste Scrum-Einführungsversuch gescheitert ist – schnell und gleichzeitig nachhaltig in Scrum einzuführen. Die Voraussetzung für die schnelle und erfolgreiche Einführung von Scrum ist Geduld, wir werden etwas weiter unten darauf zurückkommen.

Der hier beschriebene Ansatz funktioniert insbesondere deshalb so gut, weil die Probleme in vorher gescheiterten Scrum-Einführungen oder in neuen, unerfahrenen Teams fast immer die gleichen sind.

Dies wiederum liegt daran, dass ein Scrum-Master Zertifikat in zwei Tagen ‚geschossen‘ werden kann, oder anders ausgedrückt, es liegt oft daran, dass Scrum wenig komplex ist, mit wenigen Rollen auskommt, nur wenige Prozesse kennt, überschaubare Artefakte definiert und auf sehr wenigen Paradigmen beruht.

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.

Es wird übersehen, wie perfekt diese wenigen Dinge ineinandergreifen müssen, damit ein sehr effektiver Prozess in Gang kommt. Oder anders ausgedrückt, es gehört schon viel Genie dazu ein Kunstwerk mit nur einem Pinsel und zwei Farben zu erstellen. Und wenn es gelungen ist, dann sieht es für den Betrachter absolut simpel aus, und doch wird er es nie nachmachen können. Fragen Sie mal bei Picasso nach.

Der zweite Grund, warum dieser Ansatz fast immer funktioniert liegt darin, dass dieser Ansatz quasi die Reset-Taste drückt und Scrum unabhängig und voraussetzungslos neu einführt.

Auch dies ist nur möglich, weil Scrum in der Tat eigentlich wenig komplex ist, man muss es nur richtig machen, dann kann es schnell gehen. Leicht ist es allerdings nicht.

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.

Machen Sie bei einem der beiden Kompromisse, dann kompromittieren Sie schon 50% der gesamten Basis Ihrer Methodik. Das kann nicht gut sein. Wenn Sie sich also überlegen, welche Kompromisse Sie machen dürfen und welche Sie auf gar keinen Fall machen können, dann stellen Sie sich folgende Frage:

Bleibt mein Scrum Team bei dem was ich jetzt ändern möchte noch Commitment- und Completion-fähig?

Wenn Sie diese Frage nicht mit einem klaren ‚ja‘ beantworten können, dann ist das was Sie gerade vorhaben definitiv kein guter Kompromiss.

Alles, was die Commitment- oder Completionfähigkeit eines Teams in Gänze oder in einem Sprint negativ beeinflusst, sollte unterlassen werden. Alles andere können Sie weiter in Erwägung ziehen.

2. Fertig werden üben

Das erste, was ich mit Teams trainiere ist Fertigwerden. Dies leitet sich unmittelbar aus dem vorher über das Wesen von Scrum Gesagten ab.

Nehmen Sie es mir nicht übel: Softwareentwickler haben ungefähr genauso viele Definitionen des Begriffs ‚fertig‘, wie Eskimos vom Begriff ‚Schnee‘.

Und wir haben sie in unserer täglichen Praxis auch alle schon oft gehört:

• ‚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 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 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:

Beim Schätzen einer Story werden immer wieder eine Reihe von Tasks vergessen, es wird im Wesentlichen nur die Implementierung geschätzt und solche Tasks wie Unit-Tests, Code-Dokumentation, Code-Review, Continuous-Integration, Code-Refactoring, Präsentation vorbereiten, Know-how Transfer, Workshops, Kaffee trinken, in Facebook mit Freunden chatten werden regelmäßig schlicht vergessen.

Dann sind Entwickler jeder für sich ja auch Superhelden, und nach dem Motto ‚wer bremst, verliert‘ will jeder mit seiner Schätzung nicht wie der Loser dastehen.

Und schließlich schätzen Entwickler immer den Happy-Path, sie gehen immer davon aus, dass immer alles glatt läuft und sie sofort nach dem Planning und bis zum Review ohne Unterbrechung und ohne Störung ihren Code schreiben können und immer alles sofort perfekt ist.

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.

Kommunikation im Scrum Team verändern

Um den Prozess des Fertigwerdens zu unterstützen und dann auch zügig einen Übergang zu finden, um die Velocity zu erhöhen, ist es im nächsten Schritt erforderlich an der Kommunikation zu arbeiten.

Es geht hier weniger darum wie kommuniziert wird, sondern mehr darum was kommuniziert wird bzw. worauf sich die Kommunikation bezieht.

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.

Und diese Frage würde ich den Team Mitgliedern daher auch genau so stellen:

‚Gilt Unser Commitment für diesen Sprint heute noch?‘.

Denn erstens kann diese Frage mit einem klaren Ja oder klaren Nein beantwortet werden. Bei einem ‚ja‘ ist das Meeting dann auch sehr kurz, nämlich unmittelbar zuende.

Bei einem ‚nein‘, geht die Diskussion sofort in Richtung Completion. Neben der Aufnahme der Impediments gilt nun sofort zu klären welche der Stories denn noch die Chance haben, fertiggestellt zu werden bzw. wie das Sprintziel noch erreicht werden kann.

Zweitens wird dem Team immer wieder klar der Bezug zum Wesen der Methodik vermittelt. Das sollte so lange und so penetrant eingeübt werden, bis das Besinnen auf Commitment und Completion so selbstverständlich sind wie das morgentliche und abendliche Zähneputzen. Auch das ist uns ja mal vor langer Zeit durch permanentes, tägliches und vor allem kompromissloses Wiederholen erfolgreich vermittelt worden.

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 Wasserfall vs. Scrum). 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 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.

Erreichen tun Sie das, indem alle technischen Diskussionen aus dem Planning 1 verbannt werden und nur über die funktionale Anforderung gesprochen wird, bis die Gehirne der Entwickler mit dem des Product Owners gleichgeschaltet sind.

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).

Retrospektive nutzen

Alles oben Gesagte setzt einen Prozess des Besserwerdens in Gang.

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 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.