Klassische Projektleiter sind in agilen Teams überflüssig

"Softwareentwicklung ist ein kreativer Prozess und funktioniert besser in kleinen Schritten. Ein 500 Seiten starkes Pflichtenheft umzusetzen kann Jahre dauern, bis dahin sind die Features schon wieder veraltet", weiß Martin Giebel von Andrena Objects. Giebel ist Agile Coach und leitet den Münchner Standort des Karlsruher Unternehmens, das nach der Scrum-Methode arbeitet und mit seinen 120 Mitarbeitern Firmen unterstützt und berät, die ihre Entwicklungsabteilungen nach agilen Prinzipien neu organisieren wollen. "Um mit dem Markt Schritt zu halten, müssen Firmen ihre Produkte schneller entwickeln. Die Qualität darf darunter nicht leiden", beobachtet Giebel.

Auch die Software AG in Darmstadt mit ihren weltweit rund 850 Entwicklern spürte diesen Druck. 2009 begannen dort die Diskussionen, wie ein Wechsel aussehen könnte. "Wir haben ganz viele Gespräche mit unseren Führungskräften geführt", sagt Christian Gengenbach, Vice President R&D Application Modernization. Jahrzehntelang folgte das Unternehmen dem Wasserfallmodell mit Hauptprojektleitern, starrem Projektplan und Vorgesetzten, die ihren Mitarbeitern sagten, was sie tun sollen. "Agiles Entwickeln funktioniert ganz anders, die Weisungsbefugnis fällt weg", erläutert Gengenbach.

Ein Product Owner agiert wie ein CEO

In einem Scrum-Projekt verschwindet die klassische Rolle des Projektleiters. Das Team aus drei bis neun Entwicklern verteilt selbständig die Aufgaben, trifft sich täglich zu kurzen Meetings, bespricht, was erledigt wurde und was an diesem Tag ansteht. Größere Arbeitsabschnitte sind in sogenannten Sprints untergliedert, die idealerweise etwa vier Wochen umfassen. Der Product-Owner trägt die fachliche Verantwortung und kümmert sich um das Budget. Disziplinarisch verantwortlich für die Teammitglieder ist er nicht.

"Wenn sich Projektleiter mit der Rolle des Product Owners anfreunden, merken sie schnell, dass sie mehr Macht haben als vorher. Ihre neue Rolle entspricht der eines kleinen CEOs, sie legen die Funktionalität fest und planen das Release", erklärt Giebel. Ganz anders sehen die Aufgaben eines Scrum-Masters aus, der seinen Kollegen den Rücken frei hält. "Der Scrum-Master kümmert sich um die Infrastruktur, agiert als Mentor und Trainer für das Team und qualifiziert die Mitarbeiter weiter", sagt Giebel.

Wenn Entwicklerteams über Jahre in hierarchischen Strukturen arbeiten, fällt der Wechsel nicht immer leicht. Viele Unternehmen holen sich Hilfe von außen und schulen ihre Mitarbeiter intensiv. "Wir wollten natürlich unsere erfahrenen Projektleiter für die neue Methode begeistern und ihnen die Personalverantwortung nicht entziehen", sagt Gengenbach. Auch wenn diese Doppelrolle in der klassischen Scrum-Lehre nicht vorgesehen ist, wählte die Software AG diesen Weg. Außerdem wollten die Darmstädter keine neue Führungsebene innerhalb des Hauses etablieren. "Unsere erfahrenen Hauptprojektleiter begeistert vor allem die Technik, deshalb wollten wir ihnen diese Verantwortung nicht entziehen. Sie sind die richtigen für die Position des Product Owners."

2010 wagte die Software AG den Wechsel. Bis die neuen Prozesse reibungslos funktionierten, dauerte es zwei bis drei Jahre. "Wir haben in einzelnen Teams verschiedene Modelle ausprobiert und die Konzepte immer wieder modifiziert", sagt Gengenbach. In dieser Zeit holte sich das Unternehmen erfahrene Berater ins Haus, die in Workshops gemeinsam mit den Teams praktikable Wege für agiles Entwickeln fanden. Basis-Schulungen in Scrum waren ein wichtiges Element im Veränderungsprozess. "Wir haben auch eigene Mitarbeiter in den Teams zu Scrum Coaches weiterqualifiziert, die ihr Wissen an andere Teams weitergegeben haben. Auf diese Weise konnten wir unsere eigenen Erfahrungen besser einfließen lassen", erläutert Gengenbach.