Ach, Scrum bringt doch nichts. Oder doch?

Mitte Dezember 2012 habe ich in meinem Team mitgeteilt, dass ich gerne Scrum einführen würde. Schnell wollte jeder wissen, wie der Hase läuft. Ein paar einschlägige Bücher und Diskussionen waren die Folge. Die Einigung erfolgte schnell. Seitdem setzen wir Scrum ein. Bisher versuchten wir uns penibel an die in der Literatur beschriebenen Rahmenwerke zu halten. Wir hatten schon einmal den Fehler gemacht, mit einer für uns passend gemachten Ausprägung zu starten. Und wir scheiterten. Und nun?

Ich will auch gar nicht lange darauf eingehen, wie wir Scrum behandeln. Im Wesentlichen haben wir unsere Inhalte aus Scrum – Agiles Projektmanagement erfolgreich einsetzen (Pichler) und Die Kraft von Scrum (Wolf) bezogen und versuchen da so nahe wie möglich dran zu bleiben. Keine Experimente, die Zeit wird wohl noch kommen.

Sehr interessant waren dabei die Auswirkungen auf das Team. Die meisten von uns waren unberührt von diesem Thema. Natürlich schielt man als Softwareentwickler auf diverse Methoden und pickt sich den einen oder anderen Teilbereich heraus. Es ist dann aber schon eine ganz andere Liga, Nägel mit Köpfen zu machen, ins kalte Wasser zu springen und die gesamte Art und Weise der Projektentwicklung umzustellen. Dementsprechend hatten wir es natürlich mit jeder Menge Ängste und Sorgen zu tun.

Ängste, Sorgen und Probleme

“Ab heute ist alles anders”. Ja, das wirft schon jede Menge Fragen auf. Vor allem dann, wenn man die Folgen nicht wirklich abschätzen kann. Veränderung fördert Angst. Angst lähmt. Was waren die einzelnen Faktoren?

• Vollkommene Transparenz kommt einer Überwachung gleich. Bisher kamen ellenlange Spezifikationen zur Umsetzung. Ein Abschätzen der Entwicklungsdauer war nicht möglich. Ein Überziehen stand an der Tagesordnung. Durch die kleineren Happen, die höhere Transparenz sieht de facto jeder, wer gerade woran arbeitet, wie der Fortschritt ist, was noch fehlt und wo die Probleme liegen. Das fördert das Gefühl, überwacht zu werden. Das ist natürlich keineswegs die Intention, ändert aber nichts an der Tatsache, dass so mancher im Team genau davor Angst hat. Nicht des Verbergens wegen, sondern vielmehr der Angreifbarkeit.
• Gemeinsames Arbeiten am selben Feature. Das Aufteilen einer User Story in kleine Happen (Tasks) kann schon seine Tücken mit sich bringen, vor allem wenn Abhängigkeiten bestehen und man sich schon Gedanken darüber machen muss, welches davon die wirklich wichtigen Arbeiten sind. Wenn jahrelang für ein Feature immer genau ein Entwickler zuständig ist, dann fehlt vielfach der klare Gedanke daran. Es entsteht der Eindruck, dass es gar nicht möglich ist, gemeinsam an einer größeren User Story zu arbeiten bzw. dass der Aufwand viel höher ist, als bei einer Umsetzung durch eine einzelne Person.
• Angst um Spezialbereiche. Ich setze ein Feature alleine um, dann bin ich darin der Experte. Ich bin also wichtig. Arbeiten mehrere Personen am selben Feature, dann trifft das nicht mehr zu. Es entsteht also die Angst, an “zuerkannter Kompetenz” und/oder Verantwortungsbereiche einzubüßen.
• Transparenz gegenüber Business. Der Business-Bereich weiß ganz genau Bescheid, was denn aktuell in Entwicklung ist, wie es um den Stand bestellt ist und wer was macht. Das kann doch nicht gut gehen und zweitens ist der “Einmischfaktor” zu hoch. Wichtige technische Punkten müssen somit diskutiert werden, konnten bisher aber ohne Probleme “eingefächert” werden.
• Zeitverlust. Sprint Planning, Recap Meeting. Das alles verbraucht doch soviel Zeit. Zeit, die man viel produktiver nutzen kann. Ran an den Punkt und arbeiten. Es ist schwierig, den “Machern” einzutrichtern, dass ein gemeinsames Verständnis, eine gemeinsame Vorgehensweise seine Vorteile mit sich bringt. Auch wenn die Meetings mitunter lange dauern. Im Vordergrund steht, dass der Entwickler eben Code schreiben und nicht reden will. Eine schwierige Sache.

Das sind schon durchaus gravierende Punkte, di in zahlreichen Gesprächen ausgeräumt werden müssen. Wichtig hierbei ist, es vorzuleben. Von “oben herab” funktioniert da erst einmal gar nichts – und das ist auch nicht Sinn und Zweck.

Vier Monate später

Nun sind über vier Monate vergangen. Bei einer Sprintdauer von zwei Wochen kam schon einiges an Erfahrung zusammen. Wie geht es jetzt mit uns und wie sieht das gesamte Teamgefüge aus? Wer nicht weiterlesen möchte: super! Wer Details möchte, bitte sehr:

• Kommunikation. Punkte müssen abgestimmt werden. Wer macht was und wie und sowieso und überhaupt. War es zuvor still im Büro, mit aufgesetzten Kopfhörern, ist das jetzt nicht mehr der Fall. Es wird richtig kommuniziert. Dies wirkt sich natürlich äußerst positiv auf das Know-How des Teams aus. Wissen wird transferiert, jeder erschließt neue Bereiche und kann mit unterschiedlichen Sichtweisen seinen Input hinsichtlich Verbesserungen etc. bringen.
• Überblick Sprintinhalt. Jeder Entwickler hat einen sehr guten Überblick über die anstehenden Tasks. Es ist klar was innerhalb eines Sprints zu leisten ist.
• Zusammenhalt. Es hat sich der Zusammenhalt, das gesamte Teamgefüge massiv verbessert. Dadurch dass alle gemeinsam am selben Strang ziehen (müssen) und eben das Bewusstsein dafür besteht, ist es diesbezüglich zu einer klaren Verbesserung gekommen.
• Qualität. Kleinere Happen, die dafür richtig gut. Das zahlt sich aus. Bugs werden bei uns grundsätzlich als Blocker eingestuft und müssen sofort behandelt werden. Die Qualität steigt von Sprint zu Sprint. Das ist nicht nur für uns selbst positiv und motivierend, sondern wird auch von unseren Testern bzw. den Benutzern positiv bemerkt/aufgenommen.
• Transparenz. Es ist jedem zu jeder Zeit klar, wie der aktuelle Stand der Entwicklung ist. Was Anfangs einen sehr negativen Touch hatte wird nun absolut positiv aufgenommen. Es gibt keine Geheimnisse, Probleme liegen offen auf dem Tisch und werden gelöst. So einfach.
• Laufende Verbesserung. Jeder Sprint wird genau beleuchtet und hinterfragt. Aufgetretene Probleme oder Schwachstellen werden offen diskutiert, priorisiert und die Top-Punkte als Verbesserungsmaßnahmen für den darauffolgenden Sprint eingeplant. Jedes Teammitglied weiß nun, dass seine Meinung zählt und auf Verbesserungsvorschläge aktiv eingegangen wird. Die laufende Weiterentwicklung des gesamten Teams spricht für sich.
• Erfolgserlebnisse. Wer wochen- oder gar monatelang an einem Feature gearbeitet hat (und somit jede Menge Tiefs mitmachen musste) lebt nun vom täglichen Erfolgserlebnis wesentlich besser. Man geht nicht mehr mit einer elendslangen Liste an offenen Punkten nach Hause, sondern mit einem abgeschlossenen Punkt in der Tasche. Jeden Tag. Das motiviert.

Es war wirklich interessant zu beobachten, welcher Ruck durch das gesamte Team gegangen ist. Von der anfänglichen Angst oder Scheu vor bestimmten Neuerungen ist eine klare Akzeptanz und Befürwortung entstanden.

Wie geht es weiter

Andere Teams bei uns haben sich entschlossen, unseren Weg mitzugehen. Da wir in unserem Team Unterstützung aus der Business-Ebene haben (ja, das funktioniert richtig gut), lag es nahe, Scrum im gesamten Unternehmen einzuführen. Am Programm steht nun ein ausführlicher Workshop mit Ilker Cetinkaya in den wir große Erwartungen für weitere Verbesserungen setzen. Zusätzlich ergibt dies die Möglichkeit, unser aktuelles Tun zu reflektieren.

Fazit

Es geht mir nicht darum, dem werten Leser Scrum ans Herzen zu legen. Vielmehr wollte ich aufzeigen, welche positiven Erscheinungen zu Tage treten und was ein konsequentes Durchziehen einer Methode in einem Team tatsächlich bewirken kann. Für welchen Weg auch immer man sich entscheidet, es muss jeder mitspielen damit dieser erfolgreich sein kann. Zwang ist definitiv der falsche Weg. Da jedes Team unterschiedlich ist, mögen unterschiedliche Ansätze zum Ziel führen. Am Ziel sind wir noch lange nicht, der angefangene Weg entpuppt sich jedoch schon nach relativ kurzer Zeit als absolut positiv für unsere Entwicklung.