Warum sich nicht drängen?

SCRUM bei doubleSlashNein, nicht sich drängen lassen, sondern sich drängen. Gemeint ist damit SCRUM (englisch für Gedränge), was ein Vorgehensmodell der Softwaretechnik ist, das sich immer größerer Beliebtheit erfreut.


Der Ansatz von Scrum[ref]Beschreibung des Projektmanagement-Frameworks http://de.wikipedia.org/wiki/Scrum[/ref] ist empirischinkrementell und iterativ. Er beruht auf der Ansicht, dass die meisten modernen Entwicklungsprojekte zu komplex sind, um durchgängig planbar zu sein. Scrum versucht, die Komplexität durch drei Prinzipien zu reduzieren:

 

  1. Transparenz: Der Fortschritt und die Hindernisse eines Projektes werden täglich und für alle sichtbar festgehalten.
  2. Überprüfung: In regelmäßigen Abständen werden Produktfunktionalitäten geliefert und beurteilt.
  3. Anpassung: Die Anforderungen an das Produkt werden nicht ein und für alle Mal festgelegt, sondern nach jeder Lieferung neu bewertet und bei Bedarf angepasst.

Scrum bei doubleSlash

Wir sind in der Produktentwicklung unseres Unternehmens im Oktober dazu übergegangen, Scrum für die Entwicklung unserer Produkte einzusetzen.
Davor wurden die Produkte nach dem klassischen Wasserfallmodell geplant und umgesetzt. Es gab 4 Releases pro Jahr mit einem Entwicklungszyklus von 3 Monaten. Dem ging eine Priorisierungs- und Konzeptionsphase voraus. Gegen Ende eines Releases stand dann noch das Gateway mit Tests und Abnahmen. Das Team war somit für lange Zeit gebunden und Unterbrechungen führten zu einem starken Effizienzverlust. Den gleichen Effekt hatten Änderungen in einem Release durch Change Requests oder Änderungen der Teamzusammensetzung. Ebenso gab es Missverständnisse in Meetings oder unterschiedliche Auffassungen bezüglich der Konzepte, die erst spät erkannt wurden. Alles hatte zur Folge, dass die Entwicklung sehr schwerfällig von statten ging und die Stakeholder immer erst am Ende eines Releases das Ergebnis zu sehen bekamen.

Mehr Flexibilität

Die Umstellung auf Scrum brachte dann für alle Beteiligten die erhoffte Besserung. Diese wurde durch mehr Agilität herbeigeführt. Das Team wurde flexibler und reaktionsfähiger.
Flexibel, da es nicht langfristig gebunden ist. In Scrum gibt es innerhalb eines Release sogenannte Sprints. Das sind kurze Entwicklungszyklen von 2 bis 3 Wochen. Nach Ablauf eines Sprints wird eine Retrospektive abgehalten, bei der das Team prüft, wo es sich verbessern kann. Es findet ein Review (Überprüfung) statt, bei dem das Team die geleistete Arbeit den Stakeholdern in Form von lauffähiger Software vorstellt. Danach werden die Inhalte des kommenden Sprints definiert. Die Stakeholder bekommen somit immer zeitnah einen Einblick in den Stand der Entwicklung und wurde etwas anders umgesetzt als gedacht, kann die Änderung bereits in einen folgenden Sprint eingeplant werden.
Somit wurde das Team auch reaktionsfähiger (Anpassung). Änderungen, nicht nur von Änderungswünschen sondern auch von anderen Themen, können schneller eingeplant werden. Reaktionsfähig meint hier auch auskunftsfähig, da der Fortschritt schneller vorgezeigt werden kann.
Klingt gut? Ist es auch.

Erhöhte Effizienz und Transparenz

Durch die Umstellung wurde das Team wesentlich effizienter. Ermöglicht wird dies auch durch optimal vorbereitete Anforderungen, die durch den Product Owner an das Team gegeben werden. Die Anforderungen werden im Vorfeld bereits geprüft, Unklarheiten direkt abgestimmt und korrigiert.
Zudem finden tägliche Meetings vor dem Taskboard statt. Dieses „Gedränge“ nennt sich Daily (Transparenz). Im Daily, welches maximal 15 Minuten dauern sollte, erklärt jeder Entwickler den anderen Teammitgliedern kurz, was er am Vortag gemacht hat, womit er sich am aktuellen Tag beschäftigen wird und ob es Probleme gibt, die ihn an seiner Arbeit hindern. Sollte es solche geben, wird dies vom Scrum Master aufgenommen und er sorgt für Abhilfe. Das Team kann damit ungestört entwickeln und sich auf seine Aufgaben konzentrieren.
Die Umstellung auf Scrum war somit die richtige Entscheidung und hat sich zu aller Zufriedenheit bewährt. Dies zeigt auch ganz deutlich ein Satz eins Entwicklers in einer Retrospektive, den ich gerne abschließend zitieren möchte:

„Ich habe letztens festgestellt, dass sich Scrum positiv auf mein Seelenheil auswirkt.“

 

Zurück zur Übersicht

Ein Kommentar zur “Warum sich nicht drängen?

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*Pflichtfelder

*