Entwickeln mit Scrum
Klassische Projektleiter 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 Prinzipienagilen 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. Alles zu Agile auf CIO.de
Foto: Andrena Objects
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.
- Prüfen von Anforderungen in agilen Projekten
Ohne die Priorisierung der Anforderungen des IT-Projekts drohen hohe Folgekosten in einzelnen Sprintphasen. - Verzögerungen durch exportierte Probleme
Neben dem Totalausfall eines Sprints gehören Verzögerungen zur Tagesordnung. Diese entstehen etwa bei unklar definierten Anforderungen, die eventuell im falschen Detaillierungsgrad vorliegen oder durch Überlastung des Product Owners verspätet priorisiert werden. - Zeitverluste durch fehlende Aufgabenzuordnung
Zunächst lassen sich nicht ausreichend gut definierte Anforderungen durch ohnehin erforderliche Routinearbeiten wie der Spezifikation technischer Anforderungen kompensieren. Später droht dagegen der Totalverlust ganzer Sprints. - Anforderungen treffen ungesteuert auf das Projektteam
Bei agilem Projektmanagement stehen viele Unternehmen noch immer auf der Bremse. Der Grund: Viele Projektverantwortliche müssen zusätzlich zu den Projektanforderungen weiterhin Aufgaben im Tagesgeschäft übernehmen. - Anforderungen laufen beim Product-Owner-Team zusammen
In einem Projektteam aus typischerweise sechs bis acht Mitarbeitern laufen alle Fäden beim Product Owner zusammen. Das Product-Owner-Team besteht aus maximal drei Personen. Der Product Owner managed alle an das Team herangetragenen Anforderungen. Das gilt sowohl vonseiten der Auftraggeber als auch der beteiligten Fach- und IT-Abteilungen sowie der Revision. Viele Unternehmen machen dabei den Fehler, Product Owner nicht ausreichend vom Tagesgeschäft freizuhalten.
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.