Digitale Kultur

New Project means New Scrum!

In den ersten Projekten nach meinem Studium musste ich schnell feststellen : „Die Theorie im Studium ist das eine aber die Umsetzung in realen Projekten etwas ganz anderes“. Für jeden mit einem IT-lastigen Studium ist Scrum ein Begriff und viele haben auch schon das ein oder andere Studienprojekt damit absolviert. Manche Dozenten achten darauf, dass die Theorie gleich der Umsetzung im Studienprojekt ist. Andere Dozenten arbeiten praxisorientierter und lassen den Studenten die nötige Flexibilität, um die Scrum-Artefakte nach eigenem Ermessen einzusetzen. Gut oder schlecht, jeder kann davon halten was er will. Auf meinen Dozenten traf in dem Fall Ersteres zu, womit ich ihm einige Projekte später ganz dankbar bin. Warum?

Meiner Meinung nach ist das wie im Kampfsport. Bevor man ein guter Wettkampfsportler wird, muss man erst einmal die Grundtechniken in Perfektion erlernen. Klar kann der ein oder andere auch mit Halbwissen den ein oder anderen Erfolg vorweisen, aber so richtig gut wird dieser nie sein.

SCRUM: Warum überhaupt?

Hierbei kam bei mir die Frage auf, wieso Unternehmen Scrum einsetzen, wenn sie es nicht richtig machen? Die Antwort darauf ist ziemlich simpel. Unternehmen wollen die Vorteile von Scrum ausschöpfen. Dazu gehört beispielsweise schnell auf Veränderungen reagieren zu können, Aufbruchsstimmung zu erzeugen, die Führung zu entlasten, die Kundenzufriedenheit zu steigern und Transparenz zu schaffen. Am Ende läuft alles darauf hinaus Vorsprung zu erzeugen!

Erster Tag in einem neuen Projekt

Vorsprung wollte auch das Unternehmen erzeugen, bei dem ich eines meiner ersten Projekte hatte. Weg vom Wasserfallmodell hin zu Scrum. Hierbei lautete meine Aufgabe, den Product Owner zu unterstützen. Dieser bewältigte mehrere Projekte gleichzeitig und hatte dadurch nicht viel Zeit. Nach der ersten Begrüßung ging es auch schon ins Review. Hierbei fiel mir als erstes auf, dass der Auftraggeber und der Scrum Master nicht anwesend waren. Auf Nachfrage hieß es, dass der Auftraggeber nur ab und zu vertreten sei, aufgrund von Zeitmangel und es einen Scrum Master erst gar nicht gebe. Einige Wochen später tauchte der Auftraggeber zu einem Meeting auf und war leicht verärgert, da seine gewünschten Features nicht so umgesetzt waren, wie er es vor Wochen mitgeteilt hatte. An dieser Stelle muss sich der Auftraggeber bewusst sein, dass der PO wie ein Goldfisch in einem Glas ist. Kippt der Auftraggeber nicht in bestimmten Abständen Wasser nach, liegt dieser früher oder später auf dem Trockenen. Der zweite Punkt, welcher mir auffiel war, dass das Review nur mündlich und via PowerPoint-Präsentation abgehalten wurde, jedoch die Anwendung an sich gar nicht gezeigt wurde.

Nach dem Review ging es weiter in die Retrospektive. Hier war ich positiv überrascht, da trotz vielen Unstimmigkeiten eine sehr offene Kommunikation herrschte. Das Feedback fiel allerdings, wie zu erwarten, nicht sehr positiv aus. Schliesslich kam man zu dem Entschluss, dass der Versuch einen Scrum Master einzusetzen nicht ganz verkehrt wäre. Dieser fing drei Wochen später in unserem Projekt an und setzte knallhart seine agile Arbeitsweise sowie Timeboxing in den Meetings durch. Damit stieg die Motivation des Teams von Meeting zu Meeting, da diese deutlich gewinnbringender genutzt wurden. Schlussendlich war der einzige größere Kritikpunkt die fehlende Zeit des Product Owners, da offene Fragen erst verspätet geklärt werden konnten.

Am Ende des Tages hatte ich ein gemeinsames Meeting mit dem PO. Dieser teilte mir mit, dass ich einen Großteil seiner Aufgaben hinsichtlich des Halten von Meetings, der Durchführung von Workshops und der Backlogpflege übernehmen sollte. Der Grund hierfür war, dass er selbst in anderen Meetings sei. Als Unterstützung bot er an, dass wir uns 1-2 Mal die Woche abstimmen könnten, wenn ich Fragen zu der Anwendung hätte. Die ersten Wochen verliefen sehr durchwachsen. Nicht nur ich hing wegen der mangelnden Zeit des POs in der Luft, sondern auch die Teammitglieder. Das führte zu einer generellen Unzufriedenheit. Diese legte sich jedoch von Woche zu Woche, da ich die Anwendung zunehmend besser kennenlernte und somit auch die Bedürfnisse der Entwickler besser bedienen konnte.

Scrum ! = Scrum

Generelle Punkte, welche in darauffolgenden Projekten verbesserungswürdig gewesen wären:

  • ein Product Owner nicht mehr als zwei Produkte gleichzeitig betreuen sollte
  • es keinen Scrum Master gibt und auch nicht die Notwendigkeit gesehen wird
  • der Auftraggeber teilweise oder gar nicht an Review-Terminen teilnimmt
  • ein Entwickler keine 100 % Entwicklungszeit hat, im Schnitt sollte man 10 % für Meetings einplanen
  • Stories ohne Druck von außen geschätzt werden sollten
  • es eine Definition of Done und Ready geben muss, an welche sich alle halten
  • die Definition of Done und Ready mit dem Auftraggeber abstimmt werden sollte
  • es teilweise nur ein Planning 1, aber kein Planning 2 oder Technical Refinement gab.

Aus Fehlern lernen

Mittlerweile blicke ich schmunzelnd zurück, wenn ein Projekt mal nicht so läuft wie es soll. Meiner Meinung nach lernt man aus Fehlern. Jeder predigt seinen Kindern: „Aus Fehlern lernst du. Wenn du keine Fehler machst, wie sollst du dann die Erfahrungen machen, was richtig oder falsch ist?“, aber selbst will man sich keine erlauben. Das ist irgendwie widersprüchlich, nicht wahr? Wichtig ist jedoch, dass die Kernpunkte wie das agile Manifest und die vorgesehenen Inhalte der Meetings eingehalten werden. Jeder macht Scrum, aber jeder macht es ein wenig anders!

Wenn sich ein Projekt Scrum auf die Fahne schreibt, schreibt es sich auch gleichzeitig Agilität mit darauf. Daher sollten auch die Artefakte von Scrum flexibel an das jeweilige Projekt angepasst werden können. Womit wir wieder bei der Kernaussage wären: erst die Prinzipien von Scrum verinnerlichen, dann anhand der gewonnenen Erfahrungen seinen eigenen Weg finden!