Komplexe und längerfristige Entwicklungsprojekte durchlaufen mehrere Phasen mit spezifischen Bedingungen auf sämtlichen technischen und administrativen Ebenen. Dies stellt auch wechselnde Anforderungen an die Projektorganisation. Idealerweise sind Auftraggeber und Dienstleister in der Lage, das Vorgehen den sich ändernden Rahmenbedingungen anzupassen, um ein Projekt zu einem erfolgreichen Abschluss zu bringen. Im vorliegenden Projekt war Atos von Beginn an mit grossen technischen und organisatorischen Herausforderungen konfrontiert. Für die Entwicklung einer Client- und Server-basierten Software, der passenden Hardware-Infrastruktur (Clients, Server, Storage und Backup) und der gleichzeitigen Ablösung des alten Systems waren insgesamt vier Jahre geplant. In dieser Zeit standen zudem nicht geplante Technologiewechsel und Updates an, etwa der Übergang von Windows Vista zu Windows 7. Entsprechend der Grösse und Komplexität prognostizierte Atos rund 120 Mannjahre für die Umsetzung des Projekts, das schlussendlich in vier Phasen realisiert wurde.
Wasserfallmethode stösst an Grenzen
In den ersten drei Phasen wurden die Grundlagendefinitionen vorgenommen, die Infrastruktursysteme aufgesetzt sowie gewisse Programmierungen (Proof of Concepts) in den vier verschiedenen Entwicklungstechnologien (.?Net, Java, Datenbankprogrammierung und Sharepoint) erbracht. Auf organisatorischer Ebene zeichneten ein Gesamt- und ein Entwicklungsprojektleiter verantwortlich. Pro Technologiebereich realisierten Teilprojektleiter die Umsetzung der Anforderungen zusammen mit den Entwicklungsteams im jeweiligen Technologieumfeld. Entsprechend der Organisationsstruktur (siehe Grafik unten) wurden die Aufgaben technologie- und nicht funktionalitätsorientiert verteilt. Das Vorgehen der Entwicklung basierte pro Phase auf dem Wasserfallprinzip. Basierend auf dem jeweiligen Pflichtenheft definierten die Software-Architekten die Aufgaben, welche von den Teams technologieorientiert nach und nach abgearbeitet wurden. Während diesen ersten drei Phasen des Projekts wurde so eine grosse Anzahl Entwicklungsaufgaben umgesetzt und implementiert. In der letzten Phase sollte nun, aufbauend auf den bisher erarbeiteten Ergebnissen, die Business-Logik gemäss dem umfangreichen Pflichtenheft (fachlichen Anforderungen des Kunden) umgesetzt werden. Da das Entwickler-Team zu dieser Zeit 50 Mitarbeiter umfasste, war die Koordination zunehmend schwierig geworden. Und weil die einzelnen Teams nach Technologie aufgestellt waren, gab es Schwierigkeiten, dem Kunden durchgängige Ergebnisse liefern zu können, welche im User Interface begutachtet werden konnten. Das Projekt-Team erkannte, dass etwas verändert werden musste, um die vereinbarten Funktionalitäten fristgerecht liefern zu können.
Wissenstransfer und kürzere Feedback-Zyklen
Da bis zum Abschluss der Entwicklung nur wenige Monate zur Verfügung standen, war der Druck auf das Projekt-Team entsprechend hoch. Doch wie konnten die noch ausstehenden Arbeiten effizienter und effektiver priorisiert, alle Tests realisiert und die Abnahme vorbereitet werden? Zwangsläufig stellte sich die Frage, ob so kurz vor Abschluss des Projekts noch eine komplette Änderung der Prozesse und der Organisation vorgenommen werden sollte. Zum Zeitpunkt dieser Entscheidungsfindung war das technologische Know-how in den jeweiligen Technologie-Teams vorhanden, während die Projektleiter das Fachwissen über die Business-Logik auf sich vereinten. Zudem hatten lediglich die Teilprojektleiter und die Software-Architekten einen Überblick über ihre spezifischen Bereiche: In den verantwortlichen Teams kamen somit nur Fragmente der Lösung an. Um die Anforderungen der zu programmierenden Software-Lösung durchgängig zu implementieren, war die Bildung interdisziplinärer Arbeitsgruppen mit übergreifenden Technologie-Skills notwendig. Die Suche nach der passenden Entwicklungsmethodik führte zu Scrum als agiles Framework. Damit sollte eine durchgehende Entwicklung möglich werden, so dass die Teams innerhalb kürzeren Feedback-Zyklen fachbezogen und technologieübergreifend Resultate erbringen konnten.
Wenig Zeit für Umstellung
Um diesen Prozess professionell zu unterstützen, wurde der Übergang von einem erfahrenen Change Agent und Agile Coach begleitet (siehe Kasten). Da bereits der nächste Produkt-Release mit Scrum realisiert werden sollte, verblieben drei Wochen für die Ausbildung der Mitarbeitenden, die Zusammenstellung der Teams, den Aufbau des Backlog und den Start des ersten «Sprints» mit fünf Scrum-Teams. Angesichts der Rahmenbedingungen — das gesamte Projekt-Team war zusätzlich mit dem Abschluss eines Produkt-Release beschäftigt – war eine konventionelle Einführung von Scrum nicht möglich. Deshalb wurde entschieden, die erste Woche für eine «Scrum Preparation Week» einzusetzen, um die Grundlagen für die neue Organisation zu schaffen. Den Teams wurden wichtige Grundsätze hinsichtlich Planung und Schätzung, Teamwork und Dynamik, Time Boxing und der Wichtigkeit von geschäftsspezifischem Domänenwissen vermittelt. So zeigte sich schnell, dass die zuvor herrschende Konzentration und Individualisierung des spezifischen (technologischen) Domänenwissens einen Hemmschuh darstellte. Auf Basis dieser Erkenntnis wurden die User Storys (funktionale Anforderungen) in einer Expertenrunde überarbeitet und die Wissensvermittlung vorbereitet. Parallel dazu wurden mit anderen Gruppen die nächsten Entwicklungszyklen (Sprints) geplant, die Release- und Sprint-Längen definiert und die Meetings der Scrum-Teams organisiert.
Die Grundvoraussetzungen
Um das Domänenwissen wie gefordert breiter zu verankern, wurden Anzahl, Grösse und interdisziplinäre Zusammensetzung der Teams definiert und für jedes Team ein Scrum Master sowie ein Product Owner bestimmt. Als ein zentrales Element von Scrum wurden die Qualitätskriterien (Definition of Done, kurz DoD) von den Entwicklern formuliert und es wurde definiert, dass am Ende jedes Sprints das ganze Produkt mit den Änderungen sämtlicher Teams auf der Integrationsumgebung geprüft werden muss. Unter Berücksichtigung dieser Rahmenbedingungen konnten sich die Mitarbeitenden selbst einem Team zuteilen (siehe Grafik auf S. 68). Nach dieser aufwendigen Konstitution bestätigte jedes Mitglied mit Unterschrift sein Commitment zur neuen Organisation. Damit war der Startschuss gegeben, den Abschluss des Projekts in der vierten Phase unter den veränderten Vorzeichen in Angriff zu nehmen.
Zusammenhang besser verstehen
Da Scrum die Übertragung von Verantwortung auf alle Team-Mitglieder fordert und fördert, brauchen diese die benötigten Kompetenzen, um sich und die Arbeit selber zu organisieren. Zeigen Teams nicht genügend Initiative oder geben Product Owner zu wenig Verantwortung ab, wird dies im Sinne einer kontinuierlichen Verbesserung der Zusammenarbeit im Rahmen der Retrospektiven thematisiert.
Im neuen Setup bestand eine wesentliche Herausforderung im Zusammenspiel von Scrum Master und Product Owner: Nimmt der Druck zu, werden Prozesse verkürzt, was im Sinn des Termins, aber nicht unbedingt der Qualität ist. Als Resultat gehen die Anliegen von Scrum Master und Product Owner auseinander. In diesen Situationen geht es darum, den Beteiligten klar zu machen, dass die Einhaltung des definierten Prozesses lediglich Mittel zum Zweck ist und hilft, das Produkt in der gewünschten Qualität zu liefern. Die grösste Herausforderung bestand jedoch in der Umstellung von technologieorientierten Entwicklungsanweisungen auf User Storys. Diese erlauben den Mitarbeitenden, den Kontext der Einzelaktivitäten leichter zu verstehen sowie die Anforderungen der Kunden einfach zuzuordnen. Daraus resultierte für die Product Owner eine bis zu diesem Zeitpunkt noch unerreichte Übersicht. Weil die Teams bereits nach Scrum entwickelten, Abnahmekriterien, Storys und DoD definierten, war diese Anpassung zwar sehr anspruchsvoll, die Teams erreichten aber zusätzlich ein noch tieferes Verständnis für die verschiedenen Kundenanforderungen.
Fazit
Durch die Umstellung auf Scrum konnten trotz Anlaufschwierigkeiten und Widerständen spezifische Erkenntnisse aus einzelnen Bereichen im Sinn des Gesamtprodukts zusammengefügt und zu einem erfolgreichen Abschluss gebracht werden. Ein umfassendes, äusserst komplexes Projekt wurde damit in einer entscheidenden Phase nicht nur steuerbar gemacht, die einzelnen Mitglieder konnten auch zielorientierter arbeiten. All dies führte dazu, dass Zusammenarbeit und Motivation der Teams stark zunahmen und die Qualität auf sämtlichen Ebenen optimiert werden konnte. Durch diese gezeigte Performance hat sich der Kunde für diese agile Entwicklungsmethodik begeistert und entschieden, dass auch Folgeprojekte nach der Scrum-Methodik entwickelt werden – unter direktem Einbezug des Kunden als Product Owner.
Guido Aregger ist Project Director IPMA Level A, Civil and National Security bei Atos Schweiz. Torben Dziuk ist Security Software Engineer bei Atos Schweiz.
Veränderung der Kultur war grösste Herausforderung
Mit jeder agilen Vorgehensweise geht eine Veränderung der Kultur einher. Traditionell organisierte Projekte und Unternehmen sind hierarchisch organisiert und funktionieren nach dem «Command and Control»-Prinzip: Wenige denken, planen und befehlen und viele führen aus. Die Planer halten die Fäden zusammen und kontrollieren über aufwendige Reporting-Strukturen, ob die nötigen Fortschritte erzielt werden.
Mit agilen Prozessen wird den Teams die natürliche Verantwortung über die Gestaltung ihrer Arbeit, gekoppelt an die Lieferung von Business Value, zurückgegeben. So einfach dies auch klingen mag, so schwierig ist es in der Praxis zu meistern. Vermeintlicher Kontrollverlust und Machtverschiebungen treiben Manager und Projektverantwortliche dazu, mit den langjährig eingeübten Praktiken fortzufahren. Dies führt aber immer dazu, dass sich die Teams nicht entwickeln und weit unter ihrem Potential bleiben.
Die agile Organisation hingegen ist als Netzwerk von gleichberechtigten Personen mit unterschiedlichen Aufgaben organisiert. Sie schafft ein Umfeld, in welchem Lernen und die kontinuierliche Verbesserung als Ziel definiert werden – alles immer basierend auf gegenseitigem Respekt und Vertrauen. Wie in jedem Projekt brachte auch hier die Änderung der Kultur die grössten Herausforderungen mit sich. Das Projekt-Team hat sich auf diesen schwierigen Weg begeben und arbeitet hart daran, eine Kultur des Vertrauens und des gegenseitigen Respekts zu etablieren. Es liegt in der Natur der Sache, dass diese Reise nie aufhört, da der Weg das Ziel ist.
Agile Coach Mischa Ramseyer von Pragmatic Solutions zum Wechsel auf die Scrum-Organisation
