In meinem Artikel DSDM Atern, jetzt auch auf Deutsch habe ich begonnen, Atern als bislang noch nicht weit verbreitetes agiles Framework vorzustellen. Heute möchte ich das Rollenmodell von Atern vorstellen. Atern definiert zwölf Rollen, die in zwei verschiedenen Dimensionen geclustert sind. Zum einen sind es drei verschiedene Ebenen:

• die Projektebene, deren Rollen für die Gesamtstrategie, den fachlichen Blickwinkel und dessen Steuerung zuständig sind
• die Entwicklungsebene, deren Rollen die konkrete Entwicklung durchführen. Dazu gehören auch Aspekte wie Vorbereitungen, Testen und Ausliefern,
• und die Ebene der anderen Rollen, deren Rollen nur bei Bedarf und eigentlich außerhalb des Projektes zugezogen werden.

Die andere Clusterung ist eher thematisch: die orangenen Rollen sind die fachlich motivierten, die grünen die mit der Entwicklung betreuten und die blauen die Managementrollen.

Wofür brauche ich so viele Rollen? Nun, zum einen handelt es sich ja um Rollen, nicht um Personen. Das bedeutet, dass mehrere Rollen von einer Person ausgefüllt werden können, aber auch, dass mehrere Personen in der gleichen Rolle sein können. Das Letztere wird sicher bei den Entwicklern und Testern der Fall sein. Aber in kleinen Projekten mag es sicher ein wenig übertrieben sein, eine künstliche Trennung zwischen den fünf verschiedenen fachlichen Rollen vorzunehmen, wenn es von einer Person ebenso gut ereldigt werden kann. Man spricht hier wie bei anderen Modellen (z.B. RUP oder V-Modell) auch vom Tayloring, also dem Maßschneidern der Vorgaben in Bezug auf eine konkrete Situation.

Dem Scrum-erfahrenen Agilen mag die Vielfalt der zwölf Rollen denn auch hoffnungslos überdimensioniert erscheinen, aber ich bin der festen Überzeugung, dass die Aufteilung sehr sinnhaft ist. Gerade in größeren Projekten ist die Konzentration aller fachlichen Themen auf genau eine Person, den Product Owner, eine Bürde, der nur wenige Personen, die diese Rolle innehaben, wirklich gerecht werden. Konkret müssen ja nicht nur die Stakeholder „bedient“ werden, sowohl beim Erfragen der fachlichen Anforderungen als auch beim Erwartungsmanagement gegenüber den Anforderern. Auch die konkrete Formulierung der User Stories, die Verwaltung des Backlogs, Erstellung eines Releaseplans und last but not least die fachliche Steuerung des Teams gehören zu den immensen Aufgaben, die ein Product Owner zu meistern hat. Im Blog-Beitrag  Product Owner, der agile König wird ausführlich darüber berichtet.

Ich glaube, dass ein einzelner Mensch selbst in Vollzeit bei nicht-trivialen Projekten damit überfordert ist. Und die Scrum-Antwort auf diese Situation, nämlich ein Product-Owner-Team mit einem primus inter pares löst das Problem der Aufgabenteilung in diesem Team auch nur unzureichend. Da gefällt mir die Aufteilung bei Atern schon viel besser. Die Aufgaben sind über die einzelnen Rollen wunderbar separiert und ergänzen sich zu einem Ganzen. Es gibt den fachlichen Auftraggeber, der für das Geld sorgt, letztendlich das Projekt verantwortet und auch oberste Entscheidungsgewalt hat. Der fachliche Visionär, der bereits inhaltlich mitarbeitet, jedenfalls auf Visionsebene und bei der Erstellung der groben Geschäftsvorfälle. Der fachliche Botschafter repräsentiert die Sicht der Fachabteilung, übersetzt diese in „Projektsprache“ und organisiert fachliche Tests. Der fachliche Analyst ist als full-time-Teammitglied bei der täglichen Arbeit dabei und stellt sicher, dass die technische Umsetzung die fachlichen Anforderungen erfüllt. Der fachliche Ratgeber schlussendlich stellt spezifisches Fachwissen zur Verfügung, z.B. als späterer Keyuser, der ein Spezialwissen besitzt, das bei der Entwicklung nützlich sein kann. Die Anordnung etwas abseits vom Team deutet an, dass er nur bei Bedarf hinzugezogen wird und kein ständiges Teammitglied ist.

Diese Trennung in die verschiedenen Rollen macht es gerade in größeren Projekten und Organisationen leichter, die richtigen Personen zu finden, die diese Rollen auch wirklich gut ausfüllen können. Jemand aus der Fachabteilung kann einen tollen fachlichen Ratgeber oder Botschafter darstellen, würde aber niemals die Zeit finden, ein kompletter Product Owner zu sein. So gibt einem diese Aufteilung mehr Möglichkeiten in der personellen Besetzung eines Projektes – und das ganz sicher mit einem deutlichen Qualitätszuwachs, da man Personen gewinnen kann, die nur Teilzeit zur Verfügung stehen können.

Aber auch, wenn man ein kleines Projekt hat, in dem fünf fachliche Rollen nicht nötig sind, hilft diese Aufteilung. Durch die gute Beschreibung der Aufgaben der einzelnen Rollen kann auch eine Einzelperson diese Beschreibungen quasi als Checkliste verwenden, um keine ihrer Aufgaben zu vergessen.

Fazit: nicht erschrecken lassen von der Rollenvielfalt, sie ist vielmehr eine Hilfe als eine Last!