Vor Jahren hatte ich eine Zusammenfassung der klassischen Scrum-Artefakte und Tätigkeiten erstellt. Dies war im Jahre 2008, als Scrum noch in den Anfangszeiten war. Agile Methoden waren stark auf dem Vormarsch und damals hatte ich mich entschieden auf dieses neue „Scrum-Pferd“ zu setzen. Seither habe ich viele Projekte als Scrum-Master geleitet und mit wechselnden Teams umgesetzt.
Nicht immer konnte ich klassisches Scrum anwenden. Dies lag vor allem daran, dass ich als IT-Berater meist keine klassische Produktentwicklung betreue sondern vielmehr Projekte zur Implementierung von Speziallösungen im Auftrag von Kunden umsetze. Die Projektgrößen variierten von kleinen 2-3 Wochenprojekten bis hin zu Projekten, die mehrere Jahre liefen. In dieser Zeit habe ich die unterschiedlichsten Erfahrungen gemacht und immer wieder festgestellt, wo Scrum seine Grenzen hat. Diese Grenzen liegen meist nicht im Vorgehen oder in der Agilen Methodik sondern an den Menschen, die in diesem Prozess arbeiten – oder arbeiten sollen. Oft sind es die Rahmenparameter oder einzelne Beteiligte, die den Scrum-Ansatz erschweren oder sogar zum Scheitern bringen. Es kommt auf die Bereitschaft und Möglichkeit an eigenverantwortlich im Team zu arbeiten. Auf die Bereitschaft sich einzubringen, Veränderungen und Kritik zuzulassen, um daran zu wachsen. Und dies ist trotz der geforderten Innovationskraft und der Bereitschaft von Unternehmen agile Entwicklung zu betreiben immer noch ein entscheidender Faktor.
Als IT-Dienstleister haben wir unser Entwicklungsteam nach Scrum organisiert, da unserer Erfahrung nach diese Methode für uns gut zu steuern ist und früh für Transparenz im Projektgeschehen sorgt. Während früher Projekte oft zum Schluss sehr hektisch wurden, da vieles noch nicht fertig war oder man erst sehr spät erkannte, dass z.B. die Installation der fertigen Lösung aufwendiger und Fehleranfällig ist hilft uns Scrum heute die Arbeitslast im Projekt gleichmäßiger zu verteilen. Vor allem, weil wir im TFS und später im Visual Studio Team Services als ein zuverlässiges Tool zur Unterstützung des gesamten ALM-Prozesses und der Scrum Methodik im Einsatz haben. Insgesamt waren wir sehr frei bei der Gestaltung unserer internen Scrum-Vorgehensweise, sind aber in der Rolle des Product Owner stark abhängig vom Vorgehen und dem Know-How des Kunden. Aus diesem Grunde haben wir den klassischen Scrum Ansatz mal mit mehr und mal mit weniger Erfolg abwandeln müssen, um unsere Projekte erfolgreich umzusetzen.
Die folgenden Faktoren haben in der Vergangenheit bei mir oft zu Anpassungen im Scrum-Vorgehen geführt:
- es ist kein qualifizierter, oder zeitlich verfügbarer Product Owner auf Seiten des Kunden vorhanden
- Anforderungen werden als klassisches Pflichtenheft geliefert
- Teammitglieder sind in mehreren Projekten gleichzeitig tätig
- der Scrum-Master ist gleichzeitig der Architekt…
Heute kann ich sagen, dass Agile Entwicklung nicht für jeden Kunden und nicht für jede Situation in seinem vollen Umfang sinnvoll einzusetzen ist, aber die meisten Scrum Grundprinzipien mit hoher Disziplin in Ihrer Anwendung den Projekterfolg in hohem Maße unterstützen.
Vor kurzem habe ich diese Notizen wieder gefunden und mal geprüft, ob sie meinen langjährigen Erfahrungen noch entsprechen. Und tatsächlich, einiges ist noch vollkommen wahr und mittlerweile in Fleisch und Blut übergegangen, doch einiges hat sich im Laufe der Zeit verändert.
Ich habe mich nun entschieden diese Zusammenfassung Stück für Stück in einem Blog mit euch zu teilen und werde an den einzelnen Punkten noch die ein oder anderen Erfahrungen mit einfließen lassen.
Scrum (engl. das Gedränge) ist eine Sammlung von Arbeitstechniken, Strukturen, Rollen und Methoden für das Projektmanagement im Rahmen agiler Softwareentwicklung. Es ist ein Vorgehensmodell, das wenige Festlegungen trifft. Teams bzw. Entwickler organisieren sich weitgehend selbst und wählen auch die eingesetzten Methoden. Das Vorgehen und die Methoden werden fortlaufend aktuellen Erfordernissen angepasst.
Übersicht der Aktivitäten im Scrum
- Product Backlog erstellen
- Sprint Planungssitzung durchführen
- implementierung im Sprint
- treffen zum Daily Scrum
- Sprint Review durchführen
- Sprint Retrospektive durchführen
- Backlog Refinement durchführen
Im Scrum erstellte Dokumente / Listen
- Product Backlog
- Releaseplan
- Sprint Backlog
- Impediment Liste
- Sprint Burndown Bericht
- Sprint Endbericht
Die Rollen im Scrum
- Rollen
- Product Owner
- Scrum Master
- Team
- Stakeholder
