Scrum kam irgendwie automatisch auf uns zu. Es gab mehrere Gründe, Scrum einzusetzen, und seine Implementierung bedeutet immer ein schrittweises Vorgehen.

Der Bedarf: Erstens haben wir in den meisten unserer Projekte nur Anforderungen auf hohem Niveau als Input von unseren Kunden. Wenn wir unsere Projekte in Übereinstimmung mit einem Wasserfall-ähnlichen Ansatz durchführen, mussten wir Kunden immer davon überzeugen, mit den Phasen der Anforderungsspezifikation und des Architekturdesigns zu beginnen. Zweifellos ist es sicher gut und hilfreich, die Anforderungen so früh wie möglich zu sammeln. Aber ist es in den meisten Fällen effizient? Ganz und gar nicht. Ganz einfach, weil es bei der Erfassung von Softwareanforderungen aus allen möglichen Perspektiven enorme Anstrengungen erfordert, alle Zielnutzer und Interessenvertreter zu befragen. Selbst wenn Sie mit vielen Diagrammen und langen Listen von Anwendungsfällen eine hunderte von Seiten umfassende Dokumentation erstellen können, müssen Sie diese in der Zukunft wahrscheinlich revidieren und dramatisch ändern, wenn Sie schließlich mit der Implementierung fortfahren. In Anbetracht von Zeit und Geld ist niemand geneigt, mehr auszugeben. Die Leute versuchen normalerweise, das System nur gemäß den Anforderungen zu implementieren, die während der vorherigen Phase des Projekts gesammelt wurden.

Das Feedback: Natürlich haben Sie während der Implementierungsphase von „Classic Waterfall“ auch Meilensteine ​​und Zwischenlieferungen. Unsere Erfahrung zeigt jedoch immer wieder, dass die Kunden in den meisten Fällen zufrieden sind mit den Fortschrittsberichten, da sie der Meinung sind, dass alles gut läuft, wenn die Spezifikation der Softwareanforderungen im Voraus sorgfältig abgeschlossen wurde. Als Ergebnis wird die Produktprüfung auf einen anderen Tag, der dem Projektende näher rückt, verschoben. Änderungsanträge in letzter Minute werden oft an den Tisch gebracht, wenn sie nicht genügend Zeit und Geld für ihre Implementierung haben. All dies geschieht nicht aufgrund fehlender Fähigkeiten, Arbeitskraft oder Loyalität. Ganz und gar nicht. Jeder versuchte, sein Bestes zu geben, um moderne und leistungsfähige Software zu bauen, aber die Dinge passten einfach nicht in den Zeitrahmen aufgrund der verwendeten monolithischen Entwicklungsmethode wie „Waterfall“.

Heute akzeptieren wir Agile, und insbesondere Scrum, mehr und mehr. Wenn wir jedoch auf die Vergangenheit zurückblicken, als wir angefangen haben, mit Scrum zu arbeiten, hatten wir keine Ahnung, wie wir am besten vorgehen könnten. Externe Scrum-Berater auf lange Sicht zu haben, ist sehr teuer und in vielen Fällen nicht sehr effizient. Das Team sollte diesen Weg selbst gehen und Best Practices in die tägliche Arbeit umsetzen. Schließlich haben wir uns entschieden, bei Bedarf von Zeit zu Zeit externe Hilfe in Anspruch zu nehmen, um dann ausgewählte Praktiken in die Projekte einzubringen. Dabei unterstützen wir diverse Entwickler permanent mit professionellen externen Fortbildungen, so daß diese wiederum regelmäßig interne Schulungen zu verschiedenen Aspekten von Scrum mit praktischen Übungen und Szenarien bezüglich unserer realen Projekte vorbereiten und durchführen. Sie agieren auch als professionelle Scrum-Master, die alle Projektteilnehmer sowohl auf unserer als auch auf Kundenseite coachen, die Prinzipien dieser Entwicklungsmethode in vollem Umfang zu nutzen.

Erfahrung ist immer eine persönliche Sache, aber wir glauben fest daran, dass Lernen von anderen etwas sehr effizientes und natürliches ist. Daher würden wir uns freuen, unsere Scrum-Erfahrung, die wir bei GRSE gewonnen haben, zu teilen. Sie wird in mehreren Beiträgen veröffentlicht, beginnend mit so wichtigen Themen wie der Gestaltung eines Projektplans und der Einschätzung des Aufwands. Wir hoffen, dass es Ihnen Spaß machen wird Sie einen Nutzen in Ihrer Organisation haben werden, wenn Sie diese Prinzipien anwenden.