Seit Anfang 2008 benutzen wir in unserer internen Produktentwicklung das SCRUM Vorgehensmodell (Infos: http://de.wikipedia.org/wiki/Scrum) . Nun möchte ich hier nicht über dieses agile Vorgehensmodell an sich philosophieren, sondern über die Besonderheiten und Zwischenergebnisse in unserem kleinen Feldversuch.
Das Besondere an unserem Projekt ist, dass es so klein ist. Das Team besteht aus einem einzigen Entwickler, die sehr engen Vorgaben für das Ergebnis kommen von einer weiteren Person.
Daraus ergibt sich zunächst ein Problem mit der Rollenverteilung: wir können Product Owner und Scrum Master nicht ohne weiteres personell trennen. Unser Zwischenergebnis: die Rolle des SCRUM Masters tritt in den Hintergrund. Da der SCRUM Master eigentlich nur die Aufgabe hat, die SCRUM Prozess aufrecht zu erhalten und Probleme aus dem Weg zu räumen, wird seine Rolle unwichtiger, solange alle sich gleichermaßen bemühen, den Prozess umzusetzen. Die Rolle des Product Owner ist wichtiger, da er die Verantwortung für alle Entscheidungen und Priorisierungen hat. Ein SCRUM mit einer Person als Product Owner (Chef) und einer Person als Entwickler (Mitarbeiter) bedeutet vor allem eines: abgeben können, nicht als Chef bestimmen, Eigenständigkeit fördern. Also eigentlich das, was man will.
Durch die “Kleinheit” des Ansatzes rücken ausserdem SCRUM-Aspekte in den Mittelpunkt, die bei großen Teams und langen Sprints vielleicht nicht auftreten würden. So sind die geplanten Sprints sehr wenig robust gegen Einflüsse von Aussen und geraten dadurch sofort in Gefahr:
- Überraschende Krankheit des einzigen Mitarbeiters stoppt sofort die ganze Arbeit
- ein einzelner falsch eingeschätzter Task behindert sofort das gesamte Fortkommen
- Zu ehrgeizig “gepackte” Sprints können viel schlimmer enden.
Ergebnis: Sprints sollten nicht zu kurz sein (Gesamtumfang >= 2 Mann-Wochen hat sich als Minimum gezeigt) und etwas mehr Reserve im Sprint belassen.
Lohnt sich das Vorgehen denn dann bei so kleinen Teams? In unserem Fall ist diese Frage klar mit “JA” zu beantworten. An oberster Stelle der Vorteile ist die ständige Absprache und Steuerungsmöglichkeit des Projektes, die auch den in unserem Fall sehr notwendigen Know-How-Transfer gut auffangen kann. Das Projekt erreicht zwar nicht immer alle Ziele, bleibt aber stets unter Kontrolle. Wildwuchs an der Software wird von Anfang an verhindert.
So weit das erste Zwischenergebnis aus unserem Feldversuch “Mini-SCRUM”
Tags: SCRUM
