Claus Kolb

IT Projektmanagement


Auf meinem Blog berichte ich regelmäßig von meinen Erfahrungen aus Kundenprojekten. Folgen Sie mir auf Twitter, um über neue Artikel informiert zu werden.

Komplizierte und abstimmungsintensive Anforderungen in Scrum

September 18, 2014Claus Kolb0 Kommentare

Die Studie 8th Annual State Of Agile Survey von 2014 nennt mit 53% die Unfähigkeit, die Kultur einer Organisation zu ändern, als den Hauptgrund, warum sich agile Vorgehensweisen nicht weiter im Unternehmen ausbreiten. Auch aus meiner Erfahrung ist die Einführung von Scrum in den technischen Bereichen zwar eine machbare, aber sehr anspruchsvolle Aufgabe. Unterschätzt werden insbesondere die Auswirkungen auf die Geschäftsbereiche, die die Anforderungen definieren.

Heute will ich anhand eines konkreten Beispiels beschreiben, wie ein Problem in der Unternehmenskultur/-organisation aussehen kann, das die Anforderungsanalyse mit User Stories behindert.

Ausgangssituation

Die Hauptaufgabe des Projekts, in dem ich als Scrum Master gearbeitet habe, war es, Prozesse einer komplizierten Anwendungsdomäne zu optimieren. Im Projekt waren drei Fachbereiche involviert, deren Mitarbeiter an verschiedenen internationalen Standorten eines Konzerns beschäftigt waren.

Um die Anforderungen aufzunehmen und zu dokumentieren, arbeitete der Product Owner mit jeweils einem Fachbereichsvertreter pro Fachbereich zusammen, der als zentraler Ansprechpartner definiert war. Dieser Fachbereichsvertreter klärte und beantwortete fachliche Fragen innerhalb seines Fachbereichs. Der Product Owner aggregierte die Informationen in Form von Epics und User Stories, leistete aber keine Unterstützung bei der Klärung innerhalb des Fachbereichs.

Problemstellung

Die Arbeit mit User Stories verlangte sowohl bei der Konzeption als auch bei der Realisierung kurzfristiges Feedback von den Fachbereichsvertretern. Die o.g. Ausgangssituation mit der hohen Anzahl von beteiligten Personen und damit hohem Abstimmungsaufwand sowie komplexen Prozessen führte dazu, dass dieses Feedback zu lang dauerte. Dadurch war es schwierig, ein ausreichend gefülltes Product Backlog zu Beginn der Sprints zur Verfügung zu stellen. Verglichen mit dem Wasserfallmodell wird in Scrum das Lastenheft während der Projektarbeit „just-in-time“ generiert.

Abhilfe

Wie kann man dieser Problemstellung begegnen? Grundsätzlich muss die Einsatzplanung für Fachbereichsmitarbeiter von vornherein berücksichtigen, dass während der (im Vergleich zur Wasserfallmethode) kürzeren Laufzeit des Projektes mehr Aufwand pro Zeiteinheit entsteht, da die Phasen des Projektes parallel bearbeitet werden.

Methode 1: Inception Phase

Der Sprint 0 des Projektes (auch als Inception Phase bezeichnet) sollte ausführlicher gestaltet werden, so dass ein ausreichender Vorrat von User Stories bei Beginn der Implementierung vorliegt. Bspw. sollten bei Realisierungsstart bereits so viele User Stories im Status „ready“ sein, dass sie auf Basis der angenommenen Velocity des Teams mindestens drei Sprints ausfüllen. Ferner sollte sichergestellt sein, dass innerhalb eines Sprints mindestens so viele User Stories durch den Product Owner und die Fachbereiche fertiggestellt werden, dass sie für einen weiteren Sprint reichen. Wird diese Geschwindigkeit in der Spezifikation nicht erreicht, so muss ggf. die Inception Phase ausgedehnt werden.

Methode 2: Die Rückkehr des Fachkonzepts (light)

Auch wenn mich agile Hardliner dafür kritisieren werden: Ist die fachliche Abstimmung so arbeitsintensiv und die Fachlichkeit so kompliziert, kann es besser sein, ein Fachkonzept zu schreiben.
Um von einigen Vorteilen der agilen Vorgehensweise zu profitieren, empfiehlt es sich, iterativ in festen Timeboxes von z. B. zwei Wochen zu arbeiten und die zu konzipierenden Themen in Form von Epics und (leichtgewichtigen) User Stories in einem Backlog festzuhalten. Dadurch kann auch in der Konzeptionsphase die Priorisierung regelmäßig überprüft werden und aus den bisherigen Erkenntnissen gelernt werden. Die besonders hoch priorisierten Teile können detailliert ausspezifiziert werden, während niedrig priorisierte Teile nur oberflächlich beschrieben werden. In der Realisierungsphase wird dann mit allen Elementen der Scrum-Methode gearbeitet (sog. Water(fal)-Scrum).

Fazit

Die o.g. Vorgehensweisen stellen nicht den Idealzustand dar, aber sind ein unter den gegebenen Umständen pragmatischer Kompromiss. Mittelfristig sollte angestrebt werden, auch die Fachbereiche so aufzustellen, dass sie kurzfristig Feedback auf fachliche Fragen liefern können. Da dazu aber u.U. tiefgreifende organisatorische Veränderungen notwendig sind, ist dies nicht kurzfristig (innerhalb der Projektlaufzeit) machbar. In meiner praktischen Arbeit geht es mir immer darum, eine Vorgehensweise zu finden, die im konkreten Projekt funktioniert und Ergebnisse produziert.


Eine Antwort eingeben