Agile
Softwareentwicklung mit Scrum
Erfahrungsbericht aus dem Umstellungsprozess
Der nachfolgende Kommentar des
Autors soll hauptsächlich Unternehmen oder Teams ansprechen, die
Scrum anwenden möchten und sich noch in der Anfangsphase befinden.
Die Scrum-Prinzipien und Begriffe sind aber bereits bekannt.
Es gibt sehr viele Artikel über Scrum,
wie es im Idealfall eingesetzt werden sollte, wie es entstanden ist
und was es überhaupt bedeutet, Scrum anzuwenden. Doch viele Berichte
sind theoretisch und haben mit der Realität nur wenig zu tun.
Die größte Schwierigkeit, vor der
Unternehmen stehen, sobald sie sich für den Einsatz von Scrum
entscheiden, ist die Abbildung fest
eingefahrener Strukturen auf Scrum. Das ist in den geringsten Fällen
eins-zu-eins möglich, es müssen viele Anpassungen vorgenommen
werden. Das sind wohlgemerkt Anpassungen auf Unternehmensseite und
nicht der Scrum-Regeln.
Wie in vielen Artikeln oft beschrieben
wird, ist die Einhaltung fester Regeln, die von Scrum vorgeschrieben
werden, sehr wichtig für den Erfolg von Scrum. Trotz agiler
Vorgehensweisen müssen diese festen Bestandteile existieren, sonst
fehlen sehr wichtige Kriterien zum Messen des Erfolgs oder Verbessern
der Abläufe.
Vor drei Monaten hat mein Arbeitgeber
entschieden, die Softwareentwicklung nach agilen Prinzipien
durchführen zu lassen. Das Unternehmen besteht an dem Standort, an
dem ich arbeite, aus knapp zehn Teams mit jeweils sechs bis acht
Entwicklern und ist daher bestens für Scrum geeignet. Für die
Einhaltung der Regeln, die maßgeblich sind für eine erfolgreiche
Anwendung von Scrum, ist der Scrum Master zuständig. Diese Position
habe ich übernommen und möchte über meine bisher gesammelten
Erfahrungen in der Umstellungsphase berichten.
Den Einstieg, bevor ich entschieden
habe, die Rolle des Scrum Masters zu übernehmen, hat die
Unternehmensführung in Amerika veranlasst. Aus den USA kam eine
Kollegin und hat uns in einem zweitägigen Workshop unterrichtet,
Scrum zu verstehen und anzuwenden. Doch zwei Tage reichen längst
nicht aus, um die Komplexität zu verstehen und den Aufwand
abzuschätzen was es bedeutet, ein großes Unternehmen mit
festgefahrenen Strukturen auf eine agile Entwicklung umzustellen.
Die Frage, wer denn Lust hätte, in die
Rolle des Scrum Master zu schlüpfen, kam gerade recht und entspricht
meinem langfristigen Ziel, mich beruflich auf andere, aber ähnliche
Pfade in der Softwareentwicklung zu bewegen. Mein Fachwissen über
die Entwicklung und Kenntnisse über das Unternehmen waren sehr von
Vorteil, jedoch musste sehr viel gelernt werden.
Wie ich später feststellen musste, ist
die Rolle des Scrum Master nicht irgendeine Aufgabe, die man
übernimmt. Es ist eine Einstellung, eine Philosophie, wenn nicht
sogar eine Bestimmung. Man muss dafür geschaffen sein, diese Rolle
korrekt anzuwenden. Nicht nur die Aufgaben müssen korrekt erledigt
werden, in die man mit der Zeit rein wächst, auch die innere
Einstellung und Überzeugung spielt eine große Rolle. Aber dazu
später mehr.
Es begann eine dreimonatige Lernphase
in Eigenregie. Auf der Suche nach Antworten, die aber mehr Fragen
aufwarfen als alles andere, wurden zur Vorbereitung Bücher
durchgelesen, dutzende Online-Schulungen abgeschlossen und etliche
Erfahrungsberichte aus einschlägigen Internetforen durchstöbert.
Das Meinungsbild, wie Scrum korrekt angewendet werden sollte, ging
dabei sehr stark auseinander. Es existiert zwar ein Dokument, aus dem
die ursprüngliche Idee von Scrum hervorgeht, doch über die Jahre
wurden viele Anpassungen an dem System vorgenommen. Diese Anpassungen
sind jedoch auf konkrete Unternehmen bezogen und daher nicht
miteinander vergleichbar. Es musste daher ein Gefühl dafür
entwickelt werden, welche Methoden am besten beim eigenen Unternehmen
angewendet werden können.
Um das zu realisieren, musste
herausgefunden werden, welche Idee Scrum verfolgt und was der
Grundgedanke dahin ist. Es wurde daher nur noch die erste und
einfachste Version von Scrum analysiert und als Grundlage für alle
weiteren Schritte bezogen.
Die Herausforderung an dieser
Entscheidung war, Scrum in kleinen Schritten einzuführen und das
Team nicht mit zu vielen Informationen zu belasten. Das Tool, was zur
Verwaltung der User Stories und Defects, sowie zur Auswertung
verschiedener Metriken eingesetzt werden sollte, erweiterte Scrum an
vielen Stellen, ohne es grundlegend zu verändern. Die Anpassungen
erschwerten jedoch den Einstieg in die agile Welt, da viele
Funktionen und Arbeitsweisen, die das Programm vorgibt, abgestimmt
werden mussten.
Im Idealfall wird Scrum zu Beginn in
seiner Rohfassung angewendet. Das trägt sehr dazu bei, Grundlagen
und agile Muster zu verinnerlichen und später effizient anzuwenden.
Je weniger Scrum anfangs bietet (nämlich nur die Grundregeln, den
Rahmen), desto agiler und effizienter kann in der Anfangsphase
gearbeitet werden. Erst wenn der Einstieg gelungen und vollstes
Scrum-Verständnis da sind, kann Scrum an das Unternehmen dezent
angepasst werden. Dabei dürfen jedoch nicht zu viele Anpassungen
gemacht werden, da dadurch vieles verloren geht.
Die größte Aufgabe besteht darin, das
Unternehmen an Scrum anzupassen. Strukturen und Arbeitsweisen müssen
aufgebrochen und verändert werden. Vieles, was über Jahrzehnte zur
Gewohnheit wurde, muss nun anders gemacht werden. Welche Schritte das
genau beinhaltet, muss natürlich im Vorfeld geklärt werden, um
Überraschungen vorzubeugen.
Nach den besagten drei Monaten
Vorbereitungszeit ging es ans Eingemachte und der erste Sprint wurde
geplant. Über die Timeboxes habe ich dem Team mehrere Vorschläge
unterbreitet, unter anderem auch eine Sprintlänge von nur einer
Woche. Die aufgezählten Argumente reichten aus, um das Team von den
kurzen Sprints zu überzeugen. Die Zeit wird es zeigen, wie sinnvoll
die Entscheidung war. Ich bin davon überzeugt, dass es genau richtig
ist, kurze Sprint durchzuführen.
Alle anderen Zeiten wurden entsprechend
loser Vorgaben festgehalten. Sprintstart am Mittwoch, Ende ist am
Dienstag. Der Sprint fängt mit dem Planning an und hört mit dem
Review/Retrospective auf, also ganz klassisch. Mittags steht täglich
das Daily Scrum an.
Spannender waren die
Abstimmungsaktivitäten, bei denen meine neu besetzte Rolle als Scrum
Master voll zur Geltung kam. Jede Situation, jede Äußerung, jedes
Argument und jede Auseinandersetzung musste beobachtet, bewertet und
koordiniert werden. Dazu kam eine straffe Einhaltung der Agenda
innerhalb der veranschlagten Zeit. Vor allem der Faktor Zeit konnte
anfangs nicht immer eingehalten werden.
Es ist schwierig, alle anstehenden
Aufgaben von einem System in ein anderes zu transferieren. Das
Herunterbrechen aller Anforderungen und Fehler in kleine
Teilaufgaben, so dass diese auch innerhalb eines Sprints erledigt
werden können, erwies sich als die aufwändigste Aufgabe. Doch auch
andere Dinge kamen im Laufe der verschiedenen Besprechungen ans
Licht, beispielsweise das Fehlerhandling, falls ein kritisches
Problem während eines Sprints auftreten sollte.
In diesem Fall, falls der Defect sofort
angegangen werden muss, wäre der Sprint gefährdet, da der zuvor
geschätzte Aufwand steigt und ungeplante Tasks den Zeitrahmen
sprengen. Zudem würde das auch keine Story Points einbringen, da das
Item noch nicht im Backlog aufgenommen wurde.
In diesen Fällen ist es wichtig, nicht
das System an die eigene Arbeit anzupassen, damit am Ende immer alles
grün ist. Solche unvorhergesehen Ereignisse können immer auftreten,
doch nur die Erfahrung zeigt, wie am besten darauf reagiert werden
kann. Scrum lebt davon, Gefühle, Emotionen und Intuition zuzulassen.
Solche Situationen müssen durchlebt werden, es müssen Fehler
gemacht werden. Es ist unmöglich, jedes Ereignis im Voraus
vorherzusehen oder zu planen. Es müssen zwar Standard-Situationen
abgefangen werden, doch sobald es ins Details geht, spielt auch das
Bauchgefühl eine große Rolle.
Ein wichtiger Tipp für startende Scrum
Teams ist es daher, den Sprint zu starten, ohne diesen wochenlang zu
planen. Es ist lediglich darauf zu achten, dass das Product Backlog
soweit gefüllt ist und dass jeder Mitarbeiter im ersten Sprint etwas
zu tun hat. Dann kann fleißig gesprintet und Erfahrung gesammelt
werden, die vor allem dann in der Retrospective genauer analysiert
wird.
Wichtig ist jedoch, dass der Scrum
Master weiß, wann was zu tun ist und was Scrum entspricht. Auch er
muss, falls dies die ersten Berührungen mit Scrum sind, vieles
Lernen und anfangs Erfahrung sammeln. Doch er muss dem Team stets das
Gefühl und das Vertrauen geben, alles perfekt zu verstehen und
anzuwenden. Der Scrum Master gibt dem Team Halt und Sicherheit und
unterstützt dieses in jeder erdenklichen Situation. Das Team steht
für den Scrum Master an erster Stelle, denn ohne Team gibt es keinen
Scrum Master.
Diese Sicherheit, die der Scrum Master
ausstrahlt, bewegt das Team zu einer hohen Leistungsfähigkeit. Der
Scrum Master ist überzeugt von der eigenen Meinung und vom Vorgehen
der Gruppe und wiegt das Team stets in Sicherheit. Alles, was diese
Sicherheit gefährden könnte, muss vom Team ferngehalten werden. Nur
so ist sichergestellt, dass das Produkt nach Scrum erfolgreich
entwickelt werden kann.
An erster Stelle kommt immer das Team.
Das Team muss aus Sicht des Scrum Masters vor allen negativen
Einflüssen geschützt und bei der Durchführung ihrer Arbeit
unterstützt werden. Vor allem am Anfang ist das schwer, wenn alte
Muster wieder angewendet werden. Diese Einflüsse kommen zu einem
großen Teil aus anderen Abteilungen oder von Vorgesetzten.
Eine meist nicht bedachte Schwierigkeit
ist es oft, das Team vor zu viel Arbeit zu bewahren. Erst recht bei
kurzen Sprints, wie es bei uns der Fall ist, dürfen nicht zu viele
User Stories angenommen werden, um einer möglichen Überlastung
vorzubeugen. Das Team besteht meist aus hoch motivierten Individuen.
Diese wollen ihre zur Verfügung stehende Zeit, die in der Theorie
errechnet wurde, zu möglichst einhundert Prozent ausgefüllt haben.
Doch wie es die Erfahrung zeigt, verschätzt man sich eher, als dass
ein Plan aufgeht. Die Schätzwerte liegen in fast allen Fällen unter
den real erreichten Werten.
Oftmals ist viel Überzeugungsarbeit
notwendig. Ein einfacher Weg ist es aber, dem Team Hinweise und Tipps
mitzugeben, aber ihre eigene Erfahrung machen zu lassen. Bei zu viel
Arbeit werden die Beteiligten schnell feststellen, dass die
aufgehalsten Aufgaben im Sprint doch nicht alle geschafft werden
können. Diese gewonnene Erfahrung wird dann später in der
Retrospektive genutzt, um herauszufinden, woran das gelegen hat,
warum die Stories nicht erledigt werden konnten. Nur durch
Fehlschläge kann das Team lernen und einen Nutzen aus der Situation
ziehen.
Als neuer Scrum Master habe ich lange
über diese Rolle nachgedacht und weiß, dass es nur richtige oder
falsche Personen in diesem Bereich gibt. Entweder ist man dafür
geeignet oder nicht. Diese Rolle muss man leben, auch wenn es streng
genommen 'nur ein Job' ist. Für mich ist es nicht mehr nur ein Job.
Es lässt die Persönlichkeit wachsen und Lebenseinstellung zum
Positiven hin verändern. Scrum ist etwas, das auf viele Bereiche des
Lebens angewendet werden kann. Dinge werden strukturierter
angegangen, Probleme sachlicher geklärt.
Trotz des strukturierten Vorgehens
fanden etliche Abstimmungsaktivitäten statt, viele Fragen mussten
mit Amerika geklärt werden, es wurden Unterlagen noch und nöcher
durchgekaut und es musste viel Überzeugungsarbeit geleistet werden.
Auf einzelne Aspekte gehe ich zu einem späteren Zeitpunkt nochmal
ein, doch die wichtigsten Punkte sind bereits erwähnt:
Scrum ist ein bisschen Framework, Scrum
ist ein bisschen Werkzeug, und Scrum ist voll und ganz Überzeugung
und Gefühl.
Über den Autor:
Stephan Klimmeck, geboren in
Hamburg, ist studierter Informatiker und seit 2009 in der
Softwareentwicklung tätig. Sein vierjähriges Studium brachte ihn
zunächst in ein mittelständisches Unternehmen für
Sicherheitstechnik, später wurde er von einer weltweit agierenden
Firma für Personalabrechnung aufgenommen, bei der er als Scrum
Master geholfen hat, Scrum erfolgreich im Unternehmen einzuführen.
Keine Kommentare:
Kommentar veröffentlichen