Owner, Master, Team

Das abstrakte Scrum muss jedes Team individuell für sein Projekt implementieren. Es spricht zunächst den Projektmanager oder Entscheidungsträger an, der sich mit dem Prozess der Entwicklung auseinandersetzt. Dabei setzt es Rollen, Aktivitäten und Artefakte ins Rampenlicht. Scrum gibt einige grundsätzliche Eckpfeiler vor, einige davon finden sich auch in Community-Projekten.

Scrum kennt drei Rollen: Product Owner, Scrum Master und das Team. Der Product Owner legt das gemeinsame Ziel fest. In Community-Projekten ist dies nur durch einen selbst gewählten Kunden-Proxy möglich, der den "Kunden" des Projekts simulieren soll. Meist übernimmt diese Rolle der Projektleiter, wie ihn etwa das Fedora-Projekt nennt. Ein Scrum-Team arbeitet interdisziplinär an der Software, so arbeiten auch in Community-Projekten Grafikdesigner und Lokalisierungsspezialisten Hand in Hand mit anderen Entwicklern.

Der Scrum Master gehört per Definition interessanterweise nicht zum Team. Er überwacht und begleitet den Prozess und greift steuernd ein. Diese Rolle existiert in Community-Projekten nicht. Seine Aufgaben bilden Projekte durch Regularien und Konventionen ab. Nicht selten üben treibende Projekt-Kräfte sie in Personalunion aus. Werkzeuge stehen stärker im Vordergrund und formen den Entwicklungskanal, zum Beispiel durch unterschiedliche Rechte beim Zugriff auf das Versionskontrollsystem.

Agile Werkzeuge

Die in Scrum genutzten Backlogs lassen sich konzeptionell gut auf Community-Projekte übertragen. Häufig sind es Ticketsysteme, die offene und mögliche Aufgaben beinhalten. Es obliegt dann der Entscheidung eines Release-Managers respektive des Projekt-Owner, ob er ein Feature in eine Release aufnimmt indem er Prioritäten wählt oder wenn Freiwillige die neue Eigenschaft schlicht von sich aus implementieren und einreichen.

Den Fortschritt visualisieren auch Community-Projekte häufig in Burndown-Charts. Technisch ist das mit modernen Ticketsystemen kein Problem, etwa mit dem für Open-Source-Projekte kostenlosen Projektracker Jira [5]. Das bekannteste Beispiel für das Sichtbarmachen der Entwicklung ist wohl der Graph der kritischen Fehler vor der Release einer neuen Debian-Version [6].

Oft schreiben Projekte Anforderungen in einer Form fort, die gut zu Scrum-Projekten passt. Zum Beispiel das Jira-Addon Green Hopper, das Entwicklern hilft User Stories zu formulieren. Risiko- oder Hindernislisten (Impediment Backlogs) aus Scrum führen Community-Projekte aber nur selten, da schwer auszumachen ist, welche Hindernisse zu formulieren und gegen wen sie zu artikulieren sind.