Scrum skalieren - Releases, Teams

Das agile Management-Rahmenwerk Scrum beschreibt die Zusammenarbeit eines Entwicklerteams mit begrenzter Anzahl an Mitgliedern und die Erstellung qualitativ hochwertiger Versionen (Inkremente) eines Produktes in vorgegebenen Zeitspannen von einer bis mehrerer Wochen mit in dieser Zeit realisierbaren Verbesserungen.

In der Praxis müssen häufig längerfristig geplante Releases eines Produktes zur Abstimmung mit der Projektumwelt eingeplant und koordiniert werden, sowie mehrere, aufeinander abgestimmte Vorhaben zeitgleich realisiert werden. Sowohl zur agilen Release Planung, als auch zur Skalierung von Scrum mit mehreren Teams wurden bereits entsprechende Erweiterungen erprobt und dokumentiert.

In der Praxis erfordern diese Erweiterungen Kompromisse bezüglich der Grundwerte und der empfohlenen Vorgehensweisen. Während Anforderungen der Release Planung vom Product Owner im Scrum Alltag relativ leicht berücksichtigt werden können, stellt die Abstimmung mit mehreren Teams eine Herausforderung dar, z.B. wenn versucht wird, die "persönliche Abstimmung" in Treffen mit zu vielen TeilnehmerInnen zu ermöglichen. Neben den in der Folge beschriebenen Erweiterungen wird eine Aufteilung der Domänen und Vorhaben auf so weit wie möglich unabhängige, kleinere Produkte empfohlen. Ist das nicht möglich, ist zunächst zu prüfen, ob die Anwendung agiler Rahmenwerke in diesem Umfeld nicht mehr Schwierigkeiten als Vorteile zur Folge hat.

Wenn agile Methoden sinnvoll erscheinen, können folgende Erweiterungen überprüft und ggfs. angepasst werden:

Agile Missverständisse

Dieser Beitrag widmet sich beliebten Missverständnissen und überholten Interpretationen agiler Rahmenwerke. Sie beinträchtigen bis heute die Erfolgsgeschichte des "agilen Manifestes" und darauf aufbauende Rahmenwerke und verdienen deshalb entsprechende Aufmerksamkeit. Die Hinweise enthalten Verweise auf Abschnitte im aktuellen  "Scrum Guide" von Jeff Sutherland und Ken Schwaber, siehe Link am Ende des Beitrags.

Agile Rahmenwerke machen Führung und Planung obsolet

Die Abschnitte über "Scrum-Theorie" - vgl. "empirische Prozessteuerung", der Abschnitt "Der Product Owner" und "Der Scrum Master" im Scrum Guide und die an diversen Stellen des Guides beschriebenen Planungsaufgaben demonstrieren, daß agile Methoden Planung und Führung nicht dem Zufall und der naiven Hoffnung auf eine sich automatisch einstellende "Selbstorganisation" überlassen. Der wesentliche Unterschied zu älteren Management Rahmenwerken besteht in der konsequenten Förderung der Selbstorganisation und Eigenverantwortung in Bereichen, wo sie eingespielte Teams nach einiger Zeit wie selbstverständlich übernehmen können.

Im agilen Manifest wird zu Recht der Wert "Reagieren auf Veränderung" über den Wert "Befolgen eines Plans" gestellt, ohne das die Bedeutung von Planung in Abrede gestellt wird. Agile Rahmenwerke sind der emprische Prozessverbesserung verpflichtet, die ohne überprüfbare Ziele aus vorangegangener Planung nicht denkbar wäre. Das "Befolgen" eine Planes stellt für sich alleine keinen Wert dar. Zudem lebt die Idee der "kontinuierliche Verbesserung" von der Erkenntniss, dass Planung in der Praxis nach wenigen Minuten überholt ist. Trotzdem ist ein Mindestmaß an Planung erforderlich, z.B. um kurzfristige gemeinsame Ziele festzuhalten (vgl. z.B. "Sprint Vision"), und damit überhaupt eine Abweichung feststellbar ist.

Weiterlesen...
Seite 2 von 2