Rollen und Tätigkeiten

Bild: Wikimedia Commons / Andriy Makukha - CC BY-SA 3.0

Zu den Gründen aus denen viele Unternehmen Verschlimmbesserungen an Scrum vornehmen (was häufig zum Harikiri führt) gehört die Sorge, dass komplexe Vorhaben ohne leitende und koordinierende Rollen nicht funktionieren. Die Argumentationen sind immer wieder die gleichen: Es gibt viele übergreifende Tests? Dann braucht man einen Testkoordinator. Es gibt eine komplexe Architektur? Dann braucht man einen Architekten. Es müssen verschiedene Features gleichzeitig Live gehen? Dann braucht man einen Releasemanager. Und so weiter. Die Folge: Mit den Rollen kommen Arbeitsteilung und Bürokratie zurück, alles wird langsamer, die Agilität verschwindet.

Dass diese Entwicklung immer wieder auftritt lässt sich auf einen zentralen Denkfehler zurückführen: Es wird davon ausgegangen, dass Tätigkeiten nicht mehr durchgeführt werden wenn sie keiner Person zugeordnet sind. Würde das zutreffen wäre es tatsächlich ein Problem, allerdings trifft es in richtig implementiertem Scrum nicht zu. Hier werden diese Tätigkeiten auch weiterhin erledigt, nur eben von keinem Koordinator oder Mittelmanager mehr sondern vom Entwicklungsteam selbst, und zwar immer dann wenn es notwendig ist.

"Aber das geht nicht, das können die gar nicht!" wird an dieser Stelle häufig eingewandt. Und hier kommen wir wieder zum korrekt implementierten Scrum zurück: Wenn zu den Aufgaben die erledigt werden müssen z.B. Testmanagement gehört, dann müssen dem Entwicklungsteam Personen zugeordnet sein die das können. Der Scrum Guide ist da eindeutig - Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment. Auch hier gilt die alte Wahrheit, dass dieses Framework nur funktioniert wenn man es einsetzt wie gedacht.

Und das lässt sich sogar noch weitertreiben: um dem Regelwerk formal Genüge zu tun könnte man einfach den Test- oder Releasemanager in das Team versetzen, wo er zwar seinen Titel verlieren würde, seine Rolle aber weiter ausüben könnte. Zu empfehlen wäre das aber nicht, da er zum einen in nur einem Team kaum ausgelastet wäre und zum anderen der Bus-Faktor bedenklich nach unten gehen würde. Zielführender wäre auch hier die Anwendung des Pull-Prinzips: Die Tätigkeit kommt als Task auf das Board und sobald sie erledigt werden muss kann sie vom jeweils nächsten Teammitglied übernommen werden das eine Aufgabe abgeschlossen hat.

Natürlich muss umgedacht werden wenn so gearbeitet wird. Manager müssen Verantwortung dorthin geben wo sie bisher noch nicht war, Mitarbeiter müssen weitergebildet werden und Entwickler müssen Aufgaben übernehmen die sie vorher noch nicht hatten. Die Vorteile wiegen das aber mehr als auf - Wissensverteilung, Abbau von Flaschenhälsen, ganzheitliche Sicht und Übernahme von Verantwortung sind nämlich genau die Faktoren die ein Team schon nach kurzer Zeit effektiver und effizienter machen.