vom BDSH e.V. verifizierter Sachverständiger
Ein umfassender Überblick über agile Methoden und deren Anwendung in der Softwareentwicklung
(In meinem Post wird aus Gründen der Lesbarkeit und Klarheit auf die Verwendung einer gendergerechter Sprache verzichtet.)
Zu einem Puristen der agilen Methode habe ich einmal gesagt: „Kein Wunder dass die Pyramiden nie fertig geworden sind: die haben damals die agile Entwicklung nicht beherrscht hatten keinen Scrum-Master…“
Das ist natürlich provokant. Aber manchmal muss man provozieren um einen Standpunkt zu hinterfragen um die Zielperson zu bewegen sich eigene Gedanken zu erarbeiten statt irgendwelchen „neumodischem Kram“ einfach nur „nachzubeten“.
(Agil: „jetzt“ werden Dokumente und Ergebnisse als Artefakte bezeichnet. Die Begründung (studiere die Methode*) scheint einleuchtend. Aus meiner Sicht ist eine Umstellung hier aber vollkommen unnötig: Lasst uns Besprechungsprotokolle als solche bezeichnen ebenso Spezifikationen FAQ´s Projektfortschrittsreports Präsentationen Entscheidungsvorlagen usw.)
*Agil: Artefakt hat breite Anwendbarkeit: Ein Artefakt kann viele verschiedene Formen annehmen wie z.B. User Stories Product Backlogs Sprint Backlogs Burndown Charts oder Inkremente der Software. Der Begriff ist breit genug um all diese unterschiedlichen Ergebnisse zu umfassen.
Ok es ist Fakt dass wir mit mehr Agilität in einem Projekt besser zum Erfolg kommen werden.
Das erfordert: Anpassen an neue Erkenntnisse eine sich als unzutreffend erweisende Spezifikation zu überarbeiten neu zu priorisieren und das Team effizient zu führen.
Aber muss ich alles „über den Haufen“ werfen was mich bisher zum Erfolg begleitet hat?
Wenn ich die Methode zitiere oder ich frage ChatGPT nach einem Plan für den Sprint und nach der Verantwortung des Scrum-Masters dann wird postuliert: Allmorgendlich a ca. 15 Minuten die Priorisierung neu aktualisieren Hindernissen nachfragen um diese zu beseitigen die Motivation erhalten usw.
Fragt man nach den benötigten Skills für unseren Scrum-Master werden ausschließlich Soft-Skills aufgelistet.
Nun stelle man sich vor: Da sitze ich im Sprint-Meeting als 50-jährige Person und vorne „tanzt“ eine junge Person die Scrum-Rituale.
Wenn mir dann diese Person nicht wirklich etwas „sagen“ kann werde ich zunehmend demotiviert.
Meine Überzeugung: Wenn das Unternehmen erfahrene Softwareentwickler beschäftigt die bis zur Rente dort durcharbeiten werden (Telekom, SAP, die Banken und Versicherungen usw.) dann muss ich konstruktive Wege finden meine klassischen Methoden agil „aufzumöbeln“ und an meine phasenweise Budgetplanung anzupassen.
Ansonsten wird mit viel Aufwand nicht das erreicht was erreicht werden muss:Mein Management(!) und meine Teams flexibler aufzustellen.
Die Entwicklungszyklen werden immer kürzer Ergebnisse müssen immer schneller zur Verfügung stehen. Daher müssen Elemente der agilen Methodik konstruktiv aufgenommen werden. Aber es muss dringend vermieden werden eine unkontrollierbare Art und Weise der Entwicklung einzuführen die nicht einmal solch effizienten Werkzeuge wie die Meilensteintrendanalyse ermöglicht. (Das Burndown-Chart ist meist kein wirklicher Ersatz weil agile Planung meine benötigten Projekt-Budgets viel zu oft umstürzt. Aber ich muss aus Businesssicht eine Kosten-Nutzen-Planung ganz klassisch aufstellen und argumentieren um meine Projektbudgets zugesagt zu bekommen.)
Earned Value Management – d.h. Entwicklungs-Performance-Analysen schon in frühen Phasen des Projektgeschehens - müssen möglich bleiben.
Fazit:
Agil sein bedeutet geplante Ergebnisse unter der Einbeziehung neuer Ergebnisse gegen den erwarteten Nutzten abzuwägen meine Ziele adäquat anzupassen und somit meine Projektplanung business-orientiert aus Kunden- und Unternehmenssicht zyklisch zu aktualisieren und die erforderlichen Budget- und Ressourcenfreigaben zu erkämpfen.
Agil arbeiten bedeutet auch im Management bewährte Methoden wie reifegrad-abhängige Führung meiner Teams zu etablieren und dort auch das Fachwissen zu organisieren um von den Mitarbeitern geachtet zu werden.
Agil erfordert weiterhin die Gegebenheiten der Planungshorizonte der Unternehmen / des Public Sectors die Mentalität meines Managements und meiner Teams und meine bisherigen Vorgehensweise konstruktiv zusammen zu bringen.
© Dr. Manfred Fitzner