Starting Scrum

In den heutigen Zeiten der Softwareentwicklung wird oftmals zu agilen Projektmanagementmethoden gegriffen. Nicht selten, ich möchte gar sagen häufig, ist SCRUM das Mittel der Wahl. Startet man nun ein frisches Projekt samt frischem Projekt Team, so kann das schnell zur Frustration führen. Anfangs ist es nicht leicht in einem unbekannten Team und Projekt die Schnelligkeit der Entwickler, beziehungsweise des gesamten Teams, einzuschätzen und die Komplexität der Funktionen mit dem auserwählten Framework zu beurteilen.

Aller Anfang ist schwer

Startet man nun mit einem solch neuartigem Konstrukt, so sollte man es sich möglichst früh zur Aufgabe machen eben diese beiden Parameter in Erfahrung zu bringen. Das funktioniert allerdings nicht, in dem man versucht von anderen Teams oder Projekten auf die eigenen zu schließen. Zwei bis drei Sprints müssen getestet und darauf geachtet werden, wie viele vom Team eingeschätzten Story Points in den gegebenen Sprints erreicht werden können. Die Aufgabe des Projektmanagements und des Product Owners ist hier ganz klar das Team nicht für Fehleinschätzungen verantwortlich zu machen, sondern diese in den ersten Sprints - vor allem im allerersten Sprint - zu akzeptieren. Oftmals haben wir auch gute Erfahrungen damit gemacht, die allererste Iteration statt mit SCRUM, mit einem Kanban System zu erarbeiten.

Das Team ist entscheidend

SCRUM ist auf Teams ausgelegt , die Vollzeit oder zumindest hauptsächlich an einem Projekt arbeiten. Es funktioniert selten mit einem Team mehrere Sprints gleichzeitig zu bestreiten. Am Anfang verschiedener Projekte haben wir es häufig erlebt, dass die Projekt-Rollen nicht klar genug definiert wurden. Man sollte zu Beginn jedes Projektes klar festlegen wer Product Owner, SCRUM Master und Entwickler ist. Außerdem ist es unabdingbar einen erfahrenen Project Manager im Boot zu haben, der dem Team zur Seite steht und nicht zu schnell die Nerven verliert wenn mal die ein oder andere Sache nicht nach Lehrbuch läuft.

Was wir außerdem loswerden möchten: Zu kleine Teams, also Teams mit ein bis zwei Leuten, sollten besser nicht auf SCRUM zurückgreifen. Hiermit sind allerdings nicht Entwickler, sondern "normale" Vollzeitkräfte gemeint.

‍

Wie sind eure Erfahrungen mit SCRUM? Sprecht uns gern an wenn ihr Unterstützung bei der Realisierung eures digitalen Projektes brauchst - Unser Alltag besteht daraus Projekte erfolgreich zu realisieren.