Ursprünglich war Scrum für die mündliche Kommunikation in kleinen Teams mit bis zu sieben Entwicklern in einem Büro gedacht. Größere Projekte, in denen sich die Entwickler auf mehrere Teams verteilen, benötigen mehr formalisierte Kommunikation und Koordinationsmechanismen jenseits des rein verbalen Austauschs. Hier werden Werkzeuge benötigt, um die vereinbarten Anforderungen und technischen Entscheidungen nachvollziehen zu können. In der Praxis übernehmen oft Wikis diese Funktion. Scrum kümmert sich weiterhin nicht groß darum, wie Aufgaben der Fehlerbehebung und Wartung bei bestehenden Softwareanwendungen anzugehen sind. Oder darum, wie der Support und die Entwicklung neuer Funktionen kombiniert wird. Letztlich werden hier dann doch zusätzliche Planungsmechanismen benötigt.
Eine weitere Schwäche ist die Tatsache, dass die Architektur eines Softwaresystems vom Team innerhalb jedes einzelnen Sprint festgelegt oder nachgebessert wird. Dies ist bei komplexen oder großen Projekten risikoreich und ineffektiv. Für sicherheitskritische oder bestimmten Standards verpflichtete Produkte ist ein derartiges Herangehen oft nicht akzeptabel. Hier muss in der Startphase zumindest ein verbindliches Dokument zu Architektur und Design aufgesetzt werden. Auch die Zusammenarbeit von verteilten Teams oder mit einem externen Dienstleister ist nicht unproblematisch. Praxisbeispiele haben aber gezeigt, dass sie möglich ist. Konkrete Vorgehensweisen müssen sich aber jeweils erst entwickeln. So kann die Scrum Wall beispielsweise in Videokonferenzen diskutiert werden. Und auch die vertraglichen Regelungen mit einem externen Dienstleister müssen im Falle von Scrum sehr genau durchdacht werden, mit einem Schwerpunkt auf den Produkt- und Projektzielen.
Zusammenfassend gesagt: Konkrete Projekte können sich stark voneinander unterscheiden. Die Auswahl eines geeigneten Ansatzes sollte sich daher immer an diesem konkreten Fall, konkreten Prioritäten, technischer Komplexität, der Teamgröße und anderen kritischen Faktoren orientieren. Die Erfolge von Scrum sind aber kein Zufall. Für kleinere Projekte sollte man dieses Vorgehensmodell auf jeden Fall in Betracht ziehen.
Anton Dechko ist Direktor Business Development bei der SaM Solutions GmbH in Gilching bei München.