Mittwoch, 16. September 2015

Erfahrungsbericht eines Scrum Masters

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 posten