Hundert Sprints – Was hat Scrum gebracht?

Nicht falsch verstehen es gibt viele gute Gründe für agile Softwaremethoden; aber auch jede Menge schlechte Gründe. Mein Eindruck ist, dass Agilität in Projekten fest zur Projektliturgie gehört und nicht kritisch hinterfragt wird, ob diese benötigt wird oder nicht. Wie viel Agilität benötigt die Entwicklung einer Standardsoftware mit festen Release Zyklen und einem festgelegten Release Plan? Diese Frage beantworte ich mit der Erfahrung von 7 Jahren Scrum Prozess in unserem Entwicklungsteam Publishing Server.

Mit der Einführung der Scrum Methode, einer der weit verbreiteten agilen Entwicklungsmethoden, vor 7 Jahren lösten wir unsere Chef-Entwickler Methode ab. In der Chef-Entwickler Methode führt der erfahrenste Entwickler das Team fachlich und disziplinarisch. Neue Anforderungen wurden schnell und effizient umgesetzt. Warum führten wir Scrum dann überhaupt ein? Es lag nicht an der mangelnden Agilität des alten Prozesses, sondern dass wir personell nicht skalierbar waren. Denn es ging alles über den Tisch des „Chef-Entwicklers“. Das Team sollte mehr eigenständig und weiterhin agil arbeiten und neue Teammitglieder sollten sich an einer bekannten Methode orientieren können.

Der erste Anlauf die Scrum Methode in unserem Publishing Server Team einzuführen scheiterte. Wir versuchten die Vorteile des bisherigen Prozesses mit denen der Scrum Methode zu kombinieren. Frei nach dem Motto „Wasch mich aber mach mich nicht nass“. Diesen Fehler erkannten wir schnell und orientierten uns dann sehr eng an der Scrum Methode. Der zweite Anlauf verlief erfolgreich, jedoch gibt es Licht und Schatten.

Die Scrum Methode geht von verschiedenen Prämissen aus: Jeder Entwickler kann alles. Diese Prämisse der Scrum Methode, war und ist heute bei uns nicht gegeben. Nicht jedes Teammitglied kann beispielsweise eine Software-Architektur entwerfen oder ein User Interface mit den eingesetzten Frameworks implementieren. Daher macht es keinen Sinn, wie von Scrum vorgeschlagen, das Backlog ausschließlich nach Business Value zu sortieren. Verfügbare Ressourcen mit den richtigen Skills sind ebenfalls relevante Kriterien für die Reihenfolge der User Stories im Backlog.

Eine zweite – aus unserer Sicht nicht praxisnahe – Annahme ist, dass die eingesetzte Software-Architektur immun gegen Architekturänderungen ist. Anders formuliert, man kann alles ändern, ohne allzu große Seiteneffekt zu riskieren. Dass ist bei einer langjährigen Standardsoftware, in der manchmal 10 Jahre alter Code verbaut ist, nicht der Fall. Architekturänderungen sind ein weiteres Kriterium, welches die Reihenfolge im Backlog stark beeinflusst. Wir starten bei einem neuen Release mit User Stories, welche Architekturänderungen beinhalten.

Eine dritte ist, dass die Teamgröße die Effizienz des Teams beeinflusst. Die Empfehlung der Methode lautet maximal 9 Entwickler. Dummerweise liegt unsere Teamgröße etwas über diesen kritischen Schwellenwert. Wir versuchten es deshalb mit zwei Teams, die am selben Produkt arbeiteten. Die Scrum Methode betrachtet den Prozess eines einzelnen Teams und gibt keine Antworten auf die Zusammenarbeit von Teams. Nach vielem Hin und Her arbeiten wir wieder mit einem großen Team.

Viele der Annahmen der Scrum Methode erweisen sich in unserem Tagesgeschäft als nicht vollständig zutreffend. Die Methode wurde schon im Elfenbein Turm entworfen und wird in der Praxis eben geradegebogen.

Als Hersteller der Standardsoftware priint:suite folgen wir einem Releaseplan. Trotzdem sind wir in permanenten Austausch mit Kunden und Partnern. Auf kritische Bugs muss schnell reagiert werden. Großartige Ideen des Marktes sollen bei Bedarf auch schnell umgesetzt werden. Deshalb haben wir einen signifikanten Anteil von agilen Anforderungen, die am Anfang eines Releases nicht feststehen. Deshalb können wir nicht auf eine agile Methode verzichten.

Teamverantwortung halten wir für essenziell für einen langfristigen Erfolg. Entscheidungen, die im Team getroffen werden und von allen getragen werden sind nachhaltiger. Die Scrum Methode hilft uns, die Teamarbeit zu verstärken und unsere Arbeit durch Retroperspektiven permanent zu verbessern.

Nach 7 Jahren sind wir von Scrum nicht hellauf begeistert. Doch wir halten Scrum für uns derzeit als die beste Alternative, die wir aber regelmäßig hinterfragen.

So freue ich mich auf die nächsten 25 Sprints in der Zusammenarbeit mit unserem tollen Publishing Server Team.