Sechs Punkte um erfolgreich zu scrummen

Scrum

SCRUM stellt eine Methode dar, die es ermöglicht Software agil und planbar zu entwickeln. SCRUM ist ein Leitfaden, ein Framework an dem ein Team sich orientieren kann um Fehler zu entdecken, höchstmögliche Transparenz zu schaffen und somit (nicht nur) die Zusammenarbeit innerhalb des Teams sondern auch nach aussen zum Kunden zu verbessern.

Wenn es doch nur so einfach wäre…

Beginnt man in einem Projekt oder in einer Firma mit SCRUM, ist vieles von Nöten. Im Folgenden möchte ich aufzeigen, was SCRUM von jeder Person aber auch vom Team verlangt. Was es leistet und was man vorrausetzen sollte, um erfolgreich Software entwickeln zu können:

Sechs Punkte um erfolgreich zu scrummen.

Offenheit:
Wenn man mit SCRUM beginnt ist naheliegend, dass diese Methode etwas Neues für die Entwickler ist. Nicht für alle vielleicht, aber für einige. „Schon mal was von SCRUM gehört?“ „Ja, vom Hörensagen.“ „Ja, mal gelesen“ oder „Mal gemacht, aber nicht so richtig“ ist eine Antwort, die man oft hört. Das ist absolut kein Problem. Ich behaupte sogar, dass dies von Vorteil ist: Man kann von Grund auf anfangen SCRUM unverfälscht zu lernen und anzuwenden. Aber man braucht einen Teil, der offen für Neues ist. SCRUM ist neu. SCRUM ist anders als das, was bisher da war. Wieso nicht einmal was Neues probieren? Auch wenn ich vorgreife: SCRUM arbeitet in festgelegten Zeiträumen, den Sprints. Man kann in Sprints Sachen ausprobieren und schauen, ob sie greifen und Verbesserung bringen. Sind sie gut? Behalten wir sie bei! Sind sie schlecht? Dann lassen wir sie fallen. Aber die Bereitschaft und die Offenheit etwas verändern zu wollen muss da sein.

Ein Beispiel: Die maximale Sprint-Dauer beträgt 4 Wochen. Das ist lange genug Zeit, um festzustellen ob eine Änderung sich etabliert oder ob sie eher Verschlechterung mit sich bringt. Nach 4 Wochen kann diese Änderung überarbeitet, also geschlossen oder weiter ausgebaut, werden. Dann hat man es probiert. Und dabei nichts an Transparenz verloren. Das Jahr hat 12 Monate. Bei 4-Wochen-Sprints hat man 12 Mal die Möglichkeit besser zu werden. Diese Chancen sollte man sich nicht entgehen lassen!

Fragen und Antworten / Transparenz:
Der SCRUM-Prozess klärt viele Fragen. Aber diese Fragen müssen gestellt werden dürfen. „Wo steht mein Produkt?“ ist eine der häufigsten, wenn nicht sogar die Kernfrage, die SCRUM versucht zu beantworten. Diese Frage kann, darf und sollte man immer stellen. Sie muss jederzeit erlaubt sein und beantwortet werden können. Die Frage wird jedoch oft mit Rechtfertigung assoziiert. Bekommt ein Entwickler diese Frage gestellt, wird daraus oft ein „Wie weit bist du mit deiner Userstory/mit deinem Backlog Item/ mit deinem Task?“ ersetzt. Das ist nicht richtig. Natürlich ist der Fortschritt der Arbeit wichtig und sollte immer offen kommuniziert werden können. Falls Probleme auftreten (und sie werden auftreten 😉 ) kann man diese lösen bzw. minimieren. Aber Probleme sind nicht immer komplett vorhersehbar und im Vorhinein überwindbar. Das weiss der Product Owner genauso wie der Kunde und der Entwickler erst recht. Wenn diese Frage also gestellt wird, ist diese sachlich gemeint. Und sie verlangt eine Antwort. SCRUM ist fähig, Probleme zu zeigen. Es löst sie aber nicht. Das ist dann wieder Teamarbeit.

Sprint Ziel:
Vor jeder Aktion, die im Sprint getätigt wird, muss die Frage beantwortet werden, ob das Sprintziel gefährdet wird. Macht ein Entwickler am SCRUM-Board beim Daily Scrum eine Aktion, die das Sprint-Ziel gefährdet, ist diese nicht zulässig. Hierbei geht es gar nicht darum den Entwickler anzuprangern. Das Team steht am Ende vor dem Kunden dafür gerade. Niemand kann im SCRUM Prozess einen Entwickler anprangern, weil er etwas nicht erreicht/geschafft hat. Der Sprint verfolgt ein Sprint-Ziel. Dies wird durch das Team erreicht oder nicht erreicht. Das Team steht am Ende dafür gerade und nicht ein einzelner Entwickler. Das Daily Scrum bietet eine ideale Plattform dafür zu überprüfen, ob man sich noch auf dem richtigen Weg befindet, das Sprint-Ziel zu erreichen.

Rollenverteilung:
Es ist schwer vom Projektleiter-Denken auf SCRUM zu wechseln. Oft wird die Frage gestellt „Wer ist denn der Chef?“. Die Antwort ist so trivial wie naheliegend: Es gibt keinen Chef. Das Team organisiert sich selbst. Der Sprint ist insofern für Aussenstehende eine Blackbox, als dass innerhalb eines Sprints nichts an der Arbeitsweise verändert wird, die das Team an den Tag legt. Das Daily Scrum beispielsweise geht es nicht los, wenn der SCRUM-Master das sagt, sondern dann, wann das Team dies (einmal) entscheidet. Der Projektmanager kann nicht während eines Sprints Arbeitsweisen ändern. Das Team organisiert seine Arbeitsweise, seine Abläufe und alles, was dazugehört, selbst. Pair-Programming, Meetings, Reviews und alles, was dazugehört steht dem Team frei. Das Team muss den Konsens haben, die Arbeit so zu machen, wie am Ende eines Sprints (das gleichzeitig der Anfang eines neuen ist) festgelegt.
Die Rolle des Scrum Masters und des Product Owners (PO) sollte klar verteilt sein. Gibt es mehrere PO, was nicht ungewöhnlich ist, sollte einer als „Sprachrohr“ definiert werden. Dieser steht für Rückfragen zur Verfügung. Natürlich kann er sich mit seinen Kollegen absprechen. Aber er hat eines seiner beiden Ohren beim Kunden, das andere beim Team bzw. dem SCRUM-Master, der bei der Kommunikation zwischen Team und PO eine wichtige Rolle einnimmt. Er schaut zum PO und auf das Team. Schaut, dass das Team ungestört arbeiten kann und schützt es vor, sagen wir es mal vorsichtig, „zu engagierten“ POs ;). Weitere Aufgaben des Scrum Masters und Aufgaben der Rollen sehen Sie hier.

Die richtigen Leute in den richtigen Meetings:
Meetings im SCRUM sind sehr wichtig. SCRUM wird von mehreren Meetings geprägt. Aber all dies bringt nichts, wenn diese Meetings nicht ernstgenommen werden oder sogar entscheidende Personen fehlen. Eine Sprint-Planung ohne Product Owner ist genauso sinnlos, wie ein Review ohne die wirklichen Stakeholder und/oder Kunden, die das Projekt benutzen und eventuell auch sogar direkt bezahlen. In diesen Meetings wird nicht nur überprüft, was getan wurde, sondern es ist auch Richtungsweisend für den weiteren Verlauf des Produkts. Viele „Wenn-wir-das-schon-machen-können-wir-auch-gleich“-Diskussionen sind Grundlage für neue Backlog-Items. Diese bedeuten weitere Arbeit für das Team oder die Firma. Dies bedeutet aber auch, dass Kunden langfristig gebunden werden. Daher sind Meetings sehr wichtig. Die Meetings mit Kundenkontakt sind wichtig für den Kunden und die Firma. Es nimmt also Einfluss auf die externen Komponenten. Meetings wie die Retrospektive beispielsweise sind wichtig für die Verbesserung der (Zusammen)Arbeit im Team. Aber all dies geschieht nur, wenn die richtigen Leute involviert sind. Schlüsselkomponenten wie Timeboxing, Protokolle und eine subtile Moderation sind sicherlich ausschlaggebend für ein erfolgreiches Meeting.
Siehe auch „Gestalten sie unterhaltsame Meetings“

Teamwork:
Ein Sprint steht und fällt mit seinem Team. Es ist das Team, welches zu Beginn des Sprints die Aufgaben bekommt und es ist das Team, welches am Ende im Review dafür gerade steht. Für Aussenstehende ist der Sprint, wie schon geschrieben, mehr oder weniger eine Blackbox. Man gibt Aufgaben herein und am Ende kommt ein auslieferungsfähiges Produkt heraus. Die ganze Organisation, das Aufteilen der Arbeiten, das „Wie“, wird in die Hände des Teams gelegt. Ich behaupte sogar, dort ist es besser aufgehoben! Ein Team redet untereinander eventuell ganz anders als bei und mit Vorgesetzten. Das Einschätzen der Stärken und Schwächen, vielleicht auch der persönlichen Interessen, geht untereinander viel viel einfacher und schneller, als das über einen Vorgesetzten zu definieren bzw. definieren zu lassen.
Gemeinsame Code-Reviews, die Entwickler im Paar durchführen können, Diskussionen und, nicht zuletzt, das abschliessende Review als SCRUM-Artefakt stärken nicht nur das Team-Gefühl, sondern verteilt auch das Know-How im Team. Und das kann nur im Interesse von Entwicklern, Product Ownern und Kunden sein.

SCRUM kann viel bewirken. Es muss nur richtig gemacht werden. Die Kunst ist, nicht SCRUM anzupassen, um seine hausgemachten Pain-Points auszulassen. SCRUM kann die Arbeitsweisen von Entwicklern und allen beteiligten Parteien verändern. Mit den oben genannten Punkten gibt man SCRUM eine Chance und schafft perfekte Voraussetzungen mit SCRUM erfolgreich zu sein.

The following two tabs change content below.
Fabian Gosebrink

Fabian Gosebrink

Softwareentwicklungsingenieur bei Noser Engineering AG
Fabian Gosebrink ist professioneller Software-Ingenieur bei der Noser Engineering AG in Winterthur. Er studierte Kommunikations – und Softwaretechnik (Bachelor) und Systems Engineering (Master) und beschäftigt sich seit dem Studium mit den Themen ASP.NET MVC, WPF, MVVM, Javascript, SQL etc. Er widmet sich besonders agilen Entwicklungsmethoden wie SCRUM und ist ehrenamtlich als Moderator auf myCSharp.de tätig. Weitere Profile sind Xing | Noser-Blog | DeveloperCircle
Fabian Gosebrink

Neueste Artikel von Fabian Gosebrink (alle ansehen)

Kommentar hinzufügen