18 Oktober 2018
„Ich habe mich im SPRINT verlaufen“ – Warum wir den agilen Ansatz mit klassischen PMI-Standards kombinieren
Softwareprojekte agil und mittels SCRUM umzusetzen ist nicht wirklich neu. Notwendigkeit und Vorteile im Vergleich zum klassischen Wasserfallansatz liegen ohnehin auf der Hand, gerade weil diese auf unzähligen Veranstaltungen immer wieder gebetsmühlenartig wiederholt werden.
Doch wie läuft es in der Praxis ab? „Verfolgt ihr auch einen agilen Ansatz in der Software Entwicklung?“ ist eine typische Frage an IT-Verantwortliche. Darauf bekommt man nicht selten Antworten wie:
- „Wir haben unsere eigene Interpretation gefunden.“
- „Wir sind gerade noch in der Transformation von Wasserfall zu agil.“
- „Wir haben in der Transformation festgestellt, dass wir doch keinen SCRUM-Master benötigen.“
SCRUM ist sicherlich die am häufigsten eingesetzte agile Methode, stellt aber neben Kanban oder Extreme Programming nur einen agilen Ansatz dar. Die Art und Weise wie SCRUM in Organisationen interpretiert und gelebt wird, kann höchst unterschiedlich ausfallen. Jedoch: Egal, für welche Interpretation man sich entscheidet, es ist wichtig, dass das zugrunde liegende agile Manifest berücksichtigt wird (agilemanifesto.org):
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
Risiken der agilen Software-Entwicklung
Bestehende und vor allem in der Vergangenheit bewährte Entwicklungsmethoden werden nicht von heute auf morgen auf einen neuen agilen Ansatz umgestellt. Nicht umsonst begleiten zahlreiche externe Berater diesen „Change“ bzw. die Transformation im Unternehmen. Kennt man SCRUM & Co nämlich nur aus der Theorie, birgt eine Einführung durchaus Risiken:
• Ungeklärte Verantwortlichkeiten und teaminterne Rollenverteilung in der neuen Struktur
• Entscheidungsvakuum resultierend aus ständigem Verschieben einer Aufgabe in den nächsten Sprint
• Zu wenig Zeit für Feedback-Runden und Reviews speziell von externen Stakeholdern
• Geringe Qualität der Sprints aufgrund fehlender Automation sowohl beim Bauen als auch beim Testen der Software
Es bedarf an Erfahrung und vor allem an Gespür für Menschen. Nicht umsonst steht der Faktor Mensch gleich an erster Stelle des Manifests.
Agilen Ansatz in Kombination mit klassischen PMI-Standards
Nicht jeder Auftrag und auch nicht jedes Softwareprojekt eignet sich für eine agile Umsetzung. Beispielsweise können klar definierte und auch durch Standards vorgegebenen Anforderungen an eine Software-Lösung durch klassische Projektmanagement Methoden einfacher umgesetzt werden – vor allem bei Projekten in stark regulierte Branchen wie zum Beispiel der Luftfahrt oder der Pharmaindustrie.
Sind die Anforderungen hingegen noch unklar und auch die Ziele zu einem bestimmten Grad flexibel, kann eine agile Vorgehensweise von Vorteil sein.
Nicht selten kombinieren wir deshalb bei DESEO agile Methoden mit klassischen PMI-Ansätzen. Oftmals wickeln wir dabei die grobe Projektplanung klassisch ab, während im Sprint-Verfahren parallel dazu kleinere Subprojekte iterativ abgearbeitet werden.
Ihr Vorteil: Wir kennen beide Welten und passen unser Vorgehen an die Bedürfnisse und Rahmenbedingungen unserer Kunden an.